I'm sure everyone who has ever done code reviews will have bumped into a situation where the design of the code is not good enough. Even worse, many times the code took a couple days to develop and we've already invested quite a lot of time to build a solution.
What do you do when this happens?
Let it slide and allow the bad design eat the productivity in little pieces for the coming months?
No.
You can point out those design problems and hope the author is able to rewrite the design in a timely manner. But that requires you to check up on the pull request later which causes context switching between your own development tasks and the review ultimately destroying your productivity for a time being.
Even better would be to call a meeting and solve the problems by pair programming with the author. Fix the issues immediately, commit, approve, merge and move on with our lives. But this is not always easy if there's no prior experience working with the other developer. Maybe the developer rejects the ideas of improving the design.
Whatever we decide, we're already in an awkward situation.
This doesn't have to happen though.
As developers we have to have a sense of smell for bad design. We have to be able to see the trade offs in the choices that we make. That's the first step.
If i find myself in a situation where i can see that my design has problems but i don't see the alternatives i must raise my hand and ask my coworkers to collaborate with me. The worst thing i could do is try to solve this problem alone. This would most likely take a lot more time and the result would still suck.
When i'm 1-2 hours in to development:
- I already know something about the problem i'm solving.
- I haven't yet written that much code. We can try alternative approaches and experiment.
- Changing the direction is possible.
When i'm 3 days in to development:
- I'm already feeling the pressure to deliver.
- I'm already commited into the poor design i wrote.
- Changing direction may require me to discard the work done for the last 3 days.
Identifying the limits of my own knowledge is crucial. But also having that sense of smell to see that there has to be better ways and not ignore that feeling. Taking initiative early on to collaborate with other developers will save time and money. That's how real teams develop software.
Top comments (0)