2014-02-13
Большинству разработчиков знакомо понятие «технического долга», введённое в обиход с лёгкой руки Ворда Каннингэма. В его понимании технический долг — это разница между идеальным техническим решением и тем решением, которое принимается сейчас. За эту разницу и приходится расплачиваться позднее: если вы не успеваете обновлять код, с ним будет всё сложнее работать.
Мне нравится определение Каннингэма, но оно относится только к одному виду технического долга. Почти все современные системы ПО построены на различных фреймворках. Эти фреймворки тоже постоянно изменяются, отражая степень осознания тех разработчиков, которые работают над ними. С течением времени образуется технический долг благодаря растущей разнице между тем, какими эти фреймворки задумывались, и тем, как они используются в коде. Вы можете ответить мне, что этот технический долг — добровольный выбор, ведь вы можете не обновлять свои фреймворки. Да-да, конечно. Зачастую цена, которую приходится платить за необновляемый фреймворк, слишком высока.
Долг компетенций
Так что же, если вам удалось оставить технический долг на низком уровне, можно ли ожидать, что систему будет легко поддерживать? Нет. Потому что существует второй вид технического долга. Я назвал его «Долгом компетенций».
На картинке ниже красным цветом обозначены те части кода, над которым уже не работает ни один программист. Это и есть долг компетенций. Обычно долг компетенций возникает в тех областях, в которых работал только один программист, и только он достаточно в них компетентен.
Технический долг растёт с течением времени, если вы не предпринимаете усилий по его уменьшению. Долг компетенций тоже растёт с течением времени. Но между ними есть грандиозная разница: если технический долг растёт быстрее от того, что вы часто вносите изменения в код, долг компетенций растёт от того, что вы перестаёте менять его.
Долг компетенций — типичная проблема многих зрелых систем ПО, где активная стадия разработки уже давно вышла на пенсию. Наверное, поэтому о техническом долге говорят гораздо больше — его сущность гораздо сексуальней.
Снижение долга компетенций
Мне странно слышать, когда люди всерьёз раздумывают над вопросом: действительно ли выгодно разрабатывать в паре, ускоряет ли это процесс? Да не в скорости дело. Настоящая ценность парной разработки состоит в том, что она уменьшает и технический долг, и долг компетенций. В паре программисты знакомятся с гораздо большей частью кода, а, самое важное: их знания дублируются. Точно так же работает и рефакторинг, снижая долг компетенций.
Что на самом деле убивает системы?
За годы своей работы программистом я работал над многими запасными системами (это такие системы ПО, которые приходят на замену старым, и пишутся заново). Я понимаю, что истинной причиной появления этих запасных проектов был образовавшийся грандиозный долг компетенций в старых системах. Как только появляются жалобы, что старую систему невозможно поддерживать, потому что невозможно понять, как она работает — знакомьтесь, это долг компетенций. Да ещё прибавьте к этому классический технический долг с грязным кодом и отсутствием автотестов. Желание всё зарыть в землю и начать писать заново возникает тогда, когда в компании осталось слишком мало тех программистов, которые писали основу для системы, а найти новых разработчиков, которые имеют желание разобраться в коде, нет времени.
К сожалению, замена системы на новую редко является хорошей бизнес-идеей, ведь пользователи ПО не ощутят никаких значительных изменений от этого. Покажите мне пользователя, который хоть раз обратился в службу поддержки с пожеланием «Пожалуйста, сделайте что-нибудь с поддерживаемостью кода».
По иронии судьбы, сам процесс написания новой системы вынуждает разработчиков изучать старую, таким образом, снижая долг компетенции…
В заключение
Люди часто воспринимают разработку ПО как производственный процесс. Это неправильно. Здесь нет конвейерности и чёткой последовательности действий.
Я бы описал процесс разработки как работу бортовой команды, которая днями и ночами вычерпывает воду из тонущего корабля. Одни факторы, вроде бесконечной текучки кадров, помогают кораблю затонуть. Другие, например, рефакторинг, помогают кораблю плыть дальше. Доплывёт ли корабль до точки назначения, зависит только от того, насколько вы справитесь с набегающими волнами технического долга и долга компетенций.
Перевод: Люся Ширшова. По материалам блога Leanway.no.
25 апреля с приходите на IT-фестиваль BitByte в ПетроКонгресс: с докладом о техническом долге выступит Максим Шульга.
