6:03 pm on Wednesday15 January 2020
We’ve devised a practical checklist for an efficient and seamless code review for any technology
Code should be adaptable to multiple geographic locations, languages, currencies and related dynamics at any given time and should make life easy with any new requirements that may come up later. Defining all UI strings including error messages externally, helps in maintaining internationalization for your software.
2.Running Checks early
Every developer,from a personal stance,should run tools such as emulators, profilers, Lint tools, performance checks, device checks, etc.instead of waiting for the team leader or quality control teams to do later.This has become easier as most of the tools are available and easily integrable with your IDE.
When reading through code it should be relatively easy for you to discern the role of specific functions, methods, or classes. Nomenclature used in code should make the code self explanatory. The code shouldn’t re-implement functions that already exist in the language or libraries that the project uses.
It doesn’t hurt to check whether the code you’re reviewing requires extra documentation to go along with it. Comments should indicate if there is any deviation in behaviour, or in any part of core engine functionality that should not be touched by new developers etc. When documenting, make sure to analyse the type of comments that stay (or not) for a production release.
Another consideration when adding new code to a code-base is whether it matches the patterns that your team has already established. New developers should ensure that they maintain the integrity of the code written and handed over to them. They should avoid starting to write new additional functionality without understanding the intent of code structure and flow.
4. Modularization and Re usability
Breaking code into smaller chunks or modules helps because it becomes easy to reason about and make changes to specific parts of the system without side effects. When doing code review, make sure that the code uses all the appropriate language features. Reusability makes code compact, less error-prone hence better quality with higher throughput. Imagine how many times we can reuse the login module, social media integration, notifications, chats, third party integrations etc within and across projects.
To refrain from writing code that may not be easy to maintain in the future, please avoid:
During code review, security issues might be overlooked if developers forget to put themselves in the shoes of someone trying to exploit the system; something that can be avoided. It is essential to identify the ways how vulnerabilities could creep into the system, for eg including easy to prone third party libraries and tools that are using unencrypted interfaces or web services, sending data over unauthenticated channels, having safe URLS. It is important to ensure that all the customer information is maintained with utmost privacy.
7. Speed with Performance
Performance for users reflects focus on how quickly your code performs for the end-user. Ensure your queries to the backend system or databases support multiple simultaneous user requests. The code should be able to handle the corner case limitations of software, hardware, network and faulty user behaviours. Understand what requests can be kept synchronous or asynchronous. A page should ideally load in less than 3 seconds else we need to evaluate if we can optimize our UI controls and API calling mechanism
Reliable code is written on the assumption that things can fail, that assets will sometimes not load, API requests will occasionally return errors like 500, database records will be missing, the internet can be down or it can be too slow, server may not be up. Foreseeing the unexpected and uncovering all corner cases helps in creating a higher quality software.
9. Test Coverage and Quality
Consider carrying out a White Box Testing to focus primarily on verifying the flow of inputs and outputs through the application. This will improve design and usability and also strengthen security. Test Coverage Tools like Codestriker, Gerrit, Phabricator, and many more could prove useful. Before code is pushed to production, it’s worth double-checking that the code provides the functionality it was meant to provide.
It is important to think through client’s actual edge cases, unexpected inputs, and error handling scenarios that the code’s author may not have considered.
10. Refining Code Versioning
Every merge request should be labelled with the issue handled in bug tracking system along with the reason for having changed a core functionality. One of the risks with code review is that it encourages a focus on the details of code, rather than the bigger picture. Pull requests should be small and frequently integrated. Feature toggles, sometimes also called feature flags, can help with this. At any point labels should help you identify and retract to an earlier version of code with minimum time and effort.