This week, I created a static site generator for my open source course. The task seemed very daunting at first, but as I started to write my program, I realized it was actually quite straightforward. However, sometimes an unexpected input would cause my program to break or behave in ways I didn't expect. Therefore, I was very glad that I was able to collaborate with my classmate, Luke Nguyen, in testing the program and finding any issues.
Finding a partner for code review
I was able to find Luke using Slack as he was also looking for a code reviewer at the same time. I was excited to work with a fellow web developer and although I initially wanted to review a program written in a different language, reviewing another person's JavaScript code helped me see problems in my own and learn new things about something I was already familiar with. We continued to use Slack to communicate which was really convenient.
Reviewing the code
It was a really great experience reviewing someone else's code and seeing how they did things differently. I learned so much from reviewing Luke's code. For example, whereas I used an HTML template, Luke generated the HTML in his JavaScript code which seemed very efficient and was something I had not considered. Thanks to his detailed README and code comments, testing his program was a pretty straightforward process.
Having my own code reviewed
I always get nervous when someone else reviews my code and finds all sorts of problems with it. At the same time, it's really nice having an extra set of eyes look over the code, test it for any problems, and suggest new things. For example, I initially forgot to test my code using a directory that contained non-.txt files, but Luke did so and noticed a bug. In addition, I usually comment my code by using //, but Luke actually suggested a different format, which I decided to use as it was very clear and easy to understand.
Issues in partner's code
In testing Luke's code, I found that the --version flag did not correctly print the program name. In addition, his program was not able to correctly read file names that contained spaces. Finally, I noticed a formatting issue in the generated HTML code. Although the output was correct, the formatting of the HTML was messy and could be difficult to read (such as incorrect indentation or a lack of spacing between paragraphs). Luke used a library called create-html, which made generating the HTML very simple, but the formatting of the output could be improved.
Issues in my code
Luke noticed several issues in my code. We actually had several problems in common. For example, my program also couldn't correctly read inputs if they contained spaces. We both used yargs to read command line inputs so I had the same problem where the --version flag didn't print the program name. I also had a bug where non-.txt files in a directory were included in the navigation when they should be ignored. Luke also provided some comments on how to improve my documentation (such as my README and code comments). I was able to fix all of these issues and improve the quality of my documentation thanks to Luke's testing and clearly written issues.
What I learned
Overall, I think it was a great experience being able to work with a partner in testing an application. I learned about how the same problem could be approached in a different way and I was also able to make suggestions to improve someone else's code. I think collaborating with others will help me improve as a programmer over time.
Top comments (0)