daily-email: add 2023-09-02
Planning first or reviewing last?
This commit is contained in:
parent
1b6ab19dcd
commit
3137670abc
31
src/content/daily-email/2023-09-02.md
Normal file
31
src/content/daily-email/2023-09-02.md
Normal file
|
@ -0,0 +1,31 @@
|
||||||
|
---
|
||||||
|
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.
|
Loading…
Reference in a new issue