Комментарии 111
Но если изначально система плохая, собранная из уже упомянутого выше, но построена на микросервисах, независимых частях — то все становится проще:
часть команды добавляет новые фичи, а другая — занимается переписыванием старой части. Интерфейсы между микросервисами не трогаем.
Пожалуйста, поправьте, если что не так.
Вот в этой статье (https://habr.com/ru/company/southbridge/blog/512268/) описаны вполне реальные случаи, когда люди даже о Докере не хотят задумываться. Порой инерционность человеческого мышления впечатляет. :)
Теперь и для себя и для других можно сформировать совет на будущее :)
Если строите MVP из говна и палок, то не побрезгуйте и микросервисами — это сэкономит другим программистам и бизнесу много сил, денег и времени. Просто пожалейте их!
*при условии, что проект продолжит свое существование и после MVP
Что грамотная архитектура, что микросервисы это +время и если цель из говна, палок, лишь бы было что на конфе ЦА показать, то это все идет лесом.
Ну и в целом стартовать проект с микросервисов может быть в разы дороже, чем монолит с последующим разделением, так как правильно разрезать на микросервисы на этапе идеи могут далеко не все. А перегруппировывать микросервисы тот ещё квест
Вы слишком безапелляционно подразумеваете, что монолиты — это плохо. И монолиты, и микросервисы — вполне оправданы в различных ситуациях. И да, где-то работают монолиты, просто потому что переписывать не имеет смысла, ибо это не окупится никогда. Микросервисы имеют свои подводные камни и набор быть очень внимательным при выборе именно такой архитектуры.
Это действительно так. Разные подходы — разные задачи. Не подразумеваю, а полностью соглашаюсь с вами) И еще раз повторяю, что совсем не профи в данной теме, просто излагаю свои мысли.
Возможно, у компании есть своё Legacy, которое отлично работает, управляется. И впихивать туда тот же Kubernetes — это просто дополнительные и лишние боль и страдания. Или, например, если это какой-то маленький проект — у него небольшие нагрузки или в принципе не очень много денег и ресурсов. То его тащить в Kubernetes нет никакого смысла.
И у нас Павел Селиванов не раз и не два говорил на конференциях и интенсивах, что если вы задаетесь вопросом: «Нужен ли мне Kubernetes?», то скорее всего он вам не нужен.
вы задаетесь вопросом: «Нужен ли мне Kubernetes?», то скорее всего он вам не нужен.
Несколько раз на работе задавались вопросом "нужен ли нам докер". И так взвешивали, и эдак. Пришли к выводу, что он нам не нужен. То есть в принципе с ним было бы сравнительно просто (проще, чем сейчас) решать некоторые задачи тестирования, но переписывать под него экосистему сборки… ради чего?
P.S. У нас монолит.
Вы не поверите, но до сих пор довольно многие компании работают с монолитами.
Вы так говорите, как будто микросервисы это идеальное решение всех проблем.
Кроме того что эта архитектура в некоторых случаях может решить какие-то проблемы, во многих случаях она может создать больше проблем чем решить их.
Я часто вижу что микросервисы применяются вообще не к месту.
То что в монолите решается джойном по таблице (по условию более сложному чем по id), то в микросервисе эта задача становится очень и очень сложной.
когда люди даже о Докере не хотят задумываться
Я выпилил докер с проекта 3 года назад.
Докер это не только новые возможности, но и новые затраты на поддержку докера и решение проблем с докером. Это не всегда оправдано и зависит от разного Один у вас проект или 50. Одна история когда у вас один проект и одна команда, а другая история когда у вас на одном и том же железе размещено 50 проектов.
Этого можно достигать и другими средствами. Сборкой deb/rpm/… пакетов, образами виртуалок, система контроля типа ансибля/паппета/ююю, другими контейнерными системами, образами виртуалок. Баш-скриптами в конце-концов (которые и для докера обычно нужны).
А как же поддержание единой тестовой и прод среды, автодеплой
Ну много вариантов есть — ansible например.
Но сейчас я скажу одну вещь, после которой у вас наверно взорвется голова )))
Раньше я использовал ansible, но потом перешел на Makefile y bash-скрипты.
Пишу «make deploy» и все готово, деплой на тестовый сервер «make deplytest», запуск тестов «make test».
Есть еще CI куда на котором тесты запускаются автоматически после каждого комита, и также автоматически деплоится на тестовый сервер.
Я не претендую на универсальность решения. Зависит от многих факторов — масштаба проекта, количества проектов, размера команды, проекты живут на своем железе или делят общее и так далее.
"make deploy" может создавать виртуальный сервер по названию ветки в гите, например, feature-123.dev.example.com
Бесспорно, на небольших проектах это имеет место, но при росте сложности проекта и увеличении размера команды такие решения начинают существенно проигрывать тому же докеру.
IMHO сложность использования docker несколько преувеличена.
На моём опыте, большая часть его противников или не хотят изучать технологию, или не хотят ничего менять в своей работе — им и так хорошо и всё устраивает, в том числе много ручных операций и портянки скриптов и/или YAML, т.к. это делает их незаменимыми.
К сожалению аргументированный отказ от docker на основе именно его технических минусов — очень редкое явление, в основном аргументация на уровне «я слышал/читал что это плохо», без личного опыта и понимания технологии.
Я, думаю, лично у меня опыт достаточный. Кажется, с 2015-го. И с тех пор у меня скептицизма стало побольше.
Как по мне, то многие рекламируемые возможности докера предполагают очень большой объём допиливания напильником. Ну вот банальная задача: развернуть на одном хосте несколько веб-проектов на php под разными доменами. В "олдскульных" практиках дошло до того, что просто файлы скопировать куда-то в /www/example.com и всё работает. А с докером/докер-композом повозиться надо: какой-то "ингресс" установить с возможностью слушать события докера (читай — рутовыми правами), существующие "монопольные" средства развертывания приложения в докере (bash, docker-compose.yaml, ansible тот же) метками утыкать, с /etc/hosts поработать.
Доступ к docker socket в RO, это всё-таки не рут права (RW — можно так назвать).
Бонусом докера является возможность не доставлять те же модули php на конечные машины, это не боль при условии, что у вас один сервер и свежий проект, а когда их несколько и проект требует старый php, которых нет в свежих дистрибутивах, или состав этих модулей периодически меняется.
В таком случае вы получаете сильное упрощение в Operations с не не очень существенным усложнением в Dev.
Кроме того очень простым становится откат и обновление.
А если выйти за рамки php там вообще начинается дивный новый мир.
Сильно отличается от того, что я написал?
А с докером/докер-композом повозиться надо: какой-то "ингресс" установить, существующие "монопольные" средства развертывания приложения в докере метками утыкать, с /etc/hosts поработать.
С этим я года три-четыре назад разобрался, причём со своим CA (LetsEncrypt хорош только для публичніх доменов/сайтов). Но вот удобным это назвать язык не поворачивается. k8s, пожалуй, даже удобнее в этом плане, жаль что тащит кучу ненужного для подобных задач.
Если проект один, то можно просто образ nginx-proxy сюда включить (но нужен ли он вообще тут?))
Проект может быть, но обслуживать несколько доменов, банально example.com и api.example.com
/etc/hosts вообще тут не причем (метка же есть).
nginx-proxy начал хосты прописывать по меткам? раньше с dnsmasq нормально было вайлдкрад домены, но с systemd увы нет.
всего два-три параметра в compose-файле проекта
На каждый "роут". Ну и сеть не просто указать в каждом контейнере, но и "глобально" прописать как external. И это если запускаемые проекты согласованы. А не, например, один с одной работы, а другой — с другой.
Может, вопрос в bus-factor данного решения и стоимости поддержки.
Ну так в том то и вопрос, что стоимость поддержки докера в нашем случае оказалась выше. Не вижу как это может влиять на bus factor.
но при росте сложности проекта и увеличении размера команды такие решения начинают существенно проигрывать тому же докеру.
Это упрощение. Факторов больше чем размер команды, но это конечно один из них.
в том числе много ручных операций и портянки скриптов и/или YAML
Ну а чем докер принципиально отличается от bash скрипта, Dockerfile это по сути и есть плюс минус bash-скрипт.
На моём опыте, большая часть его противников
Я не противник докера. Более того я его использую для тестирования bash-скриптов. (Хотя могу и без докера, через vagrant). Но я против бездумного пихания докера и микросервисов в каждый проект.
или не хотят изучать технологию, или не хотят ничего менять в своей работе
Я выше написал, что изначально докер был в проекте. Так что это не про нашу ситуацию.
Ну так в том то и вопрос, что стоимость поддержки докера в нашем случае оказалась выше. Не вижу как это может влиять на bus factor.
Docker это всё-таки стандарт, в отличии от самописных скриптов, который со временем разрастаются, поэтому найти на рынке специалистов, которые его знают будет проще.
Это упрощение. Факторов больше чем размер команды, но это конечно один из них.
Основные факторы это:
- Сложность проекта
- Размер команды
- Необходимое значение Time to market
Из них как правило вытекают размер инфраструктуры, которую нужно поддерживать и сложность развёртывания.
Плюс с ростом команды появляется класс проблем, связанный с тестированием всех изменений, которые делаются в проекте, откуда появляется необходимость простого развёртывания нескольких веток по необходимости.
Причём чем быстрее нужно вносить изменения, тем нужнее системы CI/CD, а в большой инфраструктуре сложного проекта docker сильно облегчает процессы тестирования и деплоя, особенно когда серверов не 2 и не 10.
Ну а чем докер принципиально отличается от bash скрипта, Dockerfile это по сути и есть плюс минус bash-скрипт.
Он принципиально отличается от bash, ansible и т.п. тем, что у вас нет предыдущего состояния (точнее оно всегда известно — это состояние образа с которого вы начинаете), поэтому он исключает класс проблем вида «для установки этой библиотеки для этой зависимости, мне сначала нужно откатить предыдущее», а так же ситуации, когда в среде исполнения приложения кто-то из администраторов и разработчиков что-то поправил руками, но не задокументировал и не вписал в тот же ansible.
Другими словами с docker у вас всегда конфигурация системы начинается с чистого листа.
Я не противник докера. Более того я его использую для тестирования bash-скриптов. (Хотя могу и без докера, через vagrant). Но я против бездумного пихания докера и микросервисов в каждый проект.
Определённо, затаскивать в любой проект любую технологию, потому что это «стильно, модно, молодёжно» не стоит.
Но многие приносят docker в проект для более простого решения класса задач, которые вас, как программиста могут не касаться.
В разрезе python / django это может быть установка пакетов, требующих компиляции нативных расширений, когда у вас 50 серверов это становится болезненно и долго — проще один раз собрать docker image, посте чего скачать его на все сервера и запустить тем же ansible.
При использовании ansible без docker он очень быстро разрастается и сложность его понимания и входа для нового DevOps/SRE становится существенной.
Не всё что вам кажется «бездумным пихаением» может быть этим на самом деле, возможно просто с вашей точки зрения это только кажется.
Я выше написал, что изначально докер был в проекте. Так что это не про нашу ситуацию.
Не исключаю, что для вашего проекта эта технология не нужна, а волосы людей, ответственных за поддержку проекта со стороны инфраструктуры вместе с теми, кто отвечает за деплой, мягкие и шелковистые.
Но всё это может быть не так в иных ситуациях.
Он принципиально отличается от bash, ansible и т.п. тем, что у вас нет предыдущего состояния (точнее оно всегда известно — это состояние образа с которого вы начинаете)
Это если volume не используется. А вот с ними начинаются танцы с бубнами на задачах типа папка из одного образа должна быть доступна в другом. В чистом докере небольшая проблема volumes-from, но вот в docker-compose v3 уже проблема — штатная фича докера не поддерживается. И множество таких нюансов.
Вам никто не мешает использовать bind mount и не использовать volumes.
Но да в таком раскладе могут быть нюансы.
Как с одного контейнера сделать bind mount на другой?
Прежде всего она и гарантирует, что у веб-сервера (nginx например) с read only доступом и приложения с read/write один набор файлов. При билде образа приложения где-нибудь в /app/public формируется source of truth статических файлов для раздачи через веб, а веб-сервер монтируется к нему с R/O. Это вы считаете костылём?
Раньше я использовал ansible, но потом перешел на Makefile y bash-скрипты.
Не взорвалась. И то, и то декларативно на высоком уровне и императивно на низком ) Мне проще обычно bash скрипт написать.
не все админы, из-за личных предубеждений и инерции, готовы переходить на микросервисную архитектуру.
Сразу скажу, что нет ничего плохого в монолитах
Ну т.е. с одной стороны вы вроде как не видите ничего плохого в монолитах, а сдругой — первыми же ассоциациями с монолитом являются "предубеждений и инерция". Забавно :)
между микросервисами не трогаем
В этом и проблема, организовать микросервисы так, чтобы добавление фичи затрагивало наименьшее количество точек. Ошибка в архитектуре это не только внутряняя кухня микросервиса, но и публичные контракты. Править которые, даже в микросервисах — большая боль.
Ваше предложение из первого комментария верно, только слово «микросервисы» стоит заменить на модули, и грамотно декомпозировать приложение на независимые модули сложно.
Микросервисы лишь проводят чуть более жёсткие границы между модулями, но и нарушения таких границ фиксить сложнее.
А вот когда у вас есть грамотное декомпозированное приложение, и вам нужно масштабировать разработку, ещё меньше конфликтов в коде, добиваться CI/CD(нормального CI, а не «пайплайн настроить»), можно задуматься о микросервисах для большего контроля за границами модулей.
Время идёт, инфраструктура совершенствуется, конечно, но микросервисы по прежнему несут за собой значимые накладные расходы.
Проблема монолитов в том, что если в нем потопталось 3-4 поколения программистов, то заложенная изначально в монолит декомпозиция бывает нарушена почти везде.
И мы имеем, когда из представления сразу обращаются к БД, минуя слой бизнес-логики.
Ну или размазанную бизнес логику между БД и приложением.
Когда в приложении вызывается несколько ХП, причем их выполнение зависит, от того, какие данные записало приложение во временные таблицы.
В этом плане «тупое» следование принципам микросервисной архитектуры, дает хоть какой-то барьер, для таких «изысков».
Грубо говоря, там где микросервисы сразу «падают» и обозначают «есть проблема».
Монолит может работать годами, а потом при не значительном изменении упасть, так, что добавление новой фичи, приведет к переписыванию половины приложения.
P.S. Прошу прощения — накипело :-)
Проблема монолитов в том, что если в нем потопталось 3-4 поколения программистов, то заложенная изначально в монолит декомпозиция бывает нарушена почти везде.Вы исходите из предположения что микросервисы которых потопталось 3-4 поколения программистов лучше чем монолит в котором потопталось 3-4 поколения программистов, в чём я лично не уверен.
С одной стороны — да, границы чуть более явные, с другой — как я писал, нарушения границ сложнее фиксить + накладные расходы на построение распределённого приложения.
В этом плане «тупое» следование принципам микросервисной архитектуры, дает хоть какой-то барьер, для таких «изысков».Думется, причина тут в том, что при проектировании микросервисной архитектуры(особенно после монолита), разработчики уже встречались с проблемами, частенько это уже не новый проект, и хоть каким-то принципам да следуют, а монолит часто делают тяп-ляп MVP быстрее, «потом перепишем».
P.S. А что до:
И мы имеем, когда из представления сразу обращаются к БД, минуя слой бизнес-логики.Я немного наслышан про некоторые конторы, и о том, чего они творят с микросервисами, тоже волосы дыбом встают. Десятки микросервисов на запрос, сотни микросервисов при условии что в компании всего с сотню разработчиков, отдельный микросервис который ходит в БД с которым общаются все-все сервисы и пр.
Ну или размазанную бизнес логику между БД и приложением.
Т.е. достаточно мал.
Соответственно «переписать» его проще.
Монолит, он на то и монолит, что выделить из него какие-то слои невозможно.
Насчет поколения программистов.
В микросервисной архитектуре они не гадят в одну кодовую базу годами.
А гадят в маленькие изолированные приложения.
И их можно просто выкинуть и полностью переписать.
Насчет, того, что при любой архитектуре можно сделать «Адъ и Израиль» — я с этим не спорю.
Но если с монолитом у вас один большой кусок говна, с которым не понятно что делать.
То с микросервисами есть много кучек говна, которые можно убирать по одному.
<:o)
В микросервисной архитектуре они не гадят в одну кодовую базу годами.Только в том случае если они изолированны, при плохой архитектуре это не так. А при хорошей и в монолите можно делать независимые модули. По поводу переписывания микросервисов по одному, выше уже писали про публичные контракты.
А гадят в маленькие изолированные приложения.
Чем больше связей, тем сложнее переписывать, и тем более переписывание по одному не поможет их исправить, нужно будет собирать общую картину из многих кодовых баз, и править всю цепочку, разбираясь во всех происходящих при этом событиях и эффектах.
Если для микросервисов это всегда так (by default).
То для монолита — нет.
Здесь могут обращаться к БД прямо из фронтенда, минуя все слои бизнес логики.
Благо JSP/ASP это позволяет сделать. :-)
Вы сделали одно допущение, что в монолите есть «публичные контракты»!Я не делал такого допущения, просто считаю что накладные расходы, сложность проектирования распределённой системы, и сложность правки контрактов перевешивают этот спорный плюс.
Если для микросервисов это всегда так (by default).
Спорный потому, что публичные контракты можно делать в монолите — вопрос желания, и потому, что я видел и микросервисы без
задокументированных публичных контрактов — чтобы глянуть api лезли в код. Так что, при желании можно и…
Формально фронтенд одного сервиса может полезть в базу данных другого. Благо JSP/ASP это позволяет сделать. :-)
Есть огромное количество систем, которые не только про микросервисы не слышало, но и для которых переход на мажорную версию проходит очень болезненно. При этом оборот компании сравним с бюджетом маленького африканского государства.
Вы исходите из ложного предположения, что продуманы хорошо как интерфейсы, так и концепция взаимодействия этих микросервисов. Но если уж понадобилось их все переписать — можете быть на 95% уверены, что и в интерфейсах, и в общей концепции их взаимодействия есть серьёзные проблемы, и переписывать вы будете шило на мыло.
Кроме плохого кода самих микросервисов могут ещё быть:
- плохая система аутентификации
- плохой протокол взаимодействия микросервисов
- плохая система оркестрации микросервисов
- некорректно выстроенная модель сущностей в БД и API
- да банально совершенно непродуманная система логирования
И этот список можно продолжать очень долго, и ни один пункт вы не сможете исправить, если будете переписывать только часть кусочков. В лучшем случае придётся переписать все их по-очереди, и долго жить в переходной схеме.
Отличным примером такого архитектурного изъяна на уровне протокола может служить wire протокол MongoDB: абсолютно ущербный механизм получения кода ошибок привёл к тому, что, фактически, используется вызов команды для записи/апдейта/удаления вместо соответствующей операции, которая нативно есть в протоколе:
Starting with MongoDB 2.6 and maxWireVersion 3, MongoDB drivers use the database commands insert, update, and delete instead of OP_INSERT, OP_UPDATE, and OP_DELETE for acknowledged writes. Most drivers continue to use opcodes for unacknowledged writes.
Так же стоит отметить, что и в монолитных системах точно так же существует понятие интерфейсов и модулей, которые через эти интерфейсы общаются друг с другом. Конечно, это не позволяет взять и переписать какой-то кусок на другом языке, или в другой парадигме программирования (скажем, асинхронный питон вместо синхронного), но не стоит ставить знак равенства между монолитом и неструктурированным спагетти-кодом. Я более того скажу, нормально спроектированный монолит будет проще поддерживать, чем плохо спроектированную груду микросервисов. А уж сколько геморроя вы начнёте огребать, если начнёте задумываться о микросервисной системе, которая не будет сыпать ошибками на каждый чих в сети, и при этом гарантировать приемлемое время ответа… LIFO очереди, exponential backoff, circuit breaker, всякие хитрые политики service discovery, которые позволяют работать системе в сдеградированном режиме — да там целый гигантский ворох проблем, про который никто особо и не думает, когда рассказывают, как"микросервисы всех спасут".
В словосочетании «микросервисная архитектура» главное слово «архитектура», а вот «микросервисная» само по себе не даёт ничего.
часть команды добавляет новые фичи, а другая — занимается переписыванием старой части
Если часть команды переписывает старый код — значит над тех.долгом уже работают, значит все уже не так уж плохо.
Есть ситуации, о которых, как понимаю и говорит автор, когда тех.долгом вообще не занимаются — «работает и ладно»
Так проблема то скорее всего будет как раз в кривых интерфейсах между микросервисами.
Но если изначально система плохая, собранная из уже упомянутого выше, но построена на микросервисах, независимых частях — то все становится проще:
часть команды добавляет новые фичи, а другая — занимается переписыванием старой части.
Это если разбиение по микросервисам было изначально правильным, что с учетом построения системы дендрофекальным способом маловероятно. Вообще по моим наблюдениям самые нормальные микросервисные реализации — именно порезанный монолит. Даже с достаточным временем, потраченным на проектирование правильно разбить приложение на отдельные сервисы с учетом не только интенсивности взаимодействия сервисов, но и частоты изменений разных частей, сильно не просто. Тут как с дорожками на газоне: их не надо делать заранее, а нужно дождаться пока жители сами вытопчут, а затем уложить поверх вытоптанного.
Статья вроде про системное программирование, казалось бы при чём тут микросервисы
Бизнес вообще не понимает: «Ну как так, MVP же работает?». Работает. «А почему новую фичу нельзя вот прям счаз воткнуть?» И с чем сталкиваются многие технические управленцы, они не могут объяснить, в чем конкретно проблема — и самое тяжелое они не могут показать в метрике, измеримой бизнесу, чтобы они понимали, что в текущем состоянии разработка фичи стоит 100 рублей, а в оптимизированном, например, 10 рублей.
Само по себе решение перейти на микро-сервисную архитектуру эти метрики же не родит. Сначала все равно придется объяснить бизнесу, что в условиях ограниченности ресурсов, нам потребуется ХХХ дней чтобы сделать рефакторинг (кстати, это слово бизнесу лучше вообще не говорить). Или же увеличиваем штат и/или увеличиваем время. И только потом, вписавшись в бюджет и в рамки, родив архитектуру, план по «распилу» монолита, затраты на инфраструктуру и тэпэ и тэдэ, мы сможем с какой-то долей вероятности обозначить эти метрики. Допустим получится не 20 дней, а 3 дня. Итого в глазах бизнеса это выглядит как ХХХ дней + 3 дня, что явно больше 20 дней.
И бизнес задает резонный вопрос: «а нафига мне этот твой рефакторинг прямо сейчас? Делайте фичу. А рефакторить эти ваши рефакторы мы будем потом. Обязательно будем! Но потом...»
а нафига мне этот твой рефакторинг прямо сейчас?
Отвечать нужно так:
1. В проекте есть плохой код. Пока он никак не выражается для обычного пользователя, но только пока.
2. Новый функционал пишется поверх старого. Соответственно старые костыли приходится покрывать сверху новыми. Количество плохого кода нарастает.
3. Количество плохого кода рано или поздно приводит к увеличению количества багов.
4. Багов становится все больше, появляются самые неприятные баги — редкие, плавающие, которые сложно воспроизвести, чтобы починить. Старые программисты уходят, новые, банально не могут разобраться во всем этом клубке багов и костылей
5. Самый замечательный этап, который обязательно наступает — это «внезапные» падения проекта. Просто взял, и упал на ровном месте. Проект поднимают — а там ошибка. В итоге банальный запуск проекта выливается в часы нервотрепки, и для программистов и для бизнеса.
6. К этому моменту атмосфера в бизнесе давно испорчена. Бардак, скандалы, поиски крайних. Программистов считают «криворукими», потому что создали такой плохой продукт.
Если команда маленькая, то проект может закончиться просто тем, что пару последних программистов разом уволится, и к очередному падению проекта его просто некому будет поднимать. Ну или новый программист просто не поймет как это сделать.
Либо, если команда большая, то проект переходит в стадию «команда 80% времени чинит бесконечные баги, новый функционал делается со скоростью 1 фича в пол года».
Не смотря на всю печальность ситуации — я считаю, что каждый менеджер проекта, каждый владелец бизнеса должен через такое пройти. Чтобы не было иллюзий, что «чистый код» это какая-то прихоть программистов. Ну и чтобы понимать, что скупой (на сроки в том числе) в итоге платит дважды, трижды и т.д.
Далее возникает вопрос: какими метриками на этом этапе Вы будете подкреплять аргументацию «давайте перепишем на микросервисы»? С потолка возьмете?
не все поддается измерению.
да и если бизнес не понимает зачем чистый код, то время на составление метрик вообще далеко за гранью будет.
Далее возникает вопрос: какими метриками на этом этапе Вы будете подкреплять аргументацию
Это не подкрепляется никакими метриками.
Как уже говорил — любой опытный менеджер должен через это пройти. Тот, кто не прошел — действительно, будет считать все разговоры программистов о техническом долге, о костылях, о легаси который нужно переписать — какой-то фигней, не стоящей внимания.
В такой ситуации можно или сразу увольняться, или расслабиться (в смысле перестать переживать за будущее проекта) и наблюдать за деградацией (ну и набираться опыта — чтобы впредь не оказаться в подобных компаниях).
Всем нам иногда нужен негативный опыт, чтобы до сознания дошел факт о том, что мы делаем что-то неправильно. Менеджеры здесь не исключение. А так как их сфера ответственности намного больше, чем у рядового программиста — то и негативный опыт у них совсем другого масштаба.
В этой ситуации, пожалуй единственным правильным шагом техдира будет убедить и донести до бизнеса/акционеров мысль, что «мы слишком сильно выросли, и если мы хотим расти и дальше, то нам надо увеличивать ресурсы, брать людей, менять подходы». И в этом случае, поверьте мне, чем будут заняты эти дополнительные 2..5..10 человек, будут ли они пилить монолит на сервисы, или будут поэтапно рефакторить существующий монолит, бизнесу будет абсолютно все равно. Он дал карт-бланш и он договорился с техдиром о сроке, когда будет представлен результат.
И вот для этого успешного донесения этой мысли и нужны либо метрики, либо умение убеждать и брать на себя ответственность. Метрик таких я ни разу не видел за 20 лет. Остаются только субъективные аргументы и личная ответственность. Поэтому выводы в этой статье считаю спорными.
Метрик таких я ни разу не видел за 20 летА зачем метрики нужны вообще? Если все так детально разложить (как это у вас получилось) — то есть реально заинтересовать в таком образе действий, то этого же достаточно будет?
И вот для этого успешного донесения этой мысли и нужны либо метрики, либо умение убеждать
Не все так плохо. Когда в проекте куча багов, новые фичи пилятся долго, а программисты постоянно жалуются на код — до руководства все же доходит, что надо что-то делать.
По этому, когда руководство созрело — достаточно просто фразы «так дальше работать нельзя, надо переписывать с нуля». И лично наблюдал ситуацию, когда такая фраза от тимлида сработала. Наняли новых людей + часть людей из старой команды начали параллельно со старым проектом писать новый. Правда, не успел посмотреть, чем в итоге все закончилось — уволился раньше.
Переписать все — это дорого, страшно и больно, но чаще всего другого варианта избавления от дентро-фекальной кучи легаси просто нет. ИМХО
«Что делать?»
1. Не работать в компаниях с плохим кодом
2. Если уж занесло — не переживать, делать то, что хочет руководство, напоминая, что все это закончится плохо (не работая над тех.долгом), и просто наблюдать, как все в итоге умрет.
Владельцы бизнеса тоже должны получать опыт. Так что пусть получают. Вы их предупредили, ну а то, что они вам ответили «работает и ладно, зачем переписывать» — это уже их проблемы.
Автор в начале статьи написал, что код до нового техдира писался абы как, при помощи кучи разных программистов, фрилансеров, заплаток, без погружения в кодовую базу и подобного. «Проблема еще заключается в том, что, так как гипотезы проверяются часто из «la merde» и палок, этим занимаются либо разные программисты, либо программисты работают по остаточному принципу.»
В вдруг с новым техдиром все волшебным образом меняется. Все начинают понимать новую архитектуру, которую предложил техдир и вкладываться в нее. Нет. Так не бывает. Проблема не в наслоении. Проблема в том, что за код нет ответственных людей, как и сам автор описал в начале статьи. Проблема не в легаси, проблема организационная, как мне кажется. У каждого куска кода должен быть долговременный хозяин, который будет его понимать и который будет придерживаться одного подхода. Если все задачи, связанные с каким-то куском функционала будут спускаться ответственному за этот функционал лицу, то, по крайней мере, он не будет делать костыли, потому что уже знает свой код. А будет встраивать новую фичу в нужное место.
Конечно, это должен быть профессионал, который имеет навыки хотя бы абстрагирования и обобщения кода. У него должна быть также какая-то тщательность, чтобы заканчивать свою работу, а не ляпать.
Но также ляпы могут быть из-за организации. Бизнес сегодня говорит: делаем это, 4 часа. Бедный программист не может сделать хорошо задачу за это время. Он делает тяп-ляп. Завтра бизнес говорит: нет, срочно переключаемся на эту задачу, а ту — бросаем. И работа бросается на полпути, назаконченная, наполовину внедренная. Вот так и получается говнокод.
задача техдира, как мне кажется, как раз в том, чтобы выделять адекватное время на задачу или корректировать задачу, чтобы сама задача стала адекватнее. И принимать оптимальные технические решения.
А для этого у техдира должны быть полномочия, по которым он будет делать то, что должен делать. А не как обычный разраб пол года уговаривать директора и быть в итоге посланным ибо и так работает.
Бухгалтеру ведь не говорят мол запиши расход сюда пока, а та придумаем. Или безопаснику — давай этого контрагента одобряй, а там посмотрим. Те кто строят или детали делают физически — могут хотя бы на законы физики сослаться, что мол разрушится изделие, если хреново сделать.
Разрабы в этом плане сильно слабее. Вот вам всем большая зп как вы хотите, но ребенка надо родить за 1 месяц.
Проблема не в наслоении.
И в нем тоже. Точнее, проблема в утрате знаний об устройстве системы. А наслоение усложняет получение его заново.
У каждого куска кода должен быть долговременный хозяин, который будет его понимать и который будет придерживаться одного подхода. Если все задачи, связанные с каким-то куском функционала будут спускаться ответственному за этот функционал лицу, то, по крайней мере, он не будет делать костыли, потому что уже знает свой код. А будет встраивать новую фичу в нужное место.
А потом этого хозяина переедет автобус. Или просто доработать кусок кода потребуется через пять лет после того, как его в последний раз трогали (у нас ведь Legacy — они долго живут). В идеале все это знание должно быть аккуратно записано связным текстом, а не в виде малосвязных кусков в чем-то википодобном, чтобы следующий владелец функционала мог бы пойти и прочитать, что, как и почему так устроено. Вот только делать так почти никто не умеет, а тех, кто может обосновать затраты на такую документацию — тех еще меньше.
Связным текстом, говорите? Это конечно, идеал. Но как на практике его достичь? Есть грубо говоря функция. У нее комментарий, объясняющий, что это такое и зачем. Потом ее правят и комментарий уже некорректен. Комментарий поправить забывают. А он совсем рядом с кодом находится. Буквально на прошлой неделе видел такое у парня, у которого настолько горят глаза при работе, что его никак нельзя заподозрить в небрежности.
Мы сейчас решаем проблему 2мя способами. 1. У нас есть такс-трекер, где ведутся все задачи. 2. Каждое изменение в коде делается коммитом. В начале текста коммита указывается ссылка на задачу или #123, где 123 — номер задачи. Ну, а в самой задаче потом придется порыться.
Проблема одного хозяина кода, конечно, тоже есть. Но и то, что я, допустим, запрограммировал хорошую архитектуру, а потом дают какую-то мелочь другому человеку поправить и он идет полностью вразрез с этой архитектурой, тоже бывает весьма часто. Просто потому что разобраться в чужом коде — это сложная интеллектуальная задача, на которую нужно потратить свои мыслесилы. Так и получается говнокод.
Проблема, что автор уйдет и что дальше делать, конечно, существует.
каждого человека нужно вводить в курс дела. То что дока должна быть это само собой, но с разрабом нужно сидеть и проговаривать что делает каждый класс/метод.
Да это долго, можнно месяц убить. Можно не все сразу, а пояснять как работает часть, по которой сейчас нужно сделать таску.
Но в любом члучае это окупится на долгосрок, так как говнокода бужет сильно меньше.
Невозможно ведь представить, что пришел новый мастер на завод, его запускают в цех с оборудованием в первый день и говорят — ну вот чертеж, пользуй все что хочешь чтоб сделать эту деталь.
Но как на практике его достичь?
Кто бы знал. Скорее всего — специально обученными людьми, которые преимущественно этим и занимаются. Удалось же сделать общепринятым мнением, что тесты (а если проект не совсем мелкий — то и специальные люди, занимающиеся тестированием) практически обязательны.
Еще пол беды когда есть хотя-бы более-менее толковые тесты — по ним можно понять что происходит (хоть и не всегда, часто они делаются больше для галочки — что-бы метрику «покрытие тестами» задрать повыше), без тестов вообще — труба. Смотришь на класс, состоящий из десятка-другого тысяч строк, без комментариев и с «говорящими» методами плана GTJD_000054878964215(...*десяток-другой аргументов*) и возникает непреодолимое желание послать все это к черту и сменить профессию :)
И мы эту концепцию не трогаем, не меняем эту концепцию как минимум год. То есть берём правило не чаще, чем раз в год ее менять, апгрейдить.
Вот это доставило особо. С чего взят такой странный период — год, мне, перелопатившему десятки легаси систем — непонятно. Обычно меняют что-то по необходимости, а не потому, что год прошел.
Узнаваемая ситуация, и это не только про legacy ) когда нанимают нового топа, потому что "надо наладить процессы/сделать так, чтобы у нас показатели выросли", а потом внезапно выясняется, что сделать-то надо, но есть куча ограничений со стороны бизнеса. Вот и крутись как хочешь.
PS: Комикс про программистов огонь! Топ-менеджмент меняют по ходу тоже из таких соображений
Настоящее легаси — это тонны кода, оперирующие коэффициентами, про которые никто не помнит, откуда они взялись. Куски кода и системы на устаревших языках, которых вы не понимаете. Система, построенная на логике, которую вы не понимаете. Потоки данных, ходящих такими путями, которые вы не понимаете. Устаревшее железо в серверных, которое поддерживается контракторами с интеграторами, которые держат на складах это железо исключительно ради вас, потому что купить его уже лет десять как нельзя, но и нельзя поменять на новое, потому что на нем не заработает версия операционки и окружения.
Решения в коде, которые вы не понимаете. Просто потому, что за 10 лет поменялись принципы разработки, среды и средства разработки и доступные ресурсы, наконец. Форматы данных, затерянные в веках, пользовательский экплорер для которых запускается исключительно на win98. Важная БД, которая работает под OS/2. Сделайте, блин, модельку этого сервиса за неделю.
Настоящее легаси — это когда у вас есть ветка кода, которая вроде бы не нужна, но трогать вам ее никто не даст, потому что нет критериев верификации работы системы после ее удаления. Никто просто не знает, в самом ли деле она не нужна. И проверить нельзя — на системе работает компания годами, и десяток трейсов в попытках понять, запускается ли она, вам ничего не дадут: вполне возможно, что она запускается по сочетанию високосного года и перехода на другую систему налогообложения, и вставлена туда после прошлого глюка, который стоил компании Х миллионов. Уберете сейчас — а через два года опять потеряете деньги. Один конкретный вопрос еще можно как-то решить, но их в коде зрелой системы тысячи, и они равномерно перемешаны с действительно ненужными кусками кода, которые мешают строить нормальную архитектуру.
Настоящее легаси — это реально тонны кода и тысячи окошек интерфейсов, которыми пользуются тысячи людей. Вы убираете одно окошко, и в конце месяца работа банка встает, потому что именно в нем раз в месяц смотрели статистику.
Вы обвешиваете окошки счетчиками показов, и убираете то, в котором счетчик показывает «1», и вас вызывают на ковер к начальству, потому что этой функцией пользовался очень-очень иногда аналитик этого начальства для важного отчета, а сейчас отчет сделать нельзя, и начальство это очень расстраивает.
Вы сливаете два окошка в одно, и в хелпдеске начинают копиться возмущения: легаси делалось десятилетиями, и пользователи им пользуются теми же десятилетиями. Нет системы доставки документации и обучения пользователей, потому что функции добавляются по одной и в ответ на запрос. Нет простого способа обучить тысячи пользователей новому методу работы. Нет ни единого центра документации, ни списка изменений, ни способа уведомить пользователей о изменениях, ни культуры читать документацию и уведомления. И это важное легаси, критичное для бизнеса, в отличии от еще одного сайта-с-мессенжером, где если пользователь свалит, невелика беда.
Вы остаетесь наедине с огромной кучей кода, которая возможно, нужна вся. Ничего нельзя взять и выбросить. Нельзя взять и переписать, потому что для переписывания можно либо повторить всю эту логику на другом стеке (а смысл, если это не решит проблем с архитектурой), либо написать ТЗ на систему не по коду, а по логике верхнего уровня (привет, восстановление контекста через интервью с бывшим сотрудником, ушедшим на пенсию), и на основании него написать новую систему (а реверс ТЗ по зрелой системе — это минимум раза в два-три больше времени, чем кодирование этого ТЗ). И это реально инвестиционный проект, на который надо обосновать бюджет миллионов эдак в 100, звать интегратора с отделом разработки или поставщика похожего решения, который будет адаптировать свою систему под ваши требования. Силами того отдела, что разработал этого монстра, сделать такое невозможно, потому что скиллы нужны немного другие. И новую систему надо внедрить одномоментно и всеобъемлюще, потому что нельзя пользоваться двумя система одновременно.
Единственное, что может сделать отдел разработки — только аккуратно разбираться с каждой фичей, как с детонатором бомбы, обвешивая ее тестами, и потом аккуратно перенося в часть кода с правильной архитектурой. Но это занимает адовое количество времени, все равно вносит баги, и требует безумно большого скилла убеждения бизнеса, чем будет заниматься три года отдел разработки, что генерирует баги и не приносит прибыль, но вот через три года, возможно, снизит стоимость разработки новых фич.
Первые два образования у меня как раз банковские. И мы помню эмулировали работу всей кухни на бумаге. пару десятков операций, заполнить на все доки, сделать проводки, пересчитать баланс, сделать отчеты, мсфо в тч, показатели всякие посчитать… И все это за 4 часа с калькулятором, листком и ручкой.
А потом я пришел в банк манагером среднего звена. И общнулся с чудом инженерной мысли — банковской системой. И чего в ней только не было. Особенно доставляли миллион всевозможных отчетов, которые в точности никто не знал как работают. А системы было 2 и они на одни и те-же отчеты выдавали немного разные цифры.
До сих пор помню как несколькими филиалами дружественными пытались понять как считать количество клиентов, и методика получилась весьма спорной. За каждым критерием по которому относить лицо к клиенту или нет велись долгие обсуждения и аргументация. Уверен — программистам и 10% от этого не рассказали и в документации никто не думал отражать это. У будущих поколений явно не раз проходила мысль «что они там курили».
Самым простым способом составить отчет было составить SQL запрос к базе. Правда для этого надо понимать корреспонденцию счетов и правила ведения каждого из счетов. Зато при таком составлнии можно было 100% описать, что включено и чего в отчете нет и какая методика. Вообще если бухгалтерскую кухню понимать — там много всего хорошего и продуманного, главное представлять себе в голове что с чем можно сджоинить.
Но уровень работников низок. Все по инструкции. Как под капотом работает мало кто понимает. Главное чтоб кнопочка работала и что-то выдавала. И человек будет жать эту кнопочку раз в месяц и печатать на бумажке и передавать это другому человеку на бумажке.
В общем слава богу, что ушел от этого в разработку :-)
А вашу боль прекрасно понимаю и что с таким делать — только паралелльно внедрять новую систему и заносить в нее всю первичку из боевой системы. А потом понемногу над первичными данными уже рисовать интерфейсы, контролы и отчеты. А когда весь функционал будет продублирован — переключиться на новую систему и оно заработает как старая.
Ну или нет
"миллионов эдак в 100" :)
И получить в итоге +1 решение в экосистеме :)
Великолепно, добавлю к этому, что настоящее легаси — это когда система в продакшене с 1965 года, а при этом она обслуживает до сих пор действующие договора на страхование перевозки скота, заключённые в 1886 году. И ее бизнес-логика не была придумана Очень Умными Аналитиками, а была оцифрована с инструкций для андеррайтеров (операторов по сути). А инструкции эти писались поколениями этих же андеррайтеров, местами уходящие в Британию XVII века.
И вот это все работает в смысле софта порядка полувека, а а смысле бизнес-логики — порядка 400 лет, непрерывно меняясь.
И научите меня, как это быстро переписать.
привет, восстановление контекста через интервью с бывшим сотрудником, ушедшим на пенсию
На пенсию ещё по-божески, по-моему, по сравнению с уволенным со скандалом.
Настоящее легаси — это ...
А стараниями текущего поколения разработчиков теперь ко всему этом добавиться еще и рой микросервисов, про который никто не будет знает, как он работает (вот нигде не видел, как сделать так, чтобы все это оставалось понятным и лет так через 10). Упадет рой — и обратно подняться не сумеет, потому что какой-нибудь конфигурационный сервер начальной раскрутки, что нужен несколько раз за жизнь системы, давно умер.
Причем рой именно добавиться, а не придет на замену — старую же систему целиком на новую архитектуру перенести не сумеют.
Настоящее легаси — это ...
… когда вы остались на проекте с командой, которая, кажется, видела человека, который говорит, что помнит команду, которая была после той, которая участвовала в поддержке кодовой базы.
JohnRico спасибо.
Slate Star Codex писал про баланс между Stress и Slack в эволюции и цивилизации. https://slatestarcodex.com/2020/05/12/studies-on-slack
Более глубокого размышления о балансе стресса и свободы (как на русский slack перевести?) я не видел. Любые вопросы эволюции кода полностью описываются в этих терминах. Есть стесс (бизнес, которому "надо вчера"), есть потребность в свободе (slack), чтобы инвестировать в долгосрочные изменения, попытки структурных улучшений (которые не всегда успешные) и т.д. Те, у кого stress 100% выигрывают в сверхкороткой преспективе, но имеют overfit и очень низкую гибкость. Те, у кого slack 100% ничего не делают. Баланс между stress и slack даёт самые офигенные результаты. (Это я кратко пересказал очень умную статью по ссылке выше).
И снова о Legacy. Вечная боль техдира