The post has been translated automatically. Original language: Russian
Technical debt is discussed either as a disaster or as something that will be thought about later. Both are incorrect. Debt is a normal tool: you take speed now in exchange for additional work later. The problem starts where no one counts the percentages. Debt can be different, and decisions are also different. A conscious duty. We know that the solution is temporary, we know why, and we know when we will return. This is the healthiest option.An unconscious duty. We did our best, and then we found out what was better. He learns by experience, but is not treated by discipline.Debt from changed requirements. The code was correct for the previous task. It's not anyone's fault, but you'll have to rewrite it anyway.Debt from negligence. They knew how to do it, they did it differently, they didn't write it down. The only type who is not justified by anything.It is useless to mix them in one conversation: the first type is planned, the second trains the team, the third is inevitable, and the fourth needs to be stopped by the process. How to understand that debt has become expensive The evaluation of simple tasks began to grow. A change in one place requires edits in the other three. There are sections of the code that no one but one person wants to touch. Bugfixes regularly lead to new bugs.Onboarding a new developer takes weeks instead of days. The team increasingly responds, "it's easier to rewrite than to fix." The third and fifth signs are the most significant. They mean that no one has the whole system in their head anymore. What really worksWrite down the debt in the same place where the tasks live, and not in a separate forgotten document. An unfixed debt becomes folklore after six months. Link refactoring to tasks that are already included in this code. A separate "sprint for technical debt" almost always loses the fight against priorities. Formulate the cost in the language of business. Not "bad architecture", but "each new integration takes three weeks instead of three days". Distinguish between debt in hot and dead areas. The perfect code in a module that no one has touched for two years is not needed by anyone. To agree that part of the debt remains forever. Giving it all back is also a form of perfectionism. The main idea It is not the duty itself that is dangerous, but its invisibility. A team that knows where its corners are cut and how much it costs manages the situation. The team that finds out about this at the moment of production failure only reacts. And how do you record the technical debt: in the backlog, in the comments to the code, or is it based on the memory of the team?
В любой работе с файлами наступает момент, когда нужна прежняя версия. Именно для этого существуют системы хранения истории изменений.
Работают они просто.
Каждое сохранение это отдельная запись: что изменилось, кто изменил, когда и с каким пояснением. Прежние версии остаются доступными.
Пользы сразу несколько. Можно вернуться к состоянию на прошлой неделе. Можно посмотреть, кто добавил конкретную строку и зачем. Можно вести две версии одновременно и потом соединить их.
Отдельная ценность в пояснениях.
Через полгода никто не помнит, почему выбрали именно такое решение. Короткая запись при сохранении отвечает на этот вопрос за секунды.
Поэтому пояснение стоит писать о смысле, а не о действии. Не поправил файл, а изменил расчёт срока по договорённости с командой.
Ещё одно правило: сохранять небольшими частями.
Одно сохранение на одно логическое изменение читается легко. Одно сохранение на две недели работы разобрать почти невозможно.
Такой подход полезен не только в разработке. Тексты, документы и таблицы тоже выигрывают от истории с пояснениями.
А в ваших пояснениях к изменениям написано, что сделано, или ещё и зачем?
Share
