A code review means having a piece of code read by someone else before a milestone, by a teammate or by yourself with a fresh eye, so as to catch the defects an outside reader spots at once and the author, too close to the work, no longer sees.
In the project
A review is not looking for perfection. It targets the obvious defects and the critical areas of the firmware: interrupt handling, the state machine, safety functions. The practice that holds up on a project is a cross-review at every milestone, between teammates at the very least and with the supervisor ideally, short but regular, recorded as a quality step (see safety and quality). It is also a powerful way to learn, since reading other people’s code is how you get better. That still takes the ability to find your way into a program you did not write, which is itself something to learn (in C++, in MicroPython).
See also
- Safety and quality — code review as a quality practice
- Firmware — what reviews mostly look at
- State machine — an area of code to read first
- Reading a C++ program — the reading method, a prerequisite for reviewing
- Reading a MicroPython program — the same method on the MicroPython side