Earlier this week, I did some code reviewing for IPC144 repo on a couple of PRs: PR #73, compilers.md, PR #78, computers.md.
When I started the process, I was reviewing this PR but unfortunately (or fortunately??) couldn't find any bugs/nitpicks there. Great job @jerryhue 🧠!!
I learned that sometimes it is okay if you cannot find anything while reviewing, because maybe the PR was already reviewed well and the contributor did a great job initially, so just move on and try to find something on other PRs. Don't try to force a code review.
My Process for Code Reviewing:
For the other 2 PRs where I managed to find some nitpicks, I tried to follow the following process:
First, I tried to view the changes that they added and see if they followed all the requirements based on the issue PRs were for: issue #43, issue #45.
Then I reviewed the whole file they were working on, to see if maybe there was something missed/ left as is in the PR that was supposed to be fixed.
How to run code locally for code reviewing? 💡
After I made sure the code that the contributors added and the code that was there initially is good, I run the pages their were working on locally. To do that, I did used the following git commands:
- Go to the contributor's GitHub account and Clone the repo that they forked to write PR on, in this case, that would be IPC144 repo:
git clone https://github.com/username/IPC144.git
- Add a reference to the original repo so you can easily get changes from the remote repo:
git remote add username clone-url - Get all the code changes they have to your computer locally:
git fetch username - Check the list of branches and find the one they did the PR on:
git branch -a - Checkout their branch locally so you can see the code changes the contributors did and run the web app with those changes:
git checkout username/issue-# - Run the web app locally, in my case, I was using the below command because the repo I was working on was using Node.js.
npm run start
Once I run their changes locally, I was checking the web page visually, but trying to see if the images worked well, whether there the alt text for accessibility was added to all images and links, if the web page looks good on mobile/desktop view, etc. These could be the kind of details that I could have missed while checking the code alone.
Finally, I added necessary comments with issue and suggestion how to fix it and then approved/continued discussion about my review comment where it was necessary.
This is how my finalized review comments look like:
I found a couple of accessibility problems, typos, slug issues,and markdown issues. Everyone did such a great job in their PRs that it was hard to find extremely serious issues.
🥳🥳🥳
Final Words
I think that my git skills are slowly improving and I can see that there are some commands I already know so well that I don't have to look at my notes anymore when I need to use them.
I was also happy to find some bugs while reviewing other's code, because when I started reviewing code for the first time, I couldn't find anything. That made me feel under-qualified to do code reviews. But now, I understood that sometimes it is okay if I don't find anything.
At this point of the year, I tried a lot of things that I have never tried before, such as writing unit tests, doing code reviews, blogging, using more advanced git commands, sending PRs, etc. I feel like I am slowly growing in the programming field.
Oh and if you have any tips for code reviewing or git, you are welcome to share them in the comments below😉
Top comments (0)