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?
Код-ревью задумано как способ поймать ошибки до продакшена и распространить знание по команде. На практике оно нередко превращается либо в формальный апрув за минуту, либо в переписку на сорок комментариев, где половина про пробелы.
Почему ревью буксует
Слишком большой пулл-реквест. На 50 строках находят логические ошибки, на 1500 находят опечатки. Внимание заканчивается раньше, чем диф. Нет договорённостей о стиле. Каждое ревью заново обсуждает форматирование, длину строк и названия переменных. Не разделены типы замечаний. Автор не понимает, что блокирует мердж, а что просто мнение ревьюера. Ревью приходит через два дня. Автор уже переключился на другую задачу и половину контекста забыл.
Что помогает
Ограничить размер PR. Ориентир в 200 до 400 строк работает почти везде. Большую задачу лучше разбить на серию последовательных PR. Отдать формат линтеру и форматтеру. Всё, что можно проверить автоматически, не должно попадать в комментарии человека. Помечать серьёзность замечания явно. Простая схема: blocker, если без этого нельзя мерджить, question, если непонятно, nit, если это вкусовое и необязательное. Это снимает большую часть конфликтов, потому что автор перестаёт защищаться от каждой строки. Договориться о сроке реакции. Не «когда будет время», а, например, в течение рабочего дня.Писать описание PR для человека, а не для галочки. Что меняется, зачем, что проверено, на что смотреть внимательно.
На что смотреть в первую очередь
Полезно идти по приоритету, а не сверху вниз по дифу. Правильно ли решена задача вообще. Иногда код безупречен, но решает не ту проблему. Граничные случаи: пустые значения, ошибки внешних вызовов, повторный запуск. Безопасность и работа с данными пользователей. Читаемость для того, кто откроет этот файл через год. И только потом стиль и мелочи.
Про тон
Замечание к коду легко читается как замечание к человеку, особенно в тексте и особенно между людьми, которые мало общаются лично. Помогают простые формулировки: вопрос вместо утверждения, «мне кажется, здесь может упасть при пустом списке» вместо «ты не обработал пустой список». Это не вежливость ради вежливости, а способ сохранить обсуждение по существу. Ревью хорошо работает, когда обе стороны считают его совместной проверкой решения, а не экзаменом. Всё остальное это уже вопрос размера дифа и настроек линтера. А у вас в команде есть договорённость про размер PR и сроки ревью, или это регулируется само?
Share
