The entire month of summer school was dedicated to developing a project. Although it was supposed to be a month, the actual coding time was about three weeks. More specifically, it was from 8:30 AM to 5:30 PM. In the last week, I also spent evenings coding.
Three weeks may not seem like a lot of 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 stack used this time was completely new to me: React for the frontend and Flask for the backend. Later on, Redux and useSWR were also introduced into the project.
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 technologies used this time were relatively easy to pick up, except for Redux, which is still a bit confusing to me. So overall, I didn't find it difficult to develop with these technologies that I hadn't used before.
However, I did discover a significant problem: due to the deadline, 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 "Don't bite off more than you can chew" applies here.
DRY and AHA#
In this project, I was mainly responsible for the backend. However, even with around 2,000 lines of code that I developed myself, by the third week, I still occasionally had thoughts of rewriting certain parts.
Especially with the "action" part. In this project, I abstracted the user's favorite, rating, and commenting functionalities 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 modified. 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. It was possible to make the changes, but I didn't dare to because I couldn't afford the time cost. The final solution was to write a few additional methods, which made the code ugly. At that moment, I truly experienced the feeling of being 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 encapsulated some commonly used code into methods, there was still a lot of code that I chose to directly copy and paste, making slight modifications on top of it. This may save time and make writing code more enjoyable, but when it comes to making changes later on, I have to pay a considerable price for my previous laziness. If I had spent more time earlier to encapsulate the code, it 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." Using the "action" as an example again, if I had taken more time to think about combining the three operations, it would have been much better. But then again, how do we determine what is not hasty and what is not premature? I think at this stage, I still lack experience, so the next time I encounter a similar situation, I will most likely be pleased with my own cleverness and confidently step into another pit I dug for myself.
Project Process#
This time, we used the waterfall model, which felt different from the Scrum we used last semester. Personally, I felt the biggest difference was in the early stages of the project, where we spent several consecutive days writing relatively abstract documents. These documents, such as requirement documents and design documents, were difficult for us newcomers who were still inexperienced. Moreover, the time spent was just writing text, which didn't provide a good experience.
Overall, this experience was quite unique during my student years, and the month's time was not wasted. I am quite satisfied with myself.