Легаси-говнокод возник почти одновременно с программированием. Термин “спагетти-код” появился в начале 80х, в 90х возникло понятие Big ball of mud, ну и вездесущий Мартин Фаулер написал книгу о принципах рефакторинга легаси еще аж четверть века назад, в далеком 1999. Но если еще лет десять назад Big ball of mud воспринималась как какая-то неприятная, но, в общем-то незначительная деталь, то последние годы она выходит на первый план. В резюме все чаще встречается “не готов готов к легаси” (или, у отчаявшихся найти работу джунов, “готов в легаси”), в вакансиях прельщают отсутствием этой самой легаси (врут!), на встречах с бывшими коллегами за пивом рассказываются кошмары про монолиты 2000 (к счастью - нашей эры) года выпуска.
Почему эта тема начала подниматься последние годы так сильно? В начале 2010х шел быстрый рост энтерпрайз-приложений - рос цифровой мир в котором мы живем: маркетплейсы, онлайн банкинг, возможность заказать госуслугу, оформить страховку, получить выписку из медкарты не выходя из дома. Приложения писались быстро (застолбить рынок), неумело (не было квалифицированных кадров) а о поддержке через 10 лет тогда мало кто думал. И мало кто думал о том что у программного кода есть такой же срок износа как у любой инфраструктуры - жилищного фонда, дорожного фонда. Устаревают технологии, уходят (кто на пенсию, кто в мир иной, кто на руководящие должности, кто за бугор) авторы монолитов, не оставив после себя документации. Наконец, за десятилетие использования накапливается критическое число заплаток, костылей, хаков, протеканий абстракций, так что лепить новые становится все сложнее.
По уму, как и с жилищным фондом, нужен капитальный ремонт. Но он, как правило, не делается. И этому есть много причин, как субъективных так и объективных:
Во-первых, для капитального ремонта желателен переезд жильцов - в гостиницы ли, в съемные квартиры. Но банк не в состоянии не то, что на месяц, на пару дней отказаться от своего энтерпрайза.
Во-вторых, жилье, как правило, строилось по типовым схемам, во главе с инженером учившимся строить по этим схемам, с соблюдением СНИПов и регламентов. И ввод в эксплуатацию осуществлялся только после проверки комиссией соответствия регламентам. А вот легаси-проект клепался без всякой документации, хаотично, никакими комиссиями никогда не проверялся (неплохо если был хотя бы код ревью, но и код ревью обычно делал человек который сам варился в этом же проекте).
В-третьих, легаси не на виду. Если в доме течет крыша - можно пригласить проверяющие органы, сфотографировать и предъявить. Но кому и что пойдет предъявлять команда поддерживающая легаси? Протекающие абстракции?
В-четвертых, и это следует из прошлого пункта, лечение легаси легко проводить формально - за большие деньги нанимается подрядчик который официально проводит рефакторинг. На деле же, просто меняются стили фронта, пишется какая-то документация - по бумагам все, получите новый проект… а под капотом все те же костыли в куче протухшего спагетти.
Ну и в пятых, вот тут внимание, руководство (уровня компании) плохо понимает что делать. Ну то есть им интуитивно понятно что с энтерпрайзом беда. И начинают искать опытного разработчика, причем желательно настолько крутого насколько позволяет бюджет. Отсюда, в том числе, тянутся нитки к олимпиадным собеседованиям - требования найти лучших - уж они-то разгребут (тут как раз подключаются инфоцыгане с рассказами как освоение нового фреймворка поможет решить все сложности). И вот приходят на проект люди с годами опыта, с охрененными стеками, но и им даже книга Мартина Фаулера не помогает, потому что реальный проект не похож на его умозрительные примеры. Потому что нужно несколько месяцев чтобы только влезть в проект, освоиться с предметной областью и понять вообще что там и как. В лучшем случае удается как-то стабилизировать легаси, прекратив экспонентный рост проблем и полет в бездну. Но переписать все - на это не хватает сил и времени. Чаще всего, в попытках разобраться с проблемами, начинает появляться еще один, на этот раз “надежный” слой абстракций, на который в итоге не хватает сил и он просто добавляется новым слоем грязи в имеющийся Big ball of mud…
Я совершенно убежден что проблемы с легаси будут только нарастать. И приводить к сбоям, факапам, краху проектов с одной стороны и, отчаянию, выгоранию, бессилию айтишников с другой. И рецепта как справиться с проблемой у меня нет. Есть определенный опыт, местами удачный, местами не очень, но о нем в следующий раз.
Шурик
Работал я в компании, где ит был не основным бизнесом. И был там проект на 1С Битрикс. При трудоустройстве, много говорили о том что всё будем с коллегой переписывать с нуля. Так шло время, и нечего не было переписано. Этот Битрикс съедал зарплату в месяц на сервер и работал медленно и из-за этого, никогда не был на первых станицах поисковой выдачи. Этот Битрикс на старте системы использовал 15Гб оперативной памяти. По эффекту обезьяньей лапы, проект ещё работал некоторое время. Но итог был давно предсказан - проект закрыли (я давно уже там не работаю, а колега иногда приезжал для поддержки проекта). Сколько не пытались объяснить, необходимость всё делать по новому и менять концепцию, всё безтолку. И пока проект работал, конкуренты с нуля вывели на рынок новый похожий проект.
Любой софт со временем, становится многосвязанным и запутанным. Даже если есть попытки всё изначально делать модульно, аккуратно понимая всё эти проблемы в будущем.
Поэтому микро сервисы появилось, в попытке уменьшить спагетти код, но принесли новые проблемы комуникации межсервисной обмена данными.
Наверное поэтому "одна программа должна делать только одно действие".
Нужен опыт, осознание проблемы и умение делать работу проше и в тоже время решать задачу. Я бы даже сказал так что, Всё генеральное - просто. Чем проше тем лучше на долгую дистанцию, ибо зоопарк технологий надо поддерживать, а фреймворк 100 раз устареет, а в зависимостях, к вам придёт вирус или поменяют лицензию и потребуют денег. Только переписывать с нуля, вот единственный путь совершенствования проекта, другого я не знаю метода (много раз проверял это на практике).