Техдолг. Часть 3. Обычно техобслуживание - это норма, но почему то в IT это стало долгом Продолжу свой долгострой про техдолг и хочу чуть углубиться в тему из поста 1: мало кто готов летать на самолете, который не прошел предполетное обслуживание мало кто готов ездить на автомобиле с просроченным ТО * оборудование на заводе выгодней обслуживать, чем ремонтировать (ТОиР) Далее список можно продолжить, но мысль думаю ясна: в других индустриях техобслуживание это признак зрелости и качества, а у нас в IT стала долгом и выбиванием бюджетов "на нужное", но "не срочное" (как следствие "нужное" часто проигрывает "срочному") Типовой контраргумент тут против параллелей с ТО: физическое оборудование физически изнашивается, поэтому ему нужно обслуживание и иногда профилактическая замена. А код он физически не стареет - зачем его обслуживать? Это так, код не стареет, но стареют не строки кода, а принятые решения - человеческие decisions, не IT solutions. Даже в самом "умном" варианте deliberate/prudent техдолга мы умышленно принимаем решения сделать быстрее: быстрее выйти на рынок, проверить гипотезу, быстрее заработать. Через 3 месяца среда и приоритеты уже меняются - что было важно тогда, перестало быть соответствовать реальности, то есть буквально старые решения износились, как будто бы какая-то запчасть. Про "износ решений и мыслей" будет следующая часть, а пока хочу еще немного позанудствовать и напомнить, что даже в стандарте ISO, который описывает Software Engineering, все то, что мы чаще называем техдолгом называется maintenance. В ISO/IEC 14764 аж целых пять категорий улучшений (corrective, preventive, adaptive, additive, perfective - как на картинке). По идее, к техдолгу чаще должны относиться perfective, но по факту, думаю если покопаться в бэклогах найдутся все. И это лишь подтверждает мою гипотезу, с которой я завел этот долгострой про техдолг: мы под это определение скидываем вообще любое обслуживание системы, которое видно только технарям и которое поэтому сложно объяснить другим. В следующих постах (хотелось бы перейти на daily режим их выпуска) - от этой затянувшейся вводной к практическим рекомендациям: а что собственно делать и как правильно выбить себе тот самый пресловутый 20-30% объем бэклога на maintenance.