Planning first or reviewing last?
Code reviews are something that happens after the code has been written.
Usually, a task is assigned to someone who completes it and makes the code available to their team members before it's merged.
The problem is that if the implementation is wrong, it's already been written, which costs time and money.
If the change needed to be rewritten or majorly changed before it could be merged, as well as being an awkward conversation, it would cost more time and money to do.
Here's the thing
Instead of reviewing the code after it's been written, invest more time into planning how the implementation should work upfront.
What potential solutions exist, and which would work best in this situation?
Write technical design documents and, if needed, create a small proof of concept.
Do this as a team and decide on the approach before any code is written and time or effort is spent.
Then, the person working on the task will have a clearer path, and if you still want to review the code afterwards, you have something to compare it to.
- Oliver
