This content originally appeared on DEV Community and was authored by DenisC
I am implementing my very first open source project in course OSD600 in Seneca. This is also my first complete program written in Python.
Everyone in the class is having their own version of the program, using different languages, including typescript, Python, JavaScript, C++, Rust, etc, while trying to fulfil the same objective, to develop a command line tool that pack data in a Git repository into a text file for use in LLM.
By reviewing the programs done by my classmates, I realize how different the approach can be to solve the same problem, and I can learn from their codes or even their mistakes. Moreover, other classmates also help spot out errors in my project that I did not find, from a different perspective, and by running in different environment and setting (e.g. different OS, shell).
I also appreciate the asynchronous nature of posting and solving issues in Git Repository, such that people can work on their most convenient and productive time.
In the testing and review process, I started to appreciate more the importance of clear instruction for testing, especially when a program is written in a language that a programmer may not often use. For example, I am using Python, while another project that I reviewed is using C++, which requires a different process to compile and run the program. Without clear instruction, testers may compile or run the program wrongly and produce errors that is actually due to incorrect use of the program.
One of the issue I filed is repeated occurrence of directory name when printing directory structure tree, which would be easier to spot out by a person other than the author, as the author may focus on the main logic of the program and overlook the subtle details.
While one of the issue in my own repo filed by the other is missing option when implementing the program, which is what I overlook in the first place.
I should be able to fix all the issues due to the small scale of the project, but as the scale of project grows, a higher chance of having errors is expected. In light of this, I realize the importance of modularity of program, to break down problem into separate parts, and I am planning to break down my program into different modules to improve the maintainability and prepare for possible future upgrades.
This content originally appeared on DEV Community and was authored by DenisC
DenisC | Sciencx (2025-09-13T00:55:38+00:00) Peer Review on Open Source Projects. Retrieved from https://www.scien.cx/2025/09/13/peer-review-on-open-source-projects/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.