Технический долг старого кода

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

Но есть ещё долг устаревания технологий. Сегодня мы написали код на .NET Framework 3.5, а завтра этот Фреймворк устаревает, и мы уже застреваем в достаточно большом долге. И это реальность, ведь в популярности растёт .NET Core. А стоит устареть паре или тройке технологий и приложение уже будет проще переписать с нуля, чем заменить один из кирпичиков. 

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

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

К чему я это? Все современные правила хорошего кода учат нас, что их нужно соблюдать для того, чтобы проще было заменять блоки и не пришлось переписывать все приложение. Мой же опыт говорит, что переписывать все равно приходиться, уж такая она реальность. Я сделал несколько редизайнов сайта sonyrewards.com, полностью менялся JS движок и совершался переход с самописного MVC на Razer. И каждый раз переписывать приходилось чуть ли не пол сайта, потому что с редизайном менялся не просто стиль или не посто технологии, а функционал, бизнес-правила и требования.

На нынешней работе компания потратила 3 года на то, чтобы перейти с Silverlight на JavaScript фреймворк Dojo, а теперь идёт разговор о следующем переходе на React. 

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

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

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

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

Это вечная борьба – когда переходить на новые технологии. Если переходить сразу, то дорого, но очень хорошо и приятно сопровождать современные решения. Программисты любят современные железки и программы. 

Если ждать, то будет дешевле. Если объединять обновления кода с обновлением бизнес логики, то это можно делать в одном цикле. 

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

И вот тут большой вопрос – где грань между тем, что можно и нужно переписать как можно быстрее, а что не стоит трогать? Это сложный вопрос, который зависит от множества факторов. Я считаю, что все вопрос ресурсов. Если есть ресурсы исправить сейчас, то почему бы не сделать это сейчас. Может это потому, что я как раз отношусь к тем людям, которые не любят работать со старыми технологиями и предпочитает все свежее. 

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

---

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку уже лайкнули 2 человек

---