Code Review Consulting
Recently I was hired to complete a review of an entire React Native codebase
This past month I was referred to a startup by a good friend of mine. They wanted an independent evaluation of a React Native application using Expo.
In this post I will go over my thought process, how much I was paid, and the exact deliverables the client wanted.
First Step
The first thing I do after getting repo access to the code, is click through all the code. I start at the entry point and work my way down.
In an Expo application, this means clicking into the App.js file in the root of the project.
I will start a google doc and make a new section for my initial thoughts. As I go through each file I’ll write down whatever I am noticing.
In this application, I noticed a pretty good authentication setup. The most glaring “mistake” is some dead code that can’t be hit due to the way if statements were setup. I tend to go into a fair amount of detail about everything from error handling, reporting, and various suggestions I may have. Especially if the project isn’t that large, I will dive in to each file in a detailed way.
Things I found in the code
Here’s a few thoughts I shared in the initial review process to give you an idea of what I look for.
Dead Code Paths
I was able to find a couple instances in the app where the developer had multiple if statements. It turns out, one of the else statements can’t be triggered, because an if statement above already handled this case. I made sure to call this out in my review.
Logging to the Console
This application had many console logs. In fact, when a user submitted an empty field in the application, it would log to the developer console instead of alerting the user. I made sure to mention that user facing alerts need to be made, and any other unexpected error handling should be sent to a bug tracking service such as Sentry.
Weird formatting
For some reason, some files in this codebase had 4 space indents, and others had 2. I mentioned they should consider running their code through Prettier.
Unused functions and variables
For this, I suggested adding eslint, and the no-unused-variables rule so that developers can’t leave around code that is no longer used.
Repeated code
If there is an easy way to abstract logic that is repeated, I make sure to call this out
Type Safety
This application was only using plain JS, so I spent a bit of time explaining why type safety is so important.
Network Requests
I find that many developers repeat their code for network requests when it comes to React applications. I spent some time explaining how SWR would remove a lot of duplicated code, and handle advanced uses their code isn’t even accounting for.
Deliverables
So how did I actually deliver my review? Thankfully, the client provided a set list of things they wanted from me. Before I focused on that, I went ahead and started a new text document, and opened up every file in the codebase. 85% of the files I had some comments to give. Most were a variation of the points I listed above.
I wanted to provide an in depth review, more than they were asking for, to ensure they are happy with what they paid for.
So, I attach the file path in the GitHub repo, and all of my comments, until I went through every file.
At this point, I created new headings at the top of my file with the client’s requested deliverables. Here they are:
We are looking for an evaluation on the following
1. Evaluate the candidate's ability.
2. Evaluate the foundation of the Android / RN app.
Final deliverables should also be to:
1. Provide a recommendation on pass / fail.
2. Provide high level thoughts on the developer’s ability & whether you'd hire this person.
3. Potential feedback for them on their work.
After having a massive document with 17 pages at this point, I created a heading for each of these from the client, at the top of the document. I proceeded to answer each question, and then for the final point about feedback for the original developer, I had the feedback given from every file I reviewed individually.
How much did I charge?
The client offered $500 for this review. The application was fairly small, and I really enjoy doing these reviews. Being able to summarize it on this blog was also in the back of my mind.
Overall this review took me under 3 hours, and I get to share some of the knowledge with everyone here!
Hopefully I will be able to do more of these reviews in the future. I love finding ways to write less code, increase testability of code, and help other engineering organizations.
If you found this post helpful, please consider subscribing or leaving a comment.