|
|
|
|
|
by snorberhuis
1861 days ago
|
|
I always suggest TODO's to be replaced during a Code Review by:
1. A ticket number that will be picked up shortly if should still be part of a larger change. In a healthy team, this is done within two weeks and you know where to perform changes when you pick it up.
2. You do not add a TODO, but explain your current understanding of what is wrong and what should be done. This way you can refresh the knowledge if it ever again is touched. With a simple TODO, this knowledge is usually not writtend down. |
|
The kind of TODO you're talking about is splitting a ticket into parts so you can hit an artificial deadline (ie, it's no longer 'done done', it's just 'done'). If the artificial deadline is your boss, then we're in a bad place. If it's another team needing a feature, that's pipelining and that's often okay.
For the TODOs that make it to PR without human error, I write most of them for the next person who adds functionality to an area, to either encourage them to do so or at least not make things worse. But sometimes it's for the person who hits the Rule of 3.
Those TODO's should be addressed in six months, not two weeks, and having someone call me on them in a PR is not particularly helpful. No, I'm not going to quadruple the scope of this story because you don't like the word TODO.