Что такое легаси и спагетти в коде

Долгое время для меня была очевидной формулировка "легаси" как низкая читаемость кода и невозможность его полноценной поддержки, пока уровень проектов, на которых работаю, не стал повышаться. Казалось бы, можно бы жить спокойно, так как там легаси нет, но не всё так просто, ведь там этим словом называют код, который только устарел, хоть и написан он качественно. Есть даже известная формулировка, типа "легаси весь код, написанный до того, как я пришёл на проект".

Легаси

С английского legacy переводится как "наследие". Бывает так, что меняется команда на проекте и весь предыдущий код объявляет "легаси". Возможно, предыдущая команда гордилась своим детищем, но новой не особенно хочется разбираться в нём и она сделает всё по-своему. Как в поговорке: "Хорошо смеётся тот, кто смеётся последним".

Бывает ли "легаси" своего кода? Многие этим понятием могут обобщить все костыли, внедренные в проект собственноручно, устаревший код, написанный ими же, но лет десять назад, в данном случае наследство оставленное самим себе. Работая в большом проекте и иногда спрашивая у тимлида, а почему некий код вообще работает, можно получить ответ: "Не помню, писал его в молодости".

Не стоит путать слово "легаси" и "гуанокод", хотя применяя и то и другое рискуете оскорбить его автора, если он услышит. Кто раз видел плохой код, никогда не подумает, что это наследие, такой код в принципе трудно поддерживать не через год или два, а уже сразу после написания. Программист, постоянно развивающий свои умения и знания, по факту может считать предыдущий код претендентом на рефакторинг, но для переделки всего кода каждый раз, когда он устаревает, а процесс продолжается, не хватит нескольких жизней. Если программист считает весь свой код идеальным, даже пятилетней давности, то он просто профессионально не развивался это время, всё просто, дело в отношении, а не в коде. Исключением можно считать новую информацию об угрозе безопасности, на этот счёт стоит поднимать не только недавние, но и старые сомнительные участки кода и проверять его на уязвимость.

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

Казалось бы, затронув часть кода, написанную когда-то и кем-то, стоит переделать его окружение под текущие реалии, "обновить", но здесь может быть иного типа ухудшение кода, более высокого уровня. Например, зашёл первый программист в некий модуль, "улучшил" немного кода, затем через год второй, тоже чуть-чуть отрефакторил, по своему видению и новому code style, через два года третий, потом заходит четвёртый и видит мешанину стилей и подходов в одном модуле, как ему в этом разбираться? Каждый из этих программистов молодец, а получилась трудночитаемая неразбериха в коде. Не стоило ли держать в одном логическом блоке единую стилистику и как-то вообще контролировать этот процесс? Скорее всего консистентность блока и последовательность подразумевает, что уж если делать рефакторинг, то единого целого участка.

Спагетти-код и компания

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

Подводя итоги

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

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

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