company_banner

И снова о Legacy. Вечная боль техдира

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


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


    Техдир пришёл к ним, поздоровался и спросил: «Ребята, скажите честно, какой аццкий зверь меня ждёт в этом проекте? Потому что стейкхолдеры рассказали только о единорогах с радужными хвостами и розовых пони? Legacy, да?»


    «Legacy, ...», — грустно ответили разработчики.


    Сказка закончилась. Началась работа — и непростые решения.



    Cитуация. Первый извечный вопрос русской интеллигенции «Кто виноват?»


    Закрываем глаза и представляем рядовую ситуацию. Бизнес приходит с какой-либо идеей — и он пробует ее сделать сразу и быстро. То есть с помощью ..., пустых банок из-под колы и палок. Бизнес-управленцы пробуют каким-то образом решить эту проблему в минимальные сроки.


    Они привлекает либо аутсорсеров, либо от других своих проектов отвлекает разработчиков. В общем, буквально экономят на всём, пытаются за копейки сделать какой-нибудь мини MVP, с помощью которого проверить гипотезу. Допустим.


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


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


    И погнали. «Оно» работает с помощью каких-то негров с опахалами, шамана, бивня мамонта, летающей китайской крысы и панголина.


    Продукт обрастает вот такими культурными наслоениями, костылями и чем-то еще. Проблема еще заключается в том, что, так как гипотезы проверяются часто из «la merde» и палок, этим занимаются либо разные программисты, либо программисты работают по остаточному принципу. И они к этому относятся «а давайте-ка я тут попробую один метод программирования, а сейчас попробую другую концепцию». И в результате получается месиво подходов.


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


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


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


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


    Проблема. Второй извечный вопрос русской интеллигенции «Что делать?»


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



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


    А бизнес вообще не знает, что проблема есть. Бизнес вообще не понимает: «Ну как так, MVP же работает?». Работает. «А почему новую фичу нельзя вот прям счаз воткнуть?» И с чем сталкиваются многие технические управленцы, они не могут объяснить, в чем конкретно проблема — и самое тяжелое они не могут показать в метрике, измеримой бизнесу, чтобы они понимали, что в текущем состоянии разработка фичи стоит 100 рублей, а в оптимизированном, например, 10 рублей.


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


    Решение проблемы. Ломать нельзя рефакторить. Или уходя гасите всех


    И мы переходим к решению проблемы. Существуют различные попытки решить проблему.


    Решение номер раз. Помножить на ноль


    Самая очевидная попытка решить проблему — переписать все от и до, до последней запятой и точки. У этого подхода есть свои плюсы.


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


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



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


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


    Была даже старая советская, не анекдот, а история про двух кладовщиц на складе на заводе. Одна кладовщица, когда к ней приходили, быстро всё выносила, какие-то запчасти, какие-то инструменты. Шурх-шур-шурх, держи-держи-держи. А другая всё время возилась, долго искала, ещё что-то. А секрет был в том, что первая разложила все по-своей какой-то собственной системе, которую никто не знал и никто не понимал, естественно, и могла пользоваться ей только она.


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


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


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


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


    Решение номер два. И давайте тут чуть-чуть починим


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


    Но у этих всех серий подходов есть две крайности. Первая крайность – сказать «давайте все перепишем нахер», а другая крайность говорит «а давайте мы по чуть-чуть вот тут вот починим, тут вот починим, там вот починим, давайте мы в спринтах наших время отрежем, там сколько у нас командная производительность, +100 story points, мы возьмем из них 10% и будем тратить их на исправление техдолга».


    Что у нас получается? А у нас получается, что команда ввела так называемый «налог на непонятно что», формально называется «налог на исправление технического долга». Но как он там исправляется, если бизнес придет и спросит «А что там и как? Что у вас?» Бизнесу, конечно, объяснят, но он не поймет. В чем заключается технический долг с точки зрения технаря, понятно.


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


    Во втором примере новой концепции нет — и это реально проблема.


    Решение номер три. Золотая середина. Микроверсия нового продукта


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


    Вот что это такое за новая концепция, это о чем? Артефакты какие бывают? Это документ или это серия видеороликов про то, как писать, или это книга «Чистый код». Должен быть какой-то артефакт — и таким неплохим артефактом является микро версия, написанная в новой архитектуре вот самого основного продукта. Буквально совсем маленькая система, в которой есть основные функциональные части.


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


    И теперь важная тема. В книге Фредерика Брукса приводится пример того, как раньше строили храмы и там был пример храма Temple Expiatori de la Sagrada Família в Барселоне, строящегося на частные пожертвования начиная с 1882 года, знаменитый проект Антонио Гауди.



    Суть в том, что Sagrada Família придумал Гауди и он выработал архитектуру, каким храм должен быть, но так как проект огромный, его строили много поколений — и он еще недостроен, его достраивают еще.


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



    И с этого момента считается, что каноническая архитектура, новая архитектура она вот такая. И мы эту концепцию не трогаем, не меняем эту концепцию как минимум год. То есть берём правило не чаще, чем раз в год ее менять, апгрейдить.


    После этого значит, что у нас появился артефакт, который обозначает, что такое хорошо. Если старая система — это, что такое плохо. То новая система — это, что такое хорошо. Соответственно, после этого надо что-то делать со старой системой, значит тогда уже можно, действительно, от спринта отрезать какой-то слайс на рефакторинг, но это не работает, так что можно про это даже не говорить.


    Теперь давайте посмотрим на поток задач, который приходят в спринт. Там есть какие-то мелкие правки, какие-то мелкие фичи. И вот эти вот вещи, какие-то мелочи, которые приходят, их нужно делать по-старому, по-плохому. Точно так же вонзаем какие-то костыли, делаем по-старому.


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


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


    Но есть особенность, если разработка идет плотно, прям хорошим потоком, прям бизнес говорит «давай, давай, давай», то свободного времени у разработчиков, как правило, нет вообще.


    И соответственно, техдиру и разработчикам надо после того, как они продали команде новую концепцию, сразу говорить, что все новые фичи они будут делать в два этапа: сначала рефакторим это место, выкатываем в продакшн очередным релизом, так что бы это застолбилось. Выкат в релиз можно назвать цементированием.


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


    Это, пожалуй, один из самых удачных подходов, который мне известен.


    О проблеме, когда сталкиваются технический директор и Legacy, рассказал CTO Дмитрий Симонов, основатель канала «Техдирские заметки».

    Southbridge
    Обеспечиваем стабильную работу highload-проектов.

    Comments 111

      +1
      Заранее извиняюсь за снобизм — только разбираюсь во всей теме проектирования систем.

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

      Пожалуйста, поправьте, если что не так.
        0
        Вы не поверите, но до сих пор довольно многие компании работают с монолитами. И не все админы, из-за личных предубеждений и инерции, готовы переходить на микросервисную архитектуру.

        Вот в этой статье (https://habr.com/ru/company/southbridge/blog/512268/) описаны вполне реальные случаи, когда люди даже о Докере не хотят задумываться. Порой инерционность человеческого мышления впечатляет. :)
          0
          Спасибо!

          Теперь и для себя и для других можно сформировать совет на будущее :)
          Если строите MVP из говна и палок, то не побрезгуйте и микросервисами — это сэкономит другим программистам и бизнесу много сил, денег и времени. Просто пожалейте их!

          *при условии, что проект продолжит свое существование и после MVP
            +5
            ну если изначально закладываться на то что, проект будет существовать и после MVP, то и костылей в нем должно быть меньше =)
            Что грамотная архитектура, что микросервисы это +время и если цель из говна, палок, лишь бы было что на конфе ЦА показать, то это все идет лесом.
            Ну и в целом стартовать проект с микросервисов может быть в разы дороже, чем монолит с последующим разделением, так как правильно разрезать на микросервисы на этапе идеи могут далеко не все. А перегруппировывать микросервисы тот ещё квест
            +38

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

              0

              Это действительно так. Разные подходы — разные задачи. Не подразумеваю, а полностью соглашаюсь с вами) И еще раз повторяю, что совсем не профи в данной теме, просто излагаю свои мысли.

                +3
                Нет. Сразу скажу, что нет ничего плохого в монолитах. Если их хватает для решения задачи, и обслуживания админам не доставляет проблем. Это просто разные подходы.

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

                И у нас Павел Селиванов не раз и не два говорил на конференциях и интенсивах, что если вы задаетесь вопросом: «Нужен ли мне Kubernetes?», то скорее всего он вам не нужен.
                  +2
                  Не далее чем на прошлой неделе пришел ко мне коллега, помоги, говорит с одним PoC для клиента. Ну, я разрисовал красивую архитектуру, десяток компонентов, все масштабируется и все такое. Он посмотрел и говорит — спасибо, конечно, но нам надо просто показать, что это в принципе работает и одного скрипта на Питоне нам будет, в принципе, достаточно.
                    +9

                    Взялись за работу не уточнив требования? Надеюсь вы не архитектор :)

                    –1
                    вы задаетесь вопросом: «Нужен ли мне Kubernetes?», то скорее всего он вам не нужен.

                    Несколько раз на работе задавались вопросом "нужен ли нам докер". И так взвешивали, и эдак. Пришли к выводу, что он нам не нужен. То есть в принципе с ним было бы сравнительно просто (проще, чем сейчас) решать некоторые задачи тестирования, но переписывать под него экосистему сборки… ради чего?


                    P.S. У нас монолит.

                  +9
                  Вы не поверите, но до сих пор довольно многие компании работают с монолитами.

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

                  когда люди даже о Докере не хотят задумываться

                  Я выпилил докер с проекта 3 года назад.
                  Докер это не только новые возможности, но и новые затраты на поддержку докера и решение проблем с докером. Это не всегда оправдано и зависит от разного Один у вас проект или 50. Одна история когда у вас один проект и одна команда, а другая история когда у вас на одном и том же железе размещено 50 проектов.

                    0
                    А как же поддержание единой тестовой и прод среды, автодеплой (хотя бы на тестовый сервер)?
                    Ведь даже без использования k8s очень удобно сделать образ, выложить его на тест для проверки, а потом этот же образ выкатить в прод? (это вообще… без привязки к тому, что микросервисы там или монолит)
                      0

                      Этого можно достигать и другими средствами. Сборкой deb/rpm/… пакетов, образами виртуалок, система контроля типа ансибля/паппета/ююю, другими контейнерными системами, образами виртуалок. Баш-скриптами в конце-концов (которые и для докера обычно нужны).

                        0
                        Конечно можно, но, на мой взгляд, очень громоздко получается.

                        Лично у меня получилось так:
                        Копирование (и настройка) ручками ->
                        Где-то в этом месте было и разделение виртуалками (но потом понял, что арендовать железные сервера избыточно для проектов с небольшой нагрузкой, достаточно просто виртуалки и на нее можно установить 1-4 сервиса и оно работает)) ->
                        Bash ->
                        Ansible ->
                        Ansible (для первичной конфигурации)+Docker+Gitlab (CI/CD)+Gitlab Registry
                          0

                          У меня в докере громоздко получается. Особенно, когда с хостом нужно взаимодействовать плотно.

                        0
                        А как же поддержание единой тестовой и прод среды, автодеплой

                        Ну много вариантов есть — ansible например.
                        Но сейчас я скажу одну вещь, после которой у вас наверно взорвется голова )))
                        Раньше я использовал ansible, но потом перешел на Makefile y bash-скрипты.
                        Пишу «make deploy» и все готово, деплой на тестовый сервер «make deplytest», запуск тестов «make test».
                        Есть еще CI куда на котором тесты запускаются автоматически после каждого комита, и также автоматически деплоится на тестовый сервер.
                          +1
                          А как всё это повторить для 5 разных веток на 1 сервере?
                            0
                            У нас нет такой потребности. Но наверно можно разные ветки разворачивать в разных папках. Не вижу тут как-то принципиальной проблемы.
                            Я не претендую на универсальность решения. Зависит от многих факторов — масштаба проекта, количества проектов, размера команды, проекты живут на своем железе или делят общее и так далее.
                              0

                              "make deploy" может создавать виртуальный сервер по названию ветки в гите, например, feature-123.dev.example.com

                                +2
                                Может, вопрос в bus-factor данного решения и стоимости поддержки.

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

                                IMHO сложность использования docker несколько преувеличена.
                                На моём опыте, большая часть его противников или не хотят изучать технологию, или не хотят ничего менять в своей работе — им и так хорошо и всё устраивает, в том числе много ручных операций и портянки скриптов и/или YAML, т.к. это делает их незаменимыми.

                                К сожалению аргументированный отказ от docker на основе именно его технических минусов — очень редкое явление, в основном аргументация на уровне «я слышал/читал что это плохо», без личного опыта и понимания технологии.
                                  0

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


                                  Как по мне, то многие рекламируемые возможности докера предполагают очень большой объём допиливания напильником. Ну вот банальная задача: развернуть на одном хосте несколько веб-проектов на php под разными доменами. В "олдскульных" практиках дошло до того, что просто файлы скопировать куда-то в /www/example.com и всё работает. А с докером/докер-композом повозиться надо: какой-то "ингресс" установить с возможностью слушать события докера (читай — рутовыми правами), существующие "монопольные" средства развертывания приложения в докере (bash, docker-compose.yaml, ansible тот же) метками утыкать, с /etc/hosts поработать.

                                    0
                                    Да это есть, но не сильно отличается от настройки того-же apache/nginx, делается это один раз и работает потом долго.

                                    Доступ к docker socket в RO, это всё-таки не рут права (RW — можно так назвать).

                                    Бонусом докера является возможность не доставлять те же модули php на конечные машины, это не боль при условии, что у вас один сервер и свежий проект, а когда их несколько и проект требует старый php, которых нет в свежих дистрибутивах, или состав этих модулей периодически меняется.
                                    В таком случае вы получаете сильное упрощение в Operations с не не очень существенным усложнением в Dev.

                                    Кроме того очень простым становится откат и обновление.

                                    А если выйти за рамки php там вообще начинается дивный новый мир.
                                      0

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

                                        0
                                        Прошу прощения в чём осложняется разработка с docker, на PHP?!
                                        Имхо наоборот, можно на рабочей машине получить окружение аналогичное серверному.
                                      0
                                      Сейчас с образом nginx-proxy достаточно новый docker-compose файл поместить в новый каталог и у образа, который должен быть опубликован наружу добавить пара переменных окружения VIRTUAL_HOST и LETSENCRYPT_HOST (и само собой общая сеть с nginx-proxy делается с доступом только к этому контейнеру и в DNS привязать доменное имя к этому IP), и вся настройка в общем… дальше оно само).
                                        0

                                        Сильно отличается от того, что я написал?


                                        А с докером/докер-композом повозиться надо: какой-то "ингресс" установить, существующие "монопольные" средства развертывания приложения в докере метками утыкать, с /etc/hosts поработать.

                                        С этим я года три-четыре назад разобрался, причём со своим CA (LetsEncrypt хорош только для публичніх доменов/сайтов). Но вот удобным это назвать язык не поворачивается. k8s, пожалуй, даже удобнее в этом плане, жаль что тащит кучу ненужного для подобных задач.

                                          0
                                          Если проект один, то можно просто образ nginx-proxy сюда включить (но нужен ли он вообще тут?)). Метка всего одна (если LE не нужен, если нужен, то два образа и две метки), /etc/hosts вообще тут не причем (метка же есть).
                                          А если два и более проекта, тогда уже nginx-proxy делается отдельным compose-файлом, плюс делается общая сеть. А остальные подключаются только указанием этой сети и метки (всего два-три параметра в compose-файле проекта).

                                          Так что да, сильно отличается на мой взгляд)
                                            0
                                            Если проект один, то можно просто образ nginx-proxy сюда включить (но нужен ли он вообще тут?))

                                            Проект может быть, но обслуживать несколько доменов, банально example.com и api.example.com


                                            /etc/hosts вообще тут не причем (метка же есть).

                                            nginx-proxy начал хосты прописывать по меткам? раньше с dnsmasq нормально было вайлдкрад домены, но с systemd увы нет.


                                            всего два-три параметра в compose-файле проекта

                                            На каждый "роут". Ну и сеть не просто указать в каждом контейнере, но и "глобально" прописать как external. И это если запускаемые проекты согласованы. А не, например, один с одной работы, а другой — с другой.

                                              0
                                              Проект может быть, но обслуживать несколько доменов, банально example.com и api.example.com

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

                                              На каждый «роут». Ну и сеть не просто указать в каждом контейнере, но и «глобально» прописать как external. И это если запускаемые проекты согласованы. А не, например, один с одной работы, а другой — с другой.

                                              по проводу роута не знаю, а так да, сеть надо указать как external и в основных контейнерах (точка входа доменного имени) ее надо указать в дополнение к внутренней сети.
                                      0
                                      Может, вопрос в bus-factor данного решения и стоимости поддержки.

                                      Ну так в том то и вопрос, что стоимость поддержки докера в нашем случае оказалась выше. Не вижу как это может влиять на bus factor.

                                      но при росте сложности проекта и увеличении размера команды такие решения начинают существенно проигрывать тому же докеру.

                                      Это упрощение. Факторов больше чем размер команды, но это конечно один из них.

                                      в том числе много ручных операций и портянки скриптов и/или YAML

                                      Ну а чем докер принципиально отличается от bash скрипта, Dockerfile это по сути и есть плюс минус bash-скрипт.

                                      На моём опыте, большая часть его противников

                                      Я не противник докера. Более того я его использую для тестирования bash-скриптов. (Хотя могу и без докера, через vagrant). Но я против бездумного пихания докера и микросервисов в каждый проект.

                                      или не хотят изучать технологию, или не хотят ничего менять в своей работе

                                      Я выше написал, что изначально докер был в проекте. Так что это не про нашу ситуацию.
                                        0
                                        Ну так в том то и вопрос, что стоимость поддержки докера в нашем случае оказалась выше. Не вижу как это может влиять на bus factor.


                                        Docker это всё-таки стандарт, в отличии от самописных скриптов, который со временем разрастаются, поэтому найти на рынке специалистов, которые его знают будет проще.

                                        Это упрощение. Факторов больше чем размер команды, но это конечно один из них.


                                        Основные факторы это:
                                        1. Сложность проекта
                                        2. Размер команды
                                        3. Необходимое значение 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 становится существенной.

                                        Не всё что вам кажется «бездумным пихаением» может быть этим на самом деле, возможно просто с вашей точки зрения это только кажется.

                                        Я выше написал, что изначально докер был в проекте. Так что это не про нашу ситуацию.


                                        Не исключаю, что для вашего проекта эта технология не нужна, а волосы людей, ответственных за поддержку проекта со стороны инфраструктуры вместе с теми, кто отвечает за деплой, мягкие и шелковистые.
                                        Но всё это может быть не так в иных ситуациях.
                                          0
                                          Он принципиально отличается от bash, ansible и т.п. тем, что у вас нет предыдущего состояния (точнее оно всегда известно — это состояние образа с которого вы начинаете)

                                          Это если volume не используется. А вот с ними начинаются танцы с бубнами на задачах типа папка из одного образа должна быть доступна в другом. В чистом докере небольшая проблема volumes-from, но вот в docker-compose v3 уже проблема — штатная фича докера не поддерживается. И множество таких нюансов.

                                            0

                                            Вам никто не мешает использовать bind mount и не использовать volumes.
                                            Но да в таком раскладе могут быть нюансы.

                                              0

                                              Как с одного контейнера сделать bind mount на другой?

                                                0
                                                Вопрос: зачем? Файловая система — далеко не лучший вариант использования совместного ресурса, т.к. не гарантирует целостность данных. Если это костыль, то тут и бубен в руки, если легаси, то через выделенную файловую систему, а если подойти с умом, то и потребности нет.
                                                  0

                                                  Прежде всего она и гарантирует, что у веб-сервера (nginx например) с read only доступом и приложения с read/write один набор файлов. При билде образа приложения где-нибудь в /app/public формируется source of truth статических файлов для раздачи через веб, а веб-сервер монтируется к нему с R/O. Это вы считаете костылём?

                                  0
                                  Раньше я использовал ansible, но потом перешел на Makefile y bash-скрипты.

                                  Не взорвалась. И то, и то декларативно на высоком уровне и императивно на низком ) Мне проще обычно bash скрипт написать.

                              0
                              не все админы, из-за личных предубеждений и инерции, готовы переходить на микросервисную архитектуру.

                              Сразу скажу, что нет ничего плохого в монолитах

                              Ну т.е. с одной стороны вы вроде как не видите ничего плохого в монолитах, а сдругой — первыми же ассоциациями с монолитом являются "предубеждений и инерция". Забавно :)

                              +8
                              между микросервисами не трогаем

                              В этом и проблема, организовать микросервисы так, чтобы добавление фичи затрагивало наименьшее количество точек. Ошибка в архитектуре это не только внутряняя кухня микросервиса, но и публичные контракты. Править которые, даже в микросервисах — большая боль.
                                +3
                                Это и понятно… Минус микросервисов, когда в системе много связей. Систему контрактов действительно стоит хорошо обдумать заранее, так сказать «с запасом на будущее». Может же все рухнуть из-за одного сервиса, повалятся 500 ошибки, как домино. Одной точки с запятой хватит, если на ПХП пишете)
                                  +5
                                  Суть проблемы в том что в системе слишком много связей, а не в том что она монолитная или микросервисная. И да, рефакторить паутину в монолите будет проще чем рефакторить паутину из микросервисов.

                                  Ваше предложение из первого комментария верно, только слово «микросервисы» стоит заменить на модули, и грамотно декомпозировать приложение на независимые модули сложно.
                                  Микросервисы лишь проводят чуть более жёсткие границы между модулями, но и нарушения таких границ фиксить сложнее.

                                  А вот когда у вас есть грамотное декомпозированное приложение, и вам нужно масштабировать разработку, ещё меньше конфликтов в коде, добиваться CI/CD(нормального CI, а не «пайплайн настроить»), можно задуматься о микросервисах для большего контроля за границами модулей.
                                  Время идёт, инфраструктура совершенствуется, конечно, но микросервисы по прежнему несут за собой значимые накладные расходы.
                                    +3
                                    Ага. «Лучше быть богатым и здоровым, чем бедным и больным».
                                    Проблема монолитов в том, что если в нем потопталось 3-4 поколения программистов, то заложенная изначально в монолит декомпозиция бывает нарушена почти везде.
                                    И мы имеем, когда из представления сразу обращаются к БД, минуя слой бизнес-логики.
                                    Ну или размазанную бизнес логику между БД и приложением.
                                    Когда в приложении вызывается несколько ХП, причем их выполнение зависит, от того, какие данные записало приложение во временные таблицы.

                                    В этом плане «тупое» следование принципам микросервисной архитектуры, дает хоть какой-то барьер, для таких «изысков».

                                    Грубо говоря, там где микросервисы сразу «падают» и обозначают «есть проблема».
                                    Монолит может работать годами, а потом при не значительном изменении упасть, так, что добавление новой фичи, приведет к переписыванию половины приложения.

                                    P.S. Прошу прощения — накипело :-)
                                      +3
                                      Проблема монолитов в том, что если в нем потопталось 3-4 поколения программистов, то заложенная изначально в монолит декомпозиция бывает нарушена почти везде.
                                      Вы исходите из предположения что микросервисы которых потопталось 3-4 поколения программистов лучше чем монолит в котором потопталось 3-4 поколения программистов, в чём я лично не уверен.
                                      С одной стороны — да, границы чуть более явные, с другой — как я писал, нарушения границ сложнее фиксить + накладные расходы на построение распределённого приложения.

                                      В этом плане «тупое» следование принципам микросервисной архитектуры, дает хоть какой-то барьер, для таких «изысков».
                                      Думется, причина тут в том, что при проектировании микросервисной архитектуры(особенно после монолита), разработчики уже встречались с проблемами, частенько это уже не новый проект, и хоть каким-то принципам да следуют, а монолит часто делают тяп-ляп MVP быстрее, «потом перепишем».

                                      P.S. А что до:
                                      И мы имеем, когда из представления сразу обращаются к БД, минуя слой бизнес-логики.
                                      Ну или размазанную бизнес логику между БД и приложением.
                                      Я немного наслышан про некоторые конторы, и о том, чего они творят с микросервисами, тоже волосы дыбом встают. Десятки микросервисов на запрос, сотни микросервисов при условии что в компании всего с сотню разработчиков, отдельный микросервис который ходит в БД с которым общаются все-все сервисы и пр.
                                        0
                                        Так фокус микросервиса в том, что он «обозримый».
                                        Т.е. достаточно мал.
                                        Соответственно «переписать» его проще.
                                        Монолит, он на то и монолит, что выделить из него какие-то слои невозможно.

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

                                        Насчет, того, что при любой архитектуре можно сделать «Адъ и Израиль» — я с этим не спорю.
                                        Но если с монолитом у вас один большой кусок говна, с которым не понятно что делать.
                                        То с микросервисами есть много кучек говна, которые можно убирать по одному.

                                        <:o)
                                          +1
                                          В микросервисной архитектуре они не гадят в одну кодовую базу годами.
                                          А гадят в маленькие изолированные приложения.
                                          Только в том случае если они изолированны, при плохой архитектуре это не так. А при хорошей и в монолите можно делать независимые модули. По поводу переписывания микросервисов по одному, выше уже писали про публичные контракты.
                                          Чем больше связей, тем сложнее переписывать, и тем более переписывание по одному не поможет их исправить, нужно будет собирать общую картину из многих кодовых баз, и править всю цепочку, разбираясь во всех происходящих при этом событиях и эффектах.
                                            +1
                                            Вы сделали одно допущение, что в монолите есть «публичные контракты»!
                                            Если для микросервисов это всегда так (by default).
                                            То для монолита — нет.
                                            Здесь могут обращаться к БД прямо из фронтенда, минуя все слои бизнес логики.
                                            Благо JSP/ASP это позволяет сделать. :-)
                                              +1
                                              Вы сделали одно допущение, что в монолите есть «публичные контракты»!
                                              Если для микросервисов это всегда так (by default).
                                              Я не делал такого допущения, просто считаю что накладные расходы, сложность проектирования распределённой системы, и сложность правки контрактов перевешивают этот спорный плюс.
                                              Спорный потому, что публичные контракты можно делать в монолите — вопрос желания, и потому, что я видел и микросервисы без
                                              задокументированных публичных контрактов — чтобы глянуть api лезли в код. Так что, при желании можно и…
                                                +1

                                                Формально фронтенд одного сервиса может полезть в базу данных другого. Благо JSP/ASP это позволяет сделать. :-)

                                  +3

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

                                    +16

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

                                      +16
                                      Микросервисы ничем не спасают, никто не мешает проводить рефакторинг по частям и в монолите, разница только в том, что в одном случае API — это функции/классы/другие средства языка, а в другом — сетевые вызовы. Единственный момент в плюс микросервисам, что там тяжелее иметь какой-то глобальный изменяемый стейт со всеми вытекающими сложностями рефакторинга, да и то плюс сомнительный, ухитряются многотонные json/protobuf/etc между микросервисами гонять, куда весь этот стейт и засунут с потрохами.

                                      В словосочетании «микросервисная архитектура» главное слово «архитектура», а вот «микросервисная» само по себе не даёт ничего.
                                        0

                                        Очень часто "легаси" кроме страшного кода означает и древние версии платформы, библиотек. (Микро)сервисы помогают переводить системы на актуальные версии платформ и библиотек по частям.

                                        +1
                                        часть команды добавляет новые фичи, а другая — занимается переписыванием старой части

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

                                        Есть ситуации, о которых, как понимаю и говорит автор, когда тех.долгом вообще не занимаются — «работает и ладно»
                                          +1

                                          Так проблема то скорее всего будет как раз в кривых интерфейсах между микросервисами.

                                            +2
                                            Но если изначально система плохая, собранная из уже упомянутого выше, но построена на микросервисах, независимых частях — то все становится проще:
                                            часть команды добавляет новые фичи, а другая — занимается переписыванием старой части.

                                            Это если разбиение по микросервисам было изначально правильным, что с учетом построения системы дендрофекальным способом маловероятно. Вообще по моим наблюдениям самые нормальные микросервисные реализации — именно порезанный монолит. Даже с достаточным временем, потраченным на проектирование правильно разбить приложение на отдельные сервисы с учетом не только интенсивности взаимодействия сервисов, но и частоты изменений разных частей, сильно не просто. Тут как с дорожками на газоне: их не надо делать заранее, а нужно дождаться пока жители сами вытопчут, а затем уложить поверх вытоптанного.
                                              0

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

                                                0
                                                Ну и как вы например Hadoop перепишите на микросервисы где может быть реализована большая часть бизнес логики? А самое главное зачем?
                                                +3
                                                Бизнес вообще не понимает: «Ну как так, MVP же работает?». Работает. «А почему новую фичу нельзя вот прям счаз воткнуть?» И с чем сталкиваются многие технические управленцы, они не могут объяснить, в чем конкретно проблема — и самое тяжелое они не могут показать в метрике, измеримой бизнесу, чтобы они понимали, что в текущем состоянии разработка фичи стоит 100 рублей, а в оптимизированном, например, 10 рублей.

                                                Само по себе решение перейти на микро-сервисную архитектуру эти метрики же не родит. Сначала все равно придется объяснить бизнесу, что в условиях ограниченности ресурсов, нам потребуется ХХХ дней чтобы сделать рефакторинг (кстати, это слово бизнесу лучше вообще не говорить). Или же увеличиваем штат и/или увеличиваем время. И только потом, вписавшись в бюджет и в рамки, родив архитектуру, план по «распилу» монолита, затраты на инфраструктуру и тэпэ и тэдэ, мы сможем с какой-то долей вероятности обозначить эти метрики. Допустим получится не 20 дней, а 3 дня. Итого в глазах бизнеса это выглядит как ХХХ дней + 3 дня, что явно больше 20 дней.
                                                И бизнес задает резонный вопрос: «а нафига мне этот твой рефакторинг прямо сейчас? Делайте фичу. А рефакторить эти ваши рефакторы мы будем потом. Обязательно будем! Но потом...»
                                                  +3
                                                  а нафига мне этот твой рефакторинг прямо сейчас?

                                                  Отвечать нужно так:
                                                  1. В проекте есть плохой код. Пока он никак не выражается для обычного пользователя, но только пока.
                                                  2. Новый функционал пишется поверх старого. Соответственно старые костыли приходится покрывать сверху новыми. Количество плохого кода нарастает.
                                                  3. Количество плохого кода рано или поздно приводит к увеличению количества багов.
                                                  4. Багов становится все больше, появляются самые неприятные баги — редкие, плавающие, которые сложно воспроизвести, чтобы починить. Старые программисты уходят, новые, банально не могут разобраться во всем этом клубке багов и костылей
                                                  5. Самый замечательный этап, который обязательно наступает — это «внезапные» падения проекта. Просто взял, и упал на ровном месте. Проект поднимают — а там ошибка. В итоге банальный запуск проекта выливается в часы нервотрепки, и для программистов и для бизнеса.
                                                  6. К этому моменту атмосфера в бизнесе давно испорчена. Бардак, скандалы, поиски крайних. Программистов считают «криворукими», потому что создали такой плохой продукт.

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

                                                  Либо, если команда большая, то проект переходит в стадию «команда 80% времени чинит бесконечные баги, новый функционал делается со скоростью 1 фича в пол года».

                                                  Не смотря на всю печальность ситуации — я считаю, что каждый менеджер проекта, каждый владелец бизнеса должен через такое пройти. Чтобы не было иллюзий, что «чистый код» это какая-то прихоть программистов. Ну и чтобы понимать, что скупой (на сроки в том числе) в итоге платит дважды, трижды и т.д.
                                                    +1
                                                    Все понятно, частично даже очевидно.
                                                    Далее возникает вопрос: какими метриками на этом этапе Вы будете подкреплять аргументацию «давайте перепишем на микросервисы»? С потолка возьмете?
                                                      +1

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

                                                        +3
                                                        Далее возникает вопрос: какими метриками на этом этапе Вы будете подкреплять аргументацию

                                                        Это не подкрепляется никакими метриками.

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

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

                                                        Всем нам иногда нужен негативный опыт, чтобы до сознания дошел факт о том, что мы делаем что-то неправильно. Менеджеры здесь не исключение. А так как их сфера ответственности намного больше, чем у рядового программиста — то и негативный опыт у них совсем другого масштаба.
                                                          +1
                                                          Да я тоже поддерживаю идею, что «лучше быть богатым и здоровым, чем бедным и больным», конечно же приятно, когда вокруг тебя идеальная картинка. Но она обычно бывает идеальной только в первый год, ну два года, после старта проекта. А потом начинается «вот это все» что описано выше. Монетизация ранее сделанных затрат начинается. А поезд красивой (не важно какой) архитектуры уже ушел.

                                                          В этой ситуации, пожалуй единственным правильным шагом техдира будет убедить и донести до бизнеса/акционеров мысль, что «мы слишком сильно выросли, и если мы хотим расти и дальше, то нам надо увеличивать ресурсы, брать людей, менять подходы». И в этом случае, поверьте мне, чем будут заняты эти дополнительные 2..5..10 человек, будут ли они пилить монолит на сервисы, или будут поэтапно рефакторить существующий монолит, бизнесу будет абсолютно все равно. Он дал карт-бланш и он договорился с техдиром о сроке, когда будет представлен результат.

                                                          И вот для этого успешного донесения этой мысли и нужны либо метрики, либо умение убеждать и брать на себя ответственность. Метрик таких я ни разу не видел за 20 лет. Остаются только субъективные аргументы и личная ответственность. Поэтому выводы в этой статье считаю спорными.
                                                            0
                                                            Метрик таких я ни разу не видел за 20 лет
                                                            А зачем метрики нужны вообще? Если все так детально разложить (как это у вас получилось) — то есть реально заинтересовать в таком образе действий, то этого же достаточно будет?
                                                              +1
                                                              И вот для этого успешного донесения этой мысли и нужны либо метрики, либо умение убеждать

                                                              Не все так плохо. Когда в проекте куча багов, новые фичи пилятся долго, а программисты постоянно жалуются на код — до руководства все же доходит, что надо что-то делать.

                                                              По этому, когда руководство созрело — достаточно просто фразы «так дальше работать нельзя, надо переписывать с нуля». И лично наблюдал ситуацию, когда такая фраза от тимлида сработала. Наняли новых людей + часть людей из старой команды начали параллельно со старым проектом писать новый. Правда, не успел посмотреть, чем в итоге все закончилось — уволился раньше.
                                                      +1
                                                      Под понятием «Бизнес придет» обычно понимают просто торгашей, для них что картохой торговать, что софтом — одинаково. Ну какой может быть техдолг на картоху ?! А тем более прототипы картохи или MVP.
                                                        +2
                                                        Первый способ выглядит очень жестко, сурово и опасно, но второй, как правило, не взлетает. Все тонет в рутине. Поначалу все с энтузиазмом начинают рефакторить, перетаскивать фичи на новую архитектуру, пытаются скрестить ужа с ежом, но все это быстро людям надоедает и через месяц-другой все возвращается к исходному состоянию — «а давайте-ка по быстрому запилим еще вот эти фичи», «А что это за непонятный архитектурный нарост? — Да это мы как-то пытались все сделать красиво, да забросили..» Легаси просто станет еще более жутким и непонятным.
                                                        Переписать все — это дорого, страшно и больно, но чаще всего другого варианта избавления от дентро-фекальной кучи легаси просто нет. ИМХО
                                                          +1
                                                          Все зависит от экспертизы по продукту и воли инвестировать в продукт.
                                                            +3
                                                            Как там.. «Для войны нужны три вещи — это: деньги, деньги, и еще раз деньги». Понятно что на голом энтузиазме исполнителей далеко не уедешь.
                                                            +1
                                                            Все проще — первый способ великолепен, если у лидера есть навык создания планируемых систем. За это им и платят такие деньги. По аналогии с футбольным тренером. Если же лидер горит желанием научиться готовить уже в процессе, то лучше дать ему такую возможность, только не на вашем ужине.
                                                            +6
                                                            Первое, что нужно понять и запомнить — нельзя создать качественный продукт, если компании (владельцам бизнеса) это не нужно.

                                                            «Что делать?»

                                                            1. Не работать в компаниях с плохим кодом
                                                            2. Если уж занесло — не переживать, делать то, что хочет руководство, напоминая, что все это закончится плохо (не работая над тех.долгом), и просто наблюдать, как все в итоге умрет.

                                                            Владельцы бизнеса тоже должны получать опыт. Так что пусть получают. Вы их предупредили, ну а то, что они вам ответили «работает и ладно, зачем переписывать» — это уже их проблемы.
                                                              +3
                                                              Сам уже 2 года мучаюсь с легаси системой. И конца не видно, потому что кода огромное количество. Поэтому, разрешите вставить свои 5 копеек.

                                                              Автор в начале статьи написал, что код до нового техдира писался абы как, при помощи кучи разных программистов, фрилансеров, заплаток, без погружения в кодовую базу и подобного. «Проблема еще заключается в том, что, так как гипотезы проверяются часто из «la merde» и палок, этим занимаются либо разные программисты, либо программисты работают по остаточному принципу.»

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

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

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

                                                                +3

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


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


                                                                Разрабы в этом плане сильно слабее. Вот вам всем большая зп как вы хотите, но ребенка надо родить за 1 месяц.

                                                                  +3
                                                                  Проблема не в наслоении.

                                                                  И в нем тоже. Точнее, проблема в утрате знаний об устройстве системы. А наслоение усложняет получение его заново.


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

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

                                                                    0
                                                                    Желаю, чтобы хозяина не переезжал автобус, а он просто перешел работать в другую компанию. )

                                                                    Связным текстом, говорите? Это конечно, идеал. Но как на практике его достичь? Есть грубо говоря функция. У нее комментарий, объясняющий, что это такое и зачем. Потом ее правят и комментарий уже некорректен. Комментарий поправить забывают. А он совсем рядом с кодом находится. Буквально на прошлой неделе видел такое у парня, у которого настолько горят глаза при работе, что его никак нельзя заподозрить в небрежности.

                                                                    Мы сейчас решаем проблему 2мя способами. 1. У нас есть такс-трекер, где ведутся все задачи. 2. Каждое изменение в коде делается коммитом. В начале текста коммита указывается ссылка на задачу или #123, где 123 — номер задачи. Ну, а в самой задаче потом придется порыться.

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

                                                                    Проблема, что автор уйдет и что дальше делать, конечно, существует.
                                                                      0

                                                                      каждого человека нужно вводить в курс дела. То что дока должна быть это само собой, но с разрабом нужно сидеть и проговаривать что делает каждый класс/метод.
                                                                      Да это долго, можнно месяц убить. Можно не все сразу, а пояснять как работает часть, по которой сейчас нужно сделать таску.
                                                                      Но в любом члучае это окупится на долгосрок, так как говнокода бужет сильно меньше.


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

                                                                        +2

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

                                                                          0

                                                                          Или ещё хуже известно, используется, но используется раз в году и на прямой вопрос никто ответить не может.

                                                                            +1
                                                                            а разбираться с тем как работает функционал и нужен ли он, некогда, т.к. бизнесу нужно другое (фичи, фиксы и т.д.)
                                                                              0

                                                                              Именно

                                                                        0
                                                                        Но как на практике его достичь?

                                                                        Кто бы знал. Скорее всего — специально обученными людьми, которые преимущественно этим и занимаются. Удалось же сделать общепринятым мнением, что тесты (а если проект не совсем мелкий — то и специальные люди, занимающиеся тестированием) практически обязательны.

                                                                        +1
                                                                        Много видел проектов — документов просто море, куча разных схем как что и куда перемещается, и все вроде бы круто. Только вот лезешь в код, и понимаешь что все эти красивые доки, мягко говоря, давно уже утратили актуальность и если ты действительно хочешь понять как там что работает — то тебе не остается ничего другого кроме как проводить полноценный реверс инжиниринг.
                                                                        Еще пол беды когда есть хотя-бы более-менее толковые тесты — по ним можно понять что происходит (хоть и не всегда, часто они делаются больше для галочки — что-бы метрику «покрытие тестами» задрать повыше), без тестов вообще — труба. Смотришь на класс, состоящий из десятка-другого тысяч строк, без комментариев и с «говорящими» методами плана GTJD_000054878964215(...*десяток-другой аргументов*) и возникает непреодолимое желание послать все это к черту и сменить профессию :)
                                                                      +5
                                                                      Что-то более похоже на поток мыслей про какой-то конкретный проект. Как это обычно бывает, в чуть другом проекте этот поток мыслей уже будет восприниматься как, мягко говоря, странный.
                                                                      И мы эту концепцию не трогаем, не меняем эту концепцию как минимум год. То есть берём правило не чаще, чем раз в год ее менять, апгрейдить.

                                                                      Вот это доставило особо. С чего взят такой странный период — год, мне, перелопатившему десятки легаси систем — непонятно. Обычно меняют что-то по необходимости, а не потому, что год прошел.
                                                                      • UFO just landed and posted this here
                                                                          +6

                                                                          вы уж постарайтесь найти. А то такую интригу создали

                                                                          • UFO just landed and posted this here
                                                                            0
                                                                            А потом новость: IE/EDGE переходит на webkit (который создали в apple, сильно развили в google).
                                                                          • UFO just landed and posted this here
                                                                              +2

                                                                              тема влияния контроля версий на уровень говнокода не раскрыта

                                                                                +1
                                                                                Если нет VCS и желательно без бэкапов, то в какой-то момент можно весьма легко избавиться от легаси. Привет WannaCry, Petya и прочие варианты рефакторинга.
                                                                                0
                                                                                А есть код попадает в систему контроля версий вместе с тестами, приликованной задачей и описанием того что сделано и зачем?
                                                                                  +1
                                                                                  Это вы как-то сильно исказили понятие legacy.
                                                                                • UFO just landed and posted this here
                                                                                    0

                                                                                    Узнаваемая ситуация, и это не только про legacy ) когда нанимают нового топа, потому что "надо наладить процессы/сделать так, чтобы у нас показатели выросли", а потом внезапно выясняется, что сделать-то надо, но есть куча ограничений со стороны бизнеса. Вот и крутись как хочешь.


                                                                                    PS: Комикс про программистов огонь! Топ-менеджмент меняют по ходу тоже из таких соображений

                                                                                      0

                                                                                      Вспоминается анекдот про три конверта...

                                                                                      +1
                                                                                      После сопоставления описанных проблем Legacy системы и фразы «И на эту модельку сервиса нужно потратить самому техлиду не больше недели времени» невозможно воспринимать этот текст серьезно. Как минмму для больших учетных или производственных систем предложенный метод видится сильно проблематичным.
                                                                                        +13
                                                                                        Если ужжжасное легаси можно взять и переписать, и это не инвестиционный проект на годы, то не такое уж это и ужасное легаси. Как говорится в анекдоте, «это не проблема, это просто расходы».

                                                                                        Настоящее легаси — это тонны кода, оперирующие коэффициентами, про которые никто не помнит, откуда они взялись. Куски кода и системы на устаревших языках, которых вы не понимаете. Система, построенная на логике, которую вы не понимаете. Потоки данных, ходящих такими путями, которые вы не понимаете. Устаревшее железо в серверных, которое поддерживается контракторами с интеграторами, которые держат на складах это железо исключительно ради вас, потому что купить его уже лет десять как нельзя, но и нельзя поменять на новое, потому что на нем не заработает версия операционки и окружения.
                                                                                        Решения в коде, которые вы не понимаете. Просто потому, что за 10 лет поменялись принципы разработки, среды и средства разработки и доступные ресурсы, наконец. Форматы данных, затерянные в веках, пользовательский экплорер для которых запускается исключительно на win98. Важная БД, которая работает под OS/2. Сделайте, блин, модельку этого сервиса за неделю.

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

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

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

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

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

                                                                                          До сих пор помню как несколькими филиалами дружественными пытались понять как считать количество клиентов, и методика получилась весьма спорной. За каждым критерием по которому относить лицо к клиенту или нет велись долгие обсуждения и аргументация. Уверен — программистам и 10% от этого не рассказали и в документации никто не думал отражать это. У будущих поколений явно не раз проходила мысль «что они там курили».

                                                                                          Самым простым способом составить отчет было составить SQL запрос к базе. Правда для этого надо понимать корреспонденцию счетов и правила ведения каждого из счетов. Зато при таком составлнии можно было 100% описать, что включено и чего в отчете нет и какая методика. Вообще если бухгалтерскую кухню понимать — там много всего хорошего и продуманного, главное представлять себе в голове что с чем можно сджоинить.

                                                                                          Но уровень работников низок. Все по инструкции. Как под капотом работает мало кто понимает. Главное чтоб кнопочка работала и что-то выдавала. И человек будет жать эту кнопочку раз в месяц и печатать на бумажке и передавать это другому человеку на бумажке.

                                                                                          В общем слава богу, что ушел от этого в разработку :-)

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

                                                                                            "миллионов эдак в 100" :)
                                                                                            И получить в итоге +1 решение в экосистеме :)

                                                                                              +1

                                                                                              Великолепно, добавлю к этому, что настоящее легаси — это когда система в продакшене с 1965 года, а при этом она обслуживает до сих пор действующие договора на страхование перевозки скота, заключённые в 1886 году. И ее бизнес-логика не была придумана Очень Умными Аналитиками, а была оцифрована с инструкций для андеррайтеров (операторов по сути). А инструкции эти писались поколениями этих же андеррайтеров, местами уходящие в Британию XVII века.


                                                                                              И вот это все работает в смысле софта порядка полувека, а а смысле бизнес-логики — порядка 400 лет, непрерывно меняясь.


                                                                                              И научите меня, как это быстро переписать.

                                                                                                0
                                                                                                А вы уже сталкивались с такой системой или это чисто теоретический вопрос?)
                                                                                                  0

                                                                                                  Да, речь про одну американскую страховую компанию, даже код видеть приходилось. Впрочем, почти в любой большой страховой компании в США примерно так.

                                                                                                +1
                                                                                                привет, восстановление контекста через интервью с бывшим сотрудником, ушедшим на пенсию

                                                                                                На пенсию ещё по-божески, по-моему, по сравнению с уволенным со скандалом.

                                                                                                  +3
                                                                                                  Настоящее легаси — это ...

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


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

                                                                                                    0

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

                                                                                                    0
                                                                                                    Вот прям в яблочко. Причем достаточно иметь в своей системе треть от вышенаписанного, чтобы начать нервно икать читая про «серебряные пули микросервисов» )
                                                                                                    +1
                                                                                                    спасибо за статью. Нужно взять на заметку.
                                                                                                      0
                                                                                                      Пожалуйста. :) Рад, что понравилась.
                                                                                                      +1
                                                                                                      Настоящее легаси — это ...

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

                                                                                                      JohnRico спасибо.
                                                                                                        +1

                                                                                                        Хех. Остаться с командой, которая ъоть что-то знает про проект, уже хорошо. А вот если остался один…

                                                                                                        0

                                                                                                        Slate Star Codex писал про баланс между Stress и Slack в эволюции и цивилизации. https://slatestarcodex.com/2020/05/12/studies-on-slack


                                                                                                        Более глубокого размышления о балансе стресса и свободы (как на русский slack перевести?) я не видел. Любые вопросы эволюции кода полностью описываются в этих терминах. Есть стесс (бизнес, которому "надо вчера"), есть потребность в свободе (slack), чтобы инвестировать в долгосрочные изменения, попытки структурных улучшений (которые не всегда успешные) и т.д. Те, у кого stress 100% выигрывают в сверхкороткой преспективе, но имеют overfit и очень низкую гибкость. Те, у кого slack 100% ничего не делают. Баланс между stress и slack даёт самые офигенные результаты. (Это я кратко пересказал очень умную статью по ссылке выше).

                                                                                                        Only users with full accounts can post comments. Log in, please.