Взаимосвязь между теорией разбитых окон и техническим долгом

В этом месяце мне удалось немного поработать с сайтом, который разрабатывался мною несколько лет назад. Сайт делался аккуратно, адаптивно, современно. В итоге он был успешно сдан клиенту, который долгое время был доволен его работой. Позднее, как потом выяснилось, всякими сторонними разработчиками (какие-то фрилансеры, интеграторы и пр.) в этот сайт вносились свои различные доработки и вот, к моему удивлению, он снова попал мне в руки на доработку и исправление всего подряд. Прямо какой-то круговорот кода в природе.

То что я увидел меня неслабо разочаровало. Вся аккуратность, стабильность и скорость сайта была грубо поломана. В системе было множество чьего-то дополнительного несвязного друг с другом кода, части которого написаны в разном стиле и с кучей левого мусора, что приводило к большому количеству конфликтов в JS и CSS, а консоль разработчика в браузере пестрела большим количеством вываливающихся ошибок. По коду было видно, что он дорабатывался множеством разных людей, часть из которых явно работала с почасовой ставкой и в стиле (в цензурном варианте) "тяп-ляп и в продакшн". И судя по всему, по мере изменений в коде, беспорядка в нем становилось все больше и больше.

В общем вся эта ситуация мне напомнила Теорию разбитых окон, но только со стороны разработки программного обеспечения.

Пару слов о самой теории разбитых окон

Оригинальное название теории разбитых окон происходит из описанного авторами абстрактного примера с оконными стеклами: "Если в здании разбито одно стекло и никто его не заменяет, то через некоторое время в этом здании не останется ни одного целого окна". Подробнее про эту теорию полно материала в интернете.

Если кратко и универсально, то в какой-то степени смысл данной теории, можно трактовать как "попустительство в плане беспорядка, приводит к еще большему беспорядку". В общем надеюсь смысл более менее понятен.

Касательно этой теории ведется множество споров, но тем не менее в ней есть определенное здравое зерно для размышлений, чтобы на нее обратить внимание. Взять хотя бы те же проблемы накопления техдолга в проектах, проблема которой имеет много общего с обсуждаемой теорией..

Теория разбитых окон и техдолг

Начну с того, что каждый разработчик сталкивался со сторонним говнокодом и давайте честно, каждый его хоть раз но сам делал, ибо мы не рождаемся сразу супер-пупер специалистами, а постепенно с нуля набираем бесценный опыт. Но даже опытные разработчики всеравно продолжают местами говнокодить. А почему так?

Давайте пока отбросим реально беспрекословные факторы, когда без вариантов нужно максимально срочно что-то сделать. Тут понятно почему приходиться быстро костылить решение, ибо сроки сильно приоритетны. И также понятно, что тем самым в проекте начинает расти техдолг, который по идее надо со временем надо устранять (да-да это те самые вечные временные костыли). Такое бывает ибо таковы реалии.

Но вот если разработчику пришел код на доработку и при этом выделено достаточно часов. Вот тут уже становится интереснее и поведение разработчика может существенно варьироваться.

Если код повсеместно документирован, явно соблюдается какая-то общая архитектура и единство, поддерживается согласованный единый стиль кода, в таком случае разработчик может делать доработку по образу и подобию того кода, который уже написан, тем самым поддерживая единообразие. Во всяком случае так может оказаться проще делать сразу, поскольку на ревью кода халтура или несоответствие общему стилю может быстро выявиться и все придется будет вылизывать и переписывать заново. Т.е. есть определенный барьер для внесения в код низкокачественного кода.

И представим случай, когда пришел проект, в котором местами много ужасного кода, нет единообразия, нет поддержки каких-либо стандартов, документации (типа когда-нибудь потом напишем), а размер техдолга вырос до неприличных размеров. Тут разработчик видит, что всем особо плевать на качество кода и в таком случае появляется соблазн побыстрому наговнокодить решение и закрыть задачу, ибо нет особого желания тратить время на то, чтобы раскопать весь этот говнокод. Да и какая мотивация тратить время и делать что-то чисто, там, где уже все засрано и всем плевать на это?

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

В случае с моим примером, который я привел в начале статьи, все шло по канонам этой теории, где в изначально чистый проект, один сторонний разработчик немного наговнокодил. Проект уже стал чуть грязнее, а так как не было того, кто бы это мог проконтролировать, эту кучку говнокода никто не убрал и она стала частью проекта. Следующие разработчики, каждый раз что-то дорабатывая, оставляли свою уникальную кучку говнокода. В итоге, весь код засран так, что киберассенизаторский рефакторинг такого проекта становится достаточно сложной и дорогостоящей задачей.

Заключение

Можно много спорить на тему практической применимости этой теории на практике, особенно в разработке программного обеспечения. Но ведь мы все с вами так или иначе сталкивались с проблемами техдолга. И эти проблемы вполне реальны. И накопление техдолга также является вполне реальной, а не теоретической проблемой, которая по мере достижения критической массы приводит к большим сложностям в поддержке этого кода.

Поэтому такие меры, как кодревью, стайлгайды, документирование и пр., являются хоть местами занудными, но очень важными в плане адекватной и комфортной долгосрочной поддержки кода.