Mayank KumarHi everyone! I’m Mayank, currently studying in the Computer Programming and Analysis (CPA) program. I’m in my Open Source Development (OSD600) course this semester, which has been an exciting dive into the world of collaborative coding. Recently, we were tasked with our first lab, where I had the chance to do something new - perform a code review on a classmate's project and have mine reviewed in return.
For this lab, I paired up with my classmate Theo, and we reviewed each other's CLI projects. My project dev-mate-cli is written in TypeScript, while Theo’s project, mastermind, is a CLI tool built in Rust. Since I didn’t have prior experience with Rust, this presented a unique learning curve for me.
Sync vs Async Approach in Code Reviews
Theo and I coordinated using both GitHub (for asynchronous feedback via issues and comments) and Slack (for real-time discussions). I found that this hybrid approach worked best. For quick notes and simple feedback, GitHub’s async mode was perfect - it allowed each of us to work at our own pace. But for more urgent or complex points that required in-depth discussion, hopping on Slack to sync up was a better approach.
Testing and Reviewing mastermind
Testing and reviewing Theo's code was a bit challenging at first because I wasn’t familiar with Rust. Setting up the environment took some time, but thanks to his project's README, I was able to run the project with little hassle. The challenge came when I tried to understand the intricacies of Rust syntax and libraries. However, this was a good learning experience for me - I learned how different languages handle similar tasks in varied ways.
One issue that caught my attention was how the program handled API key and other environment configurations. If the GROQ's API_KEY was missing, the connection failed but the error message was undefined response from the LLM model. I filed an issue suggesting better error catching for missing configuration. I also raised issues related to handling empty input files and problem related to the output for the -v flag. Here are the links to the issues I raised:
Receiving Feedback on My Code
Having Theo review my project was equally beneficial. He pointed out some oversights in how my program processed API responses and handled files, as well as some improvements for better user experience (UX). One issue I overlooked was how my output contained Markdown notations, which wasn’t the intended result. I’ve already fixed this by merging a PR, but I’m still working on two other issues: the file being overwritten when multiple input sources are provided and an error with the default language model when using a different API provider. Here are the links to the issues raised on my repo:
Key Takeaways from the Review Process
This whole experience was incredibly valuable. Not only did it allow me to get another perspective on my work, but it also helped me realize that some of the issues I found in Theo’s project existed in mine too! Testing and reviewing code from someone else helped me sharpen my eye for details, and I now see how important it is to consider edge cases and unexpected inputs.
All in all, this exercise showed me how collaborative open source development can really improve the quality of software. By raising issues and addressing feedback, we’re not just fixing bugs - we’re making better, more reliable tools.
