First Experience with Code Review and Open Source Collaboration
This week, for the first lab, I had the chance to partner up with a classmate to review each other's code and suggest improvements. It really was a valuable experience that went beyond just writing code. It was a great opportunity to browse through other people's different point of view on the same task and ask for feedback.
Async vs. Sync
For this code review, I choose an async approach. Rather than communicating in real-time on MS teams, I used Github issues to provide feedback after taking the time to thoroughly look over the code. The main reason for this choice is that it allows everyone to analyze the code deeply at their own convenience. It also ensures that all feedback is logged which makes easy to reference when it is needed. I found it beneficial in terms of organizing the problems and checking the improvements that brought to the project.
so.. what did I learn?
The code I reviewed was in python that summarize the information of a Git repository into a single text file. Denis' code structure was very well structured utilizing argparse and pathlib. I knew that I had to use argparse for the command-line arguments but I got idea from Denis' code about pathlib for file path management.
Also learned that how effective it is to create the basic structure of the entire code before actually start implementing the helper functions. Denis had written down all the required functions with "TO be implemented" tag so it can be a kind reminder what is needed to be completed.
The Key Issues I Filed
when I started to review the code, it was in early stage so most part of the code were under "To be Completed" tag. So I created two issues for documentation and two for feature implementation.
README: python installation instruction
The README.md file was missing instructions on how to set up the Python environment or install necessary libraries. I created an issue to add a bit more precise guidance so that new users could easily set up the project.README: add LICENSE file to the project
A license is crucial for any open-source project. Project had License file but it would be good idea to also indicate it on the README.md file.Implement "wirte_git_info" to add repository details
The write_get_info function is supposed to fetch repository details. It was under "To be Implemented" tag but creating an issue would be a good way to track the work needed to be completed.Implement "write_struct_tree" to generate directory tree
Similar reason with function above, "write_struct_tree" function was also under "To Be Completed" tag. I filed an issue requesting the implementation of this feature to keep track of these works.
Getting my Code Reviewed
Having someone else reviewing my code was a bit embarrassing. It feels like I am letting someone to laugh at my work. However, it also felt incredibly rewarding once I saw the issues created by teammates. It made me realize that feedback isn't criticism, but a suggestion to make the project better.
Formatting of structure tree
This is a issue that I was aware with. It only prints the entire list of file instead of showing it in a structure tree. This would be first thing to work on.Missing print of absolute path
As always, bug comes from where you thought implemented correctly. I did put some time to check if paths are correctly printing but it doesn't. Thanks to Denis who found this but and created issue to draw my attention.Missing implementation of -o option
I haven't get to this far with my project and issues will help me to keep track of things that need to be implemented. Human memory is volatile so I will be vising these issues frequently to remind myself.
What I learned from this Lab
I learned few important lesson throughout this lab. Honestly, I never gave a thought about the importance of README file but now I understand that README file define a project's first impression and encourage others to browse through the project. Secondly, I learned the constructive feedback is not a criticism. Feedback has very different definition from criticism. It not only points out the possible improvement of the project but also saves my time to realize the defects and bugs that require attention. Lastly, I was impressed by how issues can turn vague ideas or bug reports into organized tasks. I always like to have a direction when I start working on something and issues are the most clear indicator where to start and where to go.
Top comments (0)