Doing Code Reviews & Filing Github Issues

As the second week of the term comes to an end, me and my classmates are gradually getting comfortable with the tools and practices used in the Open Source world.

To get used to the collaborative nature of Open Source, we were asked to review each other's code, give feedback on it, and file Github Issues pointing out any bugs/potential areas for improvement

Code Reviews

First off, I have never really done "proper" code reviews. I've created GitHub issues within the team projects' repos and helped my friends with their code here and there, but this experience was certainly new to me.

As a result, I don't have a preferred way of doing the thing. Me and my partner settled on conducting our reviews asynchronously. I liked the convenience of the asynchronous approach since both of us could peacefully work at our own pace without dealing with scheduling conflicts. However, I am eager to try the sync approach to be able to contrast the pros and cons of both (I also feel like it might be more fun).

Reviewing my classmate's code

My code review partner was Lily

Testing and reviewing her code was intriguing. I wanted to see other people's approach to the task we were given and was curious about the functionality of her CLI tool (you can check it out here: rat-assistant).

I've only faced a couple of problems throughout the process. The main one is that Lily's tool was written in TypeScript, a language I am not that familiar with. I haven't written in TypeScript and haven't touched JavaScript in a bit, primarily focusing on Python, so it was hard for me to understand what was going on after a first look at the project. I won't lie, to overcome this I asked AI to break down the code. It helped me to make sense of it when I was reading through the file line by line. The other consequent challenge was that I didn't feel competent enough to point out logical flaws in her code. Nonetheless, I wanted to provide helpful feedback, so I decided to focus on other areas (e.g. code formatting, setup instructions).

All in all, I have created 8 issues

• Issue #1 and Issue #2 are focused on improving documentation: The usage of an API endpoint and the need to provide an API key wasn't clearly mentioned in the README.md (Issue#1). + I suggested making the example of using the tool more illustrative (e.g. bun run index.ts [FILE_PATH] -r "mr. Rat please give feedback to this code." vs. bun run index.ts) (Issue#2):

• Issue #3, Issue #4, and Issue #6 have to do with code formatting. The code structuring was inconsistent (Issue#6), there were undescriptive variable names such as "thing" (Issue#3) and quite a lot of unclear draft comments (Issue#4).

• Issue #5 is more of a nitpick, the repo didn't have the directory with sample files for testing (Issue#5).

• In Issue #7, I pointed out the discrepancy in the --help information, as it mentioned running the tool with the command that doesn't currently work (toast vs bun run index.ts) (Issue#7).

• And, finally, Issue #8 is a good old typo which I found in one of the option descriptions (Issue#8).

Getting my code reviewed

Getting my code reviewed by another person was nice. To my surprise, I wasn't even nervous to receive criticism. On the contrary, I was more worried about coming off as judgmental in my feedback. But at the end of the day, there's nothing personal, we just want to help each other make our projects better.

The issues my partner has identified primarily have to do with a lack of functionality.

• Issue #1 and Issue #3 suggest to allow the user to specify an API endpoint of choice (Issue#1) and to enable users to pass the API key as a part of the command (Issue#2).

• Issue #2 is a missing --version flag (Issue#2).

I will start working on closing the issues over the weekend when I have more time (pinky promise).

Learning Outcomes

I feel more comfortable sharing my code when it is not "completely ready" (as if it ever is) after doing so myself and seeing my classmates' fruitful collaborations (not to mention that this lab pushed me to start working on the assignment earlier than I would otherwise). + Now I have a clearer understanding of how to conduct code reviews and what issues to look for in someone else's code.

I've also learned about bun! And, although my partner's code was written in TypeScript, which made it challenging to get ideas for my code, this lab sparked my interest in exploring my other classmates' Python projects, providing feedback and asking for theirs.

Feel free to take a look at my repo and file issues if you have any suggestions: https://github.com/arilloid/addcom