32 lines
1.2 KiB
Markdown
32 lines
1.2 KiB
Markdown
---
|
|
title: >
|
|
Planning first or reviewing last?
|
|
pubDate: 2023-09-02
|
|
permalink: >-
|
|
archive/2023/09/02/planning-first-or-reviewing-last
|
|
tags:
|
|
- code-review
|
|
- pair-programming
|
|
- mob-programming
|
|
---
|
|
|
|
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.
|