Рубрики
Реалии

Big ball of mud

Легаси-говнокод возник почти одновременно с программированием. Термин “спагетти-код” появился в начале 80х, в 90х возникло понятие Big ball of mud, ну и вездесущий Мартин Фаулер написал книгу о принципах рефакторинга легаси еще аж четверть века назад, в далеком 1999. Но если еще лет десять назад Big ball of mud воспринималась как какая-то неприятная, но, в общем-то незначительная деталь, то последние годы она выходит на первый план. В резюме все чаще встречается “не готов готов к легаси” (или, у отчаявшихся найти работу джунов, “готов в легаси”), в вакансиях прельщают отсутствием этой самой легаси (врут!), на встречах с бывшими коллегами за пивом рассказываются кошмары про монолиты 2000 (к счастью — нашей эры) года выпуска.

Почему эта тема начала подниматься последние годы так сильно? В начале 2010х шел быстрый рост энтерпрайз-приложений — рос цифровой мир в котором мы живем: маркетплейсы, онлайн банкинг, возможность заказать госуслугу, оформить страховку, получить выписку из медкарты не выходя из дома. Приложения писались быстро (застолбить рынок), неумело (не было квалифицированных кадров) а о поддержке через 10 лет тогда мало кто думал. И мало кто думал о том что у программного кода есть такой же срок износа как у любой инфраструктуры — жилищного фонда, дорожного фонда. Устаревают технологии, уходят (кто на пенсию, кто в мир иной, кто на руководящие должности, кто за бугор) авторы монолитов, не оставив после себя документации. Наконец, за десятилетие использования накапливается критическое число заплаток, костылей, хаков, протеканий абстракций, так что лепить новые становится все сложнее.

По уму, как и с жилищным фондом, нужен капитальный ремонт. Но он, как правило, не делается. И этому есть много причин, как субъективных так и объективных:

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

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

В-третьих, легаси не на виду. Если в доме течет крыша — можно пригласить проверяющие органы, сфотографировать и предъявить. Но кому и что пойдет предъявлять команда поддерживающая легаси? Протекающие абстракции?

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

Ну и в пятых, вот тут внимание, руководство (уровня компании) плохо понимает что делать. Ну то есть им интуитивно понятно что с энтерпрайзом беда. И начинают искать опытного разработчика, причем желательно настолько крутого насколько позволяет бюджет. Отсюда, в том числе, тянутся нитки к олимпиадным собеседованиям — требования найти лучших — уж они-то разгребут (тут как раз подключаются инфоцыгане с рассказами как освоение нового фреймворка поможет решить все сложности). И вот приходят на проект люди с годами опыта, с охрененными стеками, но и им даже книга Мартина Фаулера не помогает, потому что реальный проект не похож на его умозрительные примеры. Потому что нужно несколько месяцев чтобы только влезть в проект, освоиться с предметной областью и понять вообще что там и как. В лучшем случае удается как-то стабилизировать легаси, прекратив экспонентный рост проблем и полет в бездну. Но переписать все — на это не хватает сил и времени. Чаще всего, в попытках разобраться с проблемами, начинает появляться еще один, на этот раз “надежный” слой абстракций, на который в итоге не хватает сил и он просто добавляется новым слоем грязи в имеющийся Big ball of mud…

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

Шурик

29 ответов к “Big ball of mud”

Работал я в компании, где ит был не основным бизнесом. И был там проект на 1С Битрикс. При трудоустройстве, много говорили о том что всё будем с коллегой переписывать с нуля. Так шло время, и нечего не было переписано. Этот Битрикс съедал зарплату в месяц на сервер и работал медленно и из-за этого, никогда не был на первых станицах поисковой выдачи. Этот Битрикс на старте системы использовал 15Гб оперативной памяти. По эффекту обезьяньей лапы, проект ещё работал некоторое время. Но итог был давно предсказан — проект закрыли (я давно уже там не работаю, а колега иногда приезжал для поддержки проекта). Сколько не пытались объяснить, необходимость всё делать по новому и менять концепцию, всё безтолку. И пока проект работал, конкуренты с нуля вывели на рынок новый похожий проект.
Любой софт со временем, становится многосвязанным и запутанным. Даже если есть попытки всё изначально делать модульно, аккуратно понимая всё эти проблемы в будущем.
Поэтому микро сервисы появилось, в попытке уменьшить спагетти код, но принесли новые проблемы комуникации межсервисной обмена данными.
Наверное поэтому «одна программа должна делать только одно действие».
Нужен опыт, осознание проблемы и умение делать работу проше и в тоже время решать задачу. Я бы даже сказал так что, Всё генеральное — просто. Чем проше тем лучше на долгую дистанцию, ибо зоопарк технологий надо поддерживать, а фреймворк 100 раз устареет, а в зависимостях, к вам придёт вирус или поменяют лицензию и потребуют денег. Только переписывать с нуля, вот единственный путь совершенствования проекта, другого я не знаю метода (много раз проверял это на практике).

