KISS and make code-review
A code review is the key to a high-quality code, apart from a good programmer who writes this code of course :) Our team is confident in this, therefore our code review refers to the rules of good form. What is it for? It helps to maximally clear the code of possible errors and difficult solutions, after all, most developers adhere to the KISS method (Keep It Simple, Stupid!). And you can’t argue with this, the simpler and clearer the code, the better it is. Do not overdo with simplification. The code review process is not so fast but we always pay attention to it.
So, the purpose of this article is to share our approach to code review and to be useful to you as always. Since our company has front / back-end and full-stacks, the code review stages will affect both sides.
General principles of code review:
1. Pay attention to the stack, the selected libraries and their size so that the size of the application does not bloat. Many libraries like momentjs have lightweight counterparts and sometimes you simply do not need to drag heavy solutions into a project.
2. Is the code easy to read? Are there functions with 5+ arguments? Are there files on 500-1000 + lines, and if so, is it possible to do something with them?
3. Are obsolete constructs (var, callback hell) used?
4. How do the algorithms work? Their complexity. Micro-optimizations (for example, replacing map with for) are sometimes needed, but you should come back to them later. But, for example, replacing the constant polling of the server with websocket can be useful.
5. Is it possible to combine the behavior of several similar methods into one without affecting the understanding of the functional?
1. Pay attention to how routing is described. Are routes protected from users who do not have the appropriate rights? How are redirects configured? Is it divided into chunks, if possible?
2. Pay attention to how the side and state of the components are described. Are the data duplicated, can they be calculated by memoizers and selectors? How are reducers described in the stores, are there any piling up, can they be distributed into different domains?
3. Stylization of the application. How are styles encapsulated so that there are no class intersections in the future?
4. Is the architecture divided into modules so as not to mix the store with the display and with the requests to the network?
5. Is the code-style adopted on the project respected? Are linters configured? And are they set up so as not to distract the developer and at the same time find potential errors in the code?
6. Specific technology selected things. For example, in React, there is a problem with re-rendering a component many times, and to improve performance, you need to use PureComponent, memoize data, and so on.
1. Is it easy to add a new endpoint to the system?
2. How clear is the work with the database?
3. How detailed are the layers and entities (middleware, services, utilities, controllers, routes, models, etc.)?
4. Are boundary conditions taken into account when checking incoming data in methods and controllers?
5. How are errors logged and how are they generated and delivered to the client?
6. How does the event-loop work (is there a thread blocking somewhere)?
Our advice - look at the code, ask yourself these questions, clear, simplify and improve its quality.
June 15, 2020