Рефакторинг, доступность, быстродействие, тесты: эти вещи объединяет фраза «бизнес не выделит на это время».

Некоторые инженеры почему-то решают, что на рефакторинг или тесты нужно просить время у заказчика. Это ставит их в неловкое положение. Во-первых, это слабая позиция с точки зрения переговоров — вы пришли к заказчику с просьбой, а не он к вам, очевидна ваша нужда. Во-вторых, заказчикам обычно неинтересны или непонятны технические детали, поэтому просьба в духе «мне нужен день на рефакторинг» звучит для них как «мне нужен день непонятно на что вместо важных и понятных улучшений».

Чуть лучше, когда инженеры не просто озвучивают свою потребность в рефакторинге, а подкрепляют её пользой. Например, «мне нужен день на то, чтобы навести порядок внутри системы: благодаря этому я сделаю задачу N за день вместо четырёх, а другим разработчикам будет проще вникнуть в код».

Откуда вообще возникают такие просьбы? По моему опыту, так случается, когда задачи выполняются как можно скорее, жертвуя тестами, качеством кода и чем угодно ещё. Такой подход даёт выгоду только в краткосрочной перспективе, в долгосрочной техдолг копится, замедляет и усложняет разработку. Когда становится совсем невмоготу, разработчики осознают, что маленьким локальным рефакторингом не обойтись, и идут просить у бизнеса время на борьбу с техдолгом.

Более здоровый подход, работающий в долгосрочной перспективе — когда рефакторинг, тесты, документация и прочие технические работы становятся частью любой продуктовой задачи. Не нужно считать рефакторинг или написание тестов отдельными видами работ, которые нельзя сделать в рамках какого-то улучшения продукта и на которые нужно выделять отдельное время. Заложите эти работы в оценку продуктовой задачи и просто сделайте их вместе с задачей. Тогда, как говорится, и волки будут сыты, и овцы целы.