The entire month of this summer school was dedicated to developing a project. Although it was called a month, the actual coding time was about three weeks. More specifically, it was from 8:30 AM to 5:30 PM every day. In the last week, I also spent evenings coding.
Three weeks may not seem like a long time, but this experience was quite rare. I encountered many challenges and gained a lot of insights, so I want to record them here.
Learning New Technologies#
The tech stacks I used this time were all new to me: React for the frontend, Flask for the backend. Later in the project, Redux and useSWR were also introduced.
I was quite enthusiastic about learning new technologies, and I chose these because I wanted to try something I hadn't encountered before. Moreover, the tech stacks used this time were relatively easy to pick up, except for Redux, which is still a bit confusing to me. So overall, the development experience was not hindered by the fact that these were all new technologies to me.
However, I did discover a significant issue: due to the deadline pressure, I tended to rush and start coding after just looking at the usage and examples. Although I was able to produce something in the end, I always had a feeling of not being fully familiar with it, lacking a solid sense of mastery.
I also realized that an individual's time and energy are limited, while technology is constantly evolving. As Zhuangzi said, "My life has a limit, but knowledge has none." The saying "The more you bite off, the less you chew" applies here.
DRY and AHA#
In this project, I was mainly responsible for the backend. However, even with around two thousand lines of code that I developed myself, by the third week, I still occasionally had thoughts of wanting to rewrite certain parts.
Especially with the "action" part. In this project, I abstracted the functionalities of user favorites, ratings, and comments into one action. At the beginning, I was quite pleased with myself, thinking that I had achieved reasonable cohesion.
But later, I discovered the drawbacks: when I wanted to modify a specific part individually, due to its coupling, I had to modify some code that didn't need to be changed. By the later stages of the project, the frontend and backend were already about 80-90% integrated. At this point, modifying a core functionality would have a ripple effect throughout the entire project. While it was possible to make changes, I didn't dare to because I couldn't afford the time cost. The final solution was to write several additional methods, which made the code ugly. This was when I truly experienced the feeling of being stuck in a mess.
Looking back and thinking about how to avoid this situation as much as possible in the future, I think two principles might be effective:
- DRY
The abbreviation for "Don't repeat yourself." Although I consciously tried to encapsulate some commonly used code into methods, there was still a lot of code that I chose to directly copy and paste, making slight modifications. This was convenient and enjoyable during the writing process, but when I wanted to make changes later, I had to pay a considerable price for my previous laziness. If I had spent more time earlier to encapsulate it, my code would have been easier to modify. - AHA
The abbreviation for "avoid hasty abstractions." This principle reminds me of the saying "premature optimization is the root of all evil." Taking the "action" as an example again, if I had thought a bit more before coupling the three operations into one, it would have been much better. But then again, how can we determine what is not hasty and what is not premature? I think I still lack experience at this stage, so the next time I encounter a similar situation, I will probably still be pleased with my own cleverness and confidently step into another pit I dug for myself.
Project Process#
This time, we followed the waterfall model, which felt different from using Scrum in the previous semester. The biggest difference, in my opinion, was in the early stages of the project, where several consecutive days were spent writing somewhat abstract documents. These documents, such as requirement documents and design documents, were difficult for us newcomers who were still inexperienced. Moreover, the time spent during those days was just for writing text, which didn't provide a good experience.
Overall, this experience was quite unique during my student phase, and the month's time was not wasted. I am quite satisfied with myself.