Костыли, протухший код, трагедия общин и устаревшие технологии

"там есть довольно элегантный костыль,

я бы сказал, трость"

Поток созания

Костылинг

Когда я возвращаюсь к разработке своего кода,
который я не комментировал

Бывает, решаешь какую-то проблему, копаешь вглубь и находишь костыль (в том числе собственный) быстро решающий какую-то локальную проблему, но вносящую еще несколько в других местах. Каждый раз смотрю и думаю, что же мешало решить проблему, ведь это очевидно. Это как темная комната и светлая улица: видно только с одной стороны.

Грешновато

Первая проблема от недостатка опыта, информации, внимания. Но бывает мы идем на осознанное преступление. Мы делаем допущение, аккуратно его описываем и выделяем ярко оранжевыми FIXME/TODO. Но бывает что такая же проблема всплывает где-то ещё - костыль аккуратно копируется вместе с все тем же оранжевым описанием. В этом месте нужно резко остановиться. Ни в коем случае нельзя умножать один и тот же костыль - его нужно срочно инкапсулировать, старый вариант удалить или пометить аннотацией deprecated, в комменте написать правильный путь, а внутри бросать exception и запись в лог, чтобы не дай Б-г кто-нибудь не использовал.

Code decay

Отсутствие контроля за качеством кода заметно снижает качество нового кода. Но что делать со старым? Он неизбежно протухает, даже если в него не вносятся изменения: подходы со временем меняются. Роберт Мартин в своем "чистом коде" сформулировал очевидную истину: Хорошо написать код недостаточно. Необходимо поддерживать чистоту кода с течением времени. Все мы видели, как код загнивает и деградирует с течением времени. Значит, мы должны активно поработать над тем, чтобы этого не произошло. У бойскаутов существует простое правило, которое применимо и к нашей профессии: Оставь место стоянки чище, чем оно было до твоего прихода. Если мы все будем оставлять свой код чище, чем он был до нашего прихода, то код попросту не будет загнивать. Чистка не обязана быть глобальной. Присвойте более понятное имя переменной, разбейте слишком большую функцию, устраните одно незначительное повторение, упростите сложную цепочку условий.
Представляете себе работу над проектом, код которого улучшается с течением времени? Но может ли профессионал позволить себе нечто иное? Разве постоянное совершенствование не является неотъемлемой частью профессионализма? (Кстати, интересное обсуждение этой цитаты).

Это реально работает: проект можно аккуратно переписать, начав с расчистки эпсилон-окрестности, участки кристаллизации в океане хаоса. Именно так произошло с моим первым реальным проектом. Сейчас меня реально начинает корёжить если я встретился с какой-то неочевидной вещью или проблемой и не поставить маркер и комментарий с описанием (почему-то приходит ассоциация с сошедшей лавиной и расстановкой флажков поисковой командой), чтобы потом легко вернуться к решению проблемы и максимально быстро восстановить контекст проблемы.

Владение кодом

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

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

Устаревшие технологии

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

Один из примеров - застревание в устаревшей технологии. Когда-то технология идеально решала задачи (быть может до сих пор решает). Но с тех пор индустрия ушла, опять же не обязательно вперед. И вот уже тяжело найти людей на вакантые должности, а мегаLOCи старого кода нужно как-то поддерживать. А расчищать Авгиевы конюшни никому не хочется. Рано или поздно это заканчивается выбрасыванием всего этого богатства и тотальным переписыванием. С астрономическими затратами - кому-то рано или поздно придется платить по долгам.