Check out my project 👉 Barrierless
Check out Uday's project 👉 Codeshift
Hello!👋
Recently, I had the opportunity to participate in a code review with my teammate Uday, and it was both an educational and enjoyable experience. Here’s how the process went and what I learned along the way.
Choosing the Async Approach for Code Reviews
For our team, the code review process was done asynchronously, and I absolutely loved it. The asynchronous (async) approach gave us the freedom to thoroughly examine each other’s code on our own schedules. By doing this, I could take the time to dive deep into Uday’s project, make sense of it, and provide meaningful feedback. It also allowed me to do some research if I wasn't sure about an issue before flagging it.
This flexibility of working at our own pace made a huge difference. It led to more thoughtful, well-researched feedback that we could both address on our own time, without feeling rushed or pressured by a live session. With an async review, there’s no need to immediately have the answers—you have the space to think, test, and respond thoughtfully.
Testing and Reviewing Uday’s Code
Testing and reviewing Uday’s code was, for the most part, a seamless experience. His project was well-documented, which helped me quickly understand how it worked. However, I did encounter one small issue while installing the CLI tool on my machine: I had to run the npm link command to get the tool to function, and this step wasn’t mentioned in his instructions. This oversight provided an opportunity for me to raise an issue and contribute to improving the user experience.
Aside from that, I didn’t face many surprises. The thorough documentation, combined with clear code, made the review process straightforward. It was encouraging to be part of improving his project.
Noteworthy Issues Raised
One of the biggest takeaways from reviewing Uday’s code was realizing how easy it is to overlook small but important details when you’re too close to your own work. Things like typos in variable names or missing validation for an API key stored in the .env file were items that I didn’t catch initially, but were crucial for a smooth user experience.
During the review process, a few notable issues were raised. Some of them included:
- Typos in variable names: A small mistake, but one that’s crucial to catch as it can break functionality. Issue #4
-
Lack of API key validation: The program didn’t validate if an API key was provided in the
.envfile, which could lead to program failure. Issue #5 -
Unclear instructions: The
npm linkcommand wasn’t mentioned in the installation instructions, which could confuse users. Issue #2 -
Unnecessary code: The
program.command("run")line was redundant because there were no subcommands in the CLI tool. Issue #3
Getting My Code Reviewed
Having Uday review my code was a different experience. Since I had started my project a little late, my code wasn’t as polished as I would’ve liked. There were a lot of missing features, and the overall structure wasn’t as streamlined as I wanted it to be. Uday flagged several issues that I hadn’t even considered, which was a learning opportunity for me.
Issues in My Own Repo
Here are some of the issues that were flagged by Uday in my own repository:
Fixed Issues:
-
README.mddid not mention environment variables. Issue #11 - Missing
.env.example. Issue #10 - Mixed
import/requireusage without comments. Issue #9 - Simplifiable code blocks. Issue #8
- Uncaught exception in
index.js. Issue #7 - Unexpected behavior of the default language option when input text was English. Issue #6
-
.gitignoredid not exclude.envin the root directory. Issue #5
Open Issues:
- Missing optional features. Issue #4
- File input feature not yet implemented. Issue #3
- No
examplesdirectory available for reference. Issue #2
While I’ve resolved several issues, some—like adding the file input feature and examples directory—are still a work in progress.
A Learning Experience
This code review process was a valuable experience that helped me better understand the importance of collaboration in coding. Through the feedback and issues raised by Uday, I became more aware of the details I might otherwise overlook. Additionally, I’d like to credit my friend Peter Wan, who's also in the OSD600 class, for spending his time helping me start the project and always being available to save me when I run into issues with Git and GitHub. This experience will change the way I approach coding, as I now know the value of writing code with the assumption that it will be reviewed. I’ll strive to minimize issues from the outset, both for my own projects and as part of future collaborations.
In the end, it was not just about finding errors, but about improving the quality of the code and enhancing the user experience.
Top comments (0)