3
0

Поэтому микросервисы появилось, в попытке уменьшить спагетти код

Как насчёт того, что между микросервисами точно так же возможен тот самый макаронный ад взаимозависимостей? В конце-концов, отличие микросервиса от класса только в том, что это отдельный exe-шник и нужный метод вызывается через сеть. А так микросервисы появились, чтобы повысить взаимозаменяемость разработчиков

5
0

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

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

И тут мы опять плавно приходим к тому, что работа программиста это совсем не то, о чем говорят инфоцыгани и статеечки с Хабра.

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

Есть легаси, которые вполне можно поддерживать, но такие легаси как правило были из разряда KISS. А вот если это дерьмище писали на псевдо-ООП, где классы, инверсия зависимостей и всякие фабрики писали в стиле «ООП ради ООП», где сама суть классов нивелирована говнокодом и отвратительной архитектурой (или, архитектуры не было вообще), то это — финиш.

5
0

Расскажу чутка о себе. Я за 5 лет именно в ИТ сменил 4 ИТ работы (причины: рост ЗП, голосование ногами, вот это вот всё), и все работал именно с данными. Как кто угодно! Я анализировал xml-схемы гос. контрактов на гос-закупках, что-то грузил, что-то парсил, где-то занимался машинным обучением, там гонял образы дисков и докеры, сям писал бекенд с фронтендом, деньги на инфраструктуру у финансистов выбивал, командами из 10 человек из 3ех компаний техлидил. Стэк — понятен да? R (включая веб-сервисы на пакетах Shiny), Python (ML, бекенд-функции и т.п.), потыкал Go (сделал мелкий проектик по запросу коллег), SQL (Oracle, Clickhouse, Postgres, etc), JS/CSS/HTML, bash/powershell (linux/windows), сейчас я ETL-щик в банке на Informatica и Java (сижу ковыряю, страдаю но вникаю) ну и т.д. Был я в мелких компаниях, где не знают, что такое git, был в очень больших, был в консалтинге, где я видел ИТ нефтяных компаний или телекома саудитов и т.п. К чему — я насмотрелся и натыкался уже разного.

Так вот, я тут как-то часто вижу упоминание ООП, абстракций и т.п. — меня это немного напрягает, т.к. никаких принципиальных преимуществ этой парадигмы я не увидел перед другими стилями. Есть места, где именно ООП вносит удобства… Ну там переиспользовать коннектик к БД, опционально — логгер, или когда пишешь свой-типа-компилятор и тебе надо вырезать всякими хитрыми регулярками из кода текст, вложенные скобки и кешировать содержимое с опцией вернуть взад и т.п. В общем все те моменты, где надо кешировать текущие данные и на их базе переиспользовать методы.

Но сцука зачем ООП как в Джава пихать в каждую бочку затычкой? Свет на ООП клином не сошелся, есть масса других парадигм, которые даже с учетом масштабируемости больше подходят для выполнения задачи…
Ну вот зачем вместо выражения 2 плюс 2 писать calculator.Add(2, 2)?

Есть и масса статей, где говорится, что ООП — это наркомания:
https://ru.hexlet.io/blog/posts/pochemu-oop-eto-ploho
https://tproger.ru/translations/oop-the-trillion-dollar-disaster
https://habr.com/ru/articles/451982/
ну и т.п.
Их писали люди, которые в этой концепции настрадились поболее меня
Тошно ведь становится

4
1

ООП, как мне кажется, стало популярным во времена десктопных приложений. Посмотри на Qt, WinForms или любой другой фрэймворк — там реально ООП на ООП и ООП погоняет, а всякие шаблоны проектирования типа Composite действительно имеют смысл, а не вызывают вопросы из разряда «А зачем это?». Не знаю, как работает современный фронтенд, но на бэкенде сейчас всё буквально состоит из хэндлеров с логикой, а сами сервисы — приложения весьма типовые, так что там на многие ООПшные штуки невольно смотришь скептически, т.к. не все из них применимы

1
0

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

Вездесущий ООП? Никаких исключений? Только статическая типизация?

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

Сложно людям смириться с фактом, что нормальный человек в свободных условиях хорошо напишет (хотя бы комментарии оставит с мини-докой и тестами), а макака она и в GO-клетке override-ами и дублированием кода нагадит так, что мало не покажется.

https://habr.com/ru/articles/709328/
«Поветрия, моды, снова поветрия… Следуя одно за другим со всё более увеличивающейся частотой, они приводят к тому, что многие хорошие и полезные вещи оказываются либо утрачены, либо заклеймены, либо (что самое поганое!) замещены их отрицанием.»

2
0

Ну вот зачем вместо выражения 2 плюс 2 писать calculator.Add(2, 2)?

Конечно понимаю, что это просто абстрактный пример, но в калькуляторе как раз логично прописать отдельные методы для любой операции, т.к. если там инты скалдываются, то по идее нужно предусмотреть возможность переполнения инта/флоатов, скорее всего там еще что-то есть, так что использование методов вполне оправдано, да и в целом методы привязаны к классу что достаточно удобно и сильно косячить с этим трудно. Ну вот зачем вместо выражения 2 плюс 2 писать calculator.Add(2, 2)?
Но в целом я понимаю про что ты говоришь, т.к. знаю реальных адептов «чистого кода» и ООП фанатов, которые умудряются засрать маленький проект так, что его просто никто не может поддерживать кроме них. Но зато есть интерфейсы, наследование и clean code best practices, то что можно было просто разбить грамотно на модули проект с небольшими классами им говорить бессмысленно. Кстати забыл сказать, что жти же люди могут писать по 2-3к строк кода в один файл прост потому что «это удобно»(хз мб кому-то норм но у меня горит очко с этого).

Есть и масса статей, где говорится, что ООП — это наркомания:

Многие просто не понимают, что ООП просто инструмент, который можно использовать а можно и нет

1
0

ООП это необходимость, которая делает код читаемым и по смыслу расфасованным в файлы. Даже в разработка на Си, неоходимо использовать структуры как объекты по смыслу, хотя вроде как бы это фунциональный язык.
Иногда есть необходимость в один файл вместить и 2 тыс строк (длинные функции).
В одно время к меня был файл где было 12
тыс строк. Навигатор кода и именование функции, упрощают навигацию (свой проект).

0
0

Так вот, я тут как-то часто вижу упоминание ООП, абстракций и т.п. — меня это немного напрягает, т.к. никаких принципиальных преимуществ этой парадигмы я не увидел перед другими стилями

ООП — отличная парадигма, она в целом тождественна бытию, в котором мы живём, об этом написано в книге Гради Буча — каждый объект состоит из связки других объектов и все они взаимодействуют между собой, инкапсулируя те или иные частности.

Если ты не любишь ООП, значит негативный опыт связан исключительно с некорректным его применением в проектах: либо шибко умные задроты написали кучу ненужных абстракций (при вполне правильной архитектуре), либо архитектура полностью не ооп-шная, а тупо «классы ради классов».

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

0
0

ООП — отличная парадигма, она в целом тождественна бытию, в котором мы живём, об этом написано в книге Гради Буча — каждый объект состоит из связки других объектов и все они взаимодействуют между собой, инкапсулируя те или иные частности.

Совершенно верно, но как и любая парадигма у нее есть ограничения. Тут и проблема множественного наследования (есть класс человек и класс боевая единица, от кого наследует человек? разрешение множественного наследования — запутанность как в плюсах, отказ от него — извращения с дефалтовыми методамикак в жаве или трейтами в скале). Или проблема с эквивалентностью — если ко временной метке добавить секунду — это таже временная метка просто с другим значением или это уже новая временная метка..
Но главное — ООП не очень хорошо подходит когда надо выразить не объекты а действия над ними — все эти предикаты, компараторы, аггрегаторы — приходится упаковывать в объекты — и код сразу тяжелеет. Поэтому, ИМХО, оптимально сочетать его с функциональщиной. Но функциональный стиль — он требует приличного времени для того чтобы к нему привыкнуть.

2
0

Вот взять в пример инверсию зависимостей — вроде бы теоретически правильная тема, только в проектах на неё все кладут болт.

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

2
0

Пора признать что чистый программист, он же кодер, не может эффективно решать задачи бизнеса. Должно быть образование в соответствующей области, а навыки кодинга должны быть вспомогательными. Отучился на химика, подучил условно петухон и уже можешь заменить собой «святую троицу» айти: аналитика, разработчика и тестировщика. На собеседовании упор нужно делать именно на предметную область.

В случае чисто технических задач должно быть образование в компьютерных науках. И спрашивать нужно именно профильные вещи. В том числе можно помучить литкодом. Но не спрашивать за какие-то новомодные фреймворки и прочую херню.

Вот тогда будет порядок.

1
1

Язык SQL тоже для разрабов так-то не предназначался. Он предназначался для бухгалтеров. А что по итогу? =3 И биоинформатика — вообще отдельная специальность, кстати

1
0

А ты где столько химиков, которые захотят ещё и питон въёбывать, найдёшь?

…да и питон явно не лучший язык, пора ему на покой

1
0

Что значит «захотят»? Накинул им ползарплаты программста — как миленькие побегут.

…да и питон явно не лучший язык, пора ему на покой

Для задач химиков как раз лучший. Это его потом потащили туда где ему явно не место.

0
0

…да и питон явно не лучший язык, пора ему на покой

Вы похоже плохо понимаете какие существуют направления разработки ПО и в какую сторону они развиваются. Для вас обычно существует два варианта: в НИИ за еду или на фреймворках сервисы где вас насилуют потогонками, литкодами и фреймворками. Так вот, в НИИ за еду уже давно никто кроме пенсионеров не работает программистами. Прошареные работяги уже давно устроились в модные конторы вроде NVIDIA где разрабатывают компиляторы шейдеров и прочую фигню за жирный прайс. У них есть будущее, они будут при деле до пенсии. Их предметная область это компьютерные науки и математика, а кодирование всего лишь вспомогательный навык. Так и должно быть. Питон часто используют для научных расчетов и визуализации. То есть это вспомогательный навык для тех, у кого предметная область может быть связана с химией, физикой, геологией и другими науками. Корпоративная разработка сервисов будет неизбежно упрощаться. В процессе вам придется изучать новые «технологии» которые делают то же самое, но с меньшими затратами на разработку и поддержку. Периодически это будут тупиковые направления. Так и будете делать ставки что быстрее устареет, где будет больше денег, но до пенсии скорее всего не доработаете. Получайте пока не поздно нормальное образование, а кодирование оставьте как бонусный навык. Он будет как небольшое конкурентное преимущество на рынке труда.

1
0

Работал в РФ банке. У нас избавлялись от легаси, переписывали Интернет банк. Так же мигрировали системы и данные из старых АБС поглощенных банков в новые/современные.

0
0

>Big Ball of Mud

Да я бы за счастье посчитал писать на big ball of mud, которым его в лиспе понимают. Однако я обычно вижу ООП-мешанину с абстрактными классами на один потомок и непременным кросс-использованием деталей реализации, якобы «архитектуру», а которой чёрт ногу сломит или вообще по функции на файл — это другая крайность.

1
0

Кстати, накидайте адекватных ит-блогеров, а не инфоцыган. Будем безвозмездно их пиарить на сайте.

3
0

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

0
0

В статически типизируемых тоже могут быть проблемы при обилии энтерпрайз паттернов: попробуй походи по стеку репозиторий — абстрактная фабрика — фабрика-хуябрика — абстрактный менеджер — реализация менеджера — собственно реализация и на каждом уровне интерфейс с десятком реализаций (легаси ога).

1
0

Весь мир кроме РФ так делает. Заливаем легаси код в GPT-4 Turbo, он выдаёт код с рефакторингом на актуальных технологиях. Код ИИ легко читается и поддерживается, содержит тесты, содержит комментарии где они должны быть.

0
6

Добавить комментарий

Правила комментирования
  • Любые темы про политику/СССР, войны/СВО или всё то, что НЕ относится к теме сайта (IT), будут УДАЛЯТЬСЯ.
  • Всё, что попадает под возможные нарушения законодательства (экстремизм, призывы, дискредитация, оправдания, возбуждение и т.п.) - тоже.
  • Любые бессмысленные оскорбления участников сайта или тематики сайта будут УДАЛЯТЬСЯ. Если с чем-то не согласны - приводите аргументацию, а не оскорбления.
  • Ссылки на habr.com запрещены по идеологическим мотивам, в случае необходимости размещения ссылки на этот ресурс пишите что-то вроде https://хабр.ком/url
Мы стараемся сделать комментарии ценным информационным материалом, засорять сайт мусорными обсуждениями, никак не относящимися к теме сайта, не нужно! Спасибо за понимание.