Every non-technical founder must ideally do a code review for their app.
Even if you’re a technical founder, we recommend getting the code reviewed by an expert. The idea is that you might have an application that works great and passes all kinds of acceptance tests, but is built in a such a way that future maintenance and enhancements will be difficult or costly. Also, ‘To err is human’. So!
A code review has several benefits which can’t be overlooked:
- Improved code quality
- Fewer defects in code
- Improved communication about code content
- Shorter development/test cycles
- Reduced impact on technical support
- More customer satisfaction
- More maintainable code
Here are our pro tips on how a non-technical founder can review code:
#1 Know what is a code review?
Modern code review is defined as a form of code inspection which has the qualities of being informal, tool-based, and frequent. The most well-known engineering organizations today, Microsoft, Google, and Facebook, typically participate in a modern code review and also advocate this practice.
The goal is to make the project better, faster, and more secure through bulletproof code. By doing a code review you can ensure your current app architecture is built to last and will be low on maintenance. Here are few steps:
Step 1: You need not go through the lines of code, but test the functionality of the code written.
Step 2: If the code is giving you the desired results, have some of the tweaks listed, like option a and b for the same functionality. and get the answers from your developers.
Step 3: Ask for the iteration time and effort if the functionality needs to be tweaked in future.
And just to clarify, code review is not the same thing as app testing. Here’s what you need to know about mobile app testing if you are building an app.
#2 Review early
IBM’s 500,000 line Orbit project used 11 levels of inspections. It was delivered early and had only about 1% of the errors that would normally be expected.
The earlier you solve a problem the lesser it will cost you. If you build on top of a bad foundation then you might get away with it for a while but ultimately you’ll have to rework and start again. Have clear communication with your tech team about what you are aiming to achieve.
This doesn’t mean the developer is not doing his job properly, but there are chances of miscommunication leading to a fragile development process. Have clear communication with your tech team about what you are aiming to achieve.
At Arkenea, we encourage the culture of healthy communication between the developers and the founders.
The sooner you can discover potential problems, the better it is. As your project begins, set off the most warning flags during its initial phase.
#3 Define a method
Usually, the developers follow lightweight code review techniques, as distinct from formal inspections. These inspections can be divided into the following types:
- Pair programming
- Over-the-shoulder inspections
- Email pass-around inspections
- Tool-assigned code review
But you don’t need to be a part of these techniques. In fact, you should define your method for getting involved in a code review. Here are a few suggestions which we follow at Arkenea:
- Daily stand-ups with app developers on Skype and tele.
- Weekly status report published and sent via email/project management tool.
- Monthly steering meeting with high-level stakeholders.
#4 Set a checklist
Come in with your checklist which satisfies the business quotients.
Having a checklist as a starting point will help you avoid inconsistent code review quality.
The list can include things like checking if the code is documented appropriately, that it’s following your company’s code guidelines (or language’s general style guide), that features are covered with tests, that there is no code duplication, etc. It’s best to have that document available and used by the entire team.
#5 Be an observer
Fun fact: Whenever a non-technical boss shows up the tech team spend more time explaining things to him than reviewing the code.
Don’t be that boss.
If you are participating in the code review then make sure you strictly know your role, i.e. of an observer.
When the developers are discussing or explaining the code, you need to be passive. Take notes of your observations and ask relevant questions which can be helpful in improving the outcome of the code.
#6 Design review is not the code review
Make the discussion about the code.
There are two separate teams – developers and the designers. A code review is strictly about reviewing the functionality of the app and not the design. If you nee to learn anything on the design side, this is the right place.
Don’t make the code review a design review, so don’t criticize the design (unless it’s flawed and will absolutely not work.)
#7 Time your code review
Never review code for more than 90 minutes at a stretch. The effectiveness of your review decreases after around an hour.
The Cisco study showed that for optimal effectiveness, developers should review fewer than 200-400 lines of code (LOC) at a time. Beyond that, the ability to find defects diminishes. At this rate, with the review spread over no more than 60–90 minutes, you should get a 70–90% yield. In other words, if 10 defects existed, you’d find 7 to 9 of them.
If you need more time, break it into multiple reviews.
#8 Set a few tangible goals
It’s best to be specific with your review meetings, for instance, “reduce app loading time by 30%” or “reduce the sign-up options” instead of saying, “improve app retention rates.”
Establish quantifiable goals for code review, and capture metrics so you can improve the outcome.
As with any project, decide in advance on the goals of the code review process and how you will measure its effectiveness. When you’ve defined specific goals, you will be able to judge whether code review is truly achieving the results that you require.
#9 It’s OK to say “It’s all good”
Don’t get picky, you don’t have to find an issue in every review. There will be times when your tech team will be working flawless, as per your expectations. The idea is to achieve results, fast. So, you can wrap up some reviews in few minutes so that the tech team can get back to work.
Also, metrics should never be used to single out developers, this practice can seriously damage morale.
Remember, it is about reviewing the code, not the authors of the code.
#10 Make sure the review is fruitful
Seems like a no-brainer. But still!
If you’re going to get into all the trouble of reviewing the code to find bugs, it certainly makes sense to fix them all!
A good way to ensure that all the defects are fixed before the code proceeds to the testing stage is you having an “All Clear” sign for your checklist.
Want maintainable code that ships quickly? Get in touch with us.