/dev/energy

Вам не нужен IT-консалтинг Странно слышать такое от консультанта? Кажется, что я стреляю себе в ногу. Но для ряда компаний, которые приходят ко мне с запросом, этот самый запрос окажется пустой тратой денег. В этой проблеме прослеживается паттерн поведения. Компания зовёт консультанта, он проводит диагностику, находит проблемы, предлагает изменения, описывает стратегию. Поначалу даже команда кивает, а изменения внедряются. Но часто ещё до ухода консультанта через пару месяцев всё возвращается на место. Культура ест стратегию на завтрак Эту фразу приписывают Питеру Друкеру, но сейчас не об авторе, а о сути. Хороший консультант не приносит идею со стороны, в которую никто не верит. Всё наоборот. На диагностике люди сами называют проблемы. И часто сами же предлагают половину решений. Более того, суть изменений собирается из того, что команда давно знает, но не может сказать вслух или довести до конца. То есть с идеей все согласны. А вот исполнять её будет та же культура, которая довела компанию до текущего состояния. Пока консультант рядом, вроде бы есть внешний ритм и кто-то, кому не всё равно. Убираешь его, и система откатывается в привычное состояние. Я это видел не раз. Процессы на бумаге есть, ретро проводятся, дашборды красивые. А решения по-прежнему принимаются набегом, приоритеты меняются от настроения сверху, и никто не готов сказать «нет». Так что, консалтинг бесполезен? Бесполезен консалтинг для компании, которая не собирается меняться. Если организация хочет купить отчёт или красивую презентацию, мой консалтинг не нужен. Более того, если запрос звучит как, «нам надо починить разработку», а бизнес называет процессы, где надо думать медленными, то это тоже странная трата денег. Консультант - это лечащий врач Есть запрос, с которым приходят чаще, чем кажется: «посмотрите на нашу разработку». Подсознательно в таком запросе люди ожидают: «… и скажите, что мы всё делаем правильно». Формулируют, конечно, иначе. Почему-то от консультанта ждут именно одобрения, группы поддержки. Пришёл, похвалил, подтвердил решения руководства, ушёл. Все довольны, никому не больно. Но ведь консультант приходит, когда что-то болит. И назначает лечение, которое может быть неприятным: менять процессы, перестраивать команды, иногда расставаться с людьми, менять образ мышления. Врач не меняет диагноз, потому что он пациенту не понравился. Консультант, который подстраивает выводы под настроение заказчика - это дорогой аниматор. Как понять, что компания не готова меняться Признаки видны уже на первых встречах:  - «Мы уже так пробовали, у нас не работает» - на любое предложение, до разбора деталей.  - Спонсор изменений есть, а полномочий у него нет. Все решения всё равно проходят через того, кто и создал текущую ситуацию. И спорить с ним бесполезно. - Проблему формулируют как «почините их» - команду, отдел, соседей. Себя из уравнения вычитают.  - На диагностике всё хорошо, все молодцы, проблем нет. Тогда зачем звали? Если лечиться никто не собирается, то и врач не поможет. Можно сколько угодно выписывать рецепты, но таблетки пить придётся самим. #консалтинг #процессы

Просто классные бизнес-книги Завершу я подборку книжками, которые я решил выделить, потому что они ну прям интересные! Причем, я бы рекомендовал их читать и менеджерам, и разработчикам, которые хотят быть настоящими Senior или Staff инженерами. Цель (Элияху Голдратт). Книжка построена в формате романа, но является основой Теории ограничений. Заходит гораздо легче, чем кажется по описанию. Но я выделяю её потому, что она помогает полечить суету «Надо брать в работу все». Она в первую очередь фокусирует на доведении как можно большего количества дел до конца. Кстати, по Теории ограничений я уже писал здесь несколько постов раньше. Преимущество повторяемости (Олег Вишняков). Практическое руководство по описанию бизнес (и не только) процессов. У нас в головах все процессы кажутся логичными, понятными и крутыми. Но как только мы перекладываем их в описание, начинаются сложности с тем, чтобы донести мысль другому человеку. Я настоятельно рекомендую книжку не только менеджерам, но и разработчикам, потому что в System Design собеседованиях я очень часто вижу, как кандидаты не в состоянии внятно обрисовать даже простую схему. А книжка помогает познакомиться с различными нотациями в доступном и неунылом формате. Найти идею (Генрих Альтшуллер). Когда-то давно в компанию, в которой я работал, пригласили лектора по ТРИЗ (Теория решения изобратетельских задач). И тогда я молодой-зеленый ни разу не понял, зачем мне это сакральное знание. Но когда ты выходишь в зону решения проблем, где есть противоречия (скажем, надо делать быстро, но качественно), методы отыскания решений становятся очень полезными. Да и просто узнать о том, как изящно решали и решают инженерные задачи другие люди, лично мне было очень интересно! Статистика и котики (Владимир Савельев). Если вы вдруг решили вспомнить институтский курс матстата или столкнулись с задачей выработки новой метрики или анализа результатов, но вдруг забыли, что такое распределения, книга для вас. Наглядно, в картинках, все, как я люблю :) Промт инжиниринг для LLM (Джон Берриман, Альберт Циглер) и Промт инжиниринг для GenAI (Джеймс Феникс, Майк Тейлор). Если ваша работа с AI инструментами больше похожа на гугление или чат с приятелем, но вы хотите систематизировать свою работу, то книжки стоит почитать. Каких-то нереальных инсайтов я из них не получил, но скорее закрыл для себя пробелы в работе современных агентов и нейросеток, оптимизировал свои запросы, стал получать более качественный результат с меньшим количеством шагов. Так что прочитать стоит. #книги

Что? Уже шестой выпуск?! Да-да, "Пенсионный скрипт" не сбавляет обороты! Вы думали, мы только технарей зовём? Как бы ни так! В этом выпуске у нас в гостях Наташа Ковалерова - интернет-маркетолог и владелица турбазы на Алтае! Слушайте наш подкаст в Spotify, Яндекс Музыке, Apple Podcasts и много ещё где по ссылке: https://script.mave.digital/ep-7. Вы же не забыли подписаться и поставить лайк? ❤️

Для менеджера Продолжу свою подборку книжек. Теперь поговорю о книжках, которые помогают в повседневной работе менеджера. Getting Things Done (Дэвид Аллен). Самая первая бизнес-книга, которую я вообще прочитал. Это система, по которой я работаю до сих пор. Аллен предлагает систему организации задач, которая пережила два десятилетия хайпа и осталась рабочей. Если вы не дочитали это сообщение до конца, пометьте его непрочитанным и вернитесь к нему позже ;) Идеальный руководитель (Ицхак Адизес). Книга, которая помогает понять, на чем тебе надо сфокусироваться. И еще про то, что в команде тебе придется осознанно отдавать с себя роли. Да, ты можешь сделать сам, молодец. Но от тебя ожидают другого. Чего? Надо читать книжку и общаться с руководителем и коллегами. Тайм-драйв (Глеб Архангельский). Русскоязычная классика по тайм-менеджменту, с акцентом на практику, а не теорию. Мне эта книга зашла не только потому, что хорошо структурирует работу со временем, но и потому, что до книги часть механик, описанных в книге, я уже создал для себя сам. 45 татуировок менеджера (Максим Батырев). Несмотря на то, что книжку надо читать в солнечных очках, так как ЧСВ автора может повредить ваши глаза, сами короткие правила из личного опыта с фокусом именно на российскую специфику я нахожу ценной. Радикальная прямота (Ким Скотт). Если вы до сих пор мучаетесь, когда на 1-1 даете человеку понять, что он может работать лучше, книгу однозначно надо прочитать. В том, чтобы сказать человеку о том, что что-то делается слабо, нет ничего плохого, но надо делать это правильно. Это тоже проявление заботы о сотруднике. Принцип пирамиды Минто (Барбара Минто). Ох, как же я туго пишу документы, вы бы знали. Когда надо взять большой объём информации и структурировать его, подход Барбары Минто - это классная механика, что чтобы все всё могли понять с первого раза. Полезно для любого, кто пишет длиннее одного абзаца. Это, кстати, хорошее продолжение к книгам «Текст по полочкам» и «Пиши сокращай». Бонус-трек. Мне посчастливилось пообщаться и даже поконсультировать автора этой замечательной книги :) Мама, я - тимлид (Марина Перескокова). Эта книжка попала мне в руки, когда я уже руководил несколькими командами и работал CTO, но я все равно считаю её одной из лучших книг для тех, кто только начинает руководить командами. В ней нет воды, есть классные рецепты базовых гигиенических процессов. Однозначно рекомендую! #книги #менеджмент

Книги на лето Я люблю отдыхать в бархатный сезон. Но когда дети идут в школу, выбора особенно не остаётся. Июнь и июль - граница кварталов, и там гора работы. Поэтому август - мой вариант! Но это ведь не повод не писать в канал 😁 В отпуске появляется больше времени на книги, до которых всё не доходили руки. Поэтому я решил поделиться с вами подборкой моих любимых книг. Я разделил её на три части: System Design, книги для менеджера, и просто классные бизнес-книги. System Design Начнем с сисдиза. Я очень люблю этот тип интервью, причем как в роли интервьюера, так и в роли кандидата. Ведь именно здесь можно поразгонять темы на совершенно разных уровнях! Но подготовку никто не отменял, поэтому ниже - мой личный топ для подготовки к System Design interview! Fundamentals of Software Architecture (Марк Ричардс, Нил Форд). Книга про стили архитектуры, как их выбирать под конкретную задачу. По сути книга говорит о компромиссах в выборе решения, потому что идеальной архитектуры не существует. Я считаю, что подготовку стоит начинать именно с этой книги, чтобы задать для себя оптимальный фреймворк размышлений об архитектуре. Designing Data-Intensive Applications (Мартин Клеппман). Ну, это уже легенда. Она же «книжка с кабанчиком». По сути это книга рецептов для размышлений об архитектуре. Она рассказывает о том, как устроены базы данных, система контрактов и еще много-много чело. Что круто, в ней последовательно разбираются принципы. Поэтому книжку надо читать, проецируя написанное на личный опыт. Иначе все прочитанное будет восприниматься абстракцией. Implementing Domain-Driven Design (Вон Вернон). Она же «красная книга» по DDD. Рассказывает она в примерах о том, как строится доменная архитектура - от стратегического дизайна до тактических паттернов. Сразу скажу, что перевод на русский максимально кривой и коверкает общепринятые понятия. Но если постоянно держать это в голове, то книжка весьма доступно объясняет сложную концепцию проектирования доменов и сервисов на их базе. Learning Domain-Driven Design (Влад Хононов). Эту уже более качественный заход в DDD, но более сложный. Я бы рекомендовал читать её после Клеппмана, хотя если справитесь с ней, знания точно будут качественно структурированными. API Design Patterns (Джей Джей Гивакс). Эта книжка отлично дополняет Книжку с кабанчиком, потому что на практике и с примерами разбирает паттерны проектирования API. Более того, в ней встречается то, что любят спрашивать на собеседовании. Building Microservices (Сэм Ньюман). Эту книжку советую читать в дополнение к книгам по DDD, так как тут важные мысли о применимости микросервисов и их отличиях от других архитектур. Но тут отмечу, что русский перевод так себе. Впрочем, без знаний тоже не останетесь, если будете читать на русском. EventStorming (Альберто Брандолини). Не столько книга, сколько процесс описания CJM. Сама книга до сих пор не дописана, имейте это в виду. Но классно помогает в проектировании систем, особенно на основе DDD. Бонус-трек: хороший сайт с разбором задач по СисДизу. #книги #сисдиз #собеседования

Говоря про пенсию, многие из нас представляют загородный дом, сад с качелями, теплицу и вот это вот всё. Поэтому мы не могли не поговорить про то, как же устроена загородная жизнь. Тем более, когда в гостях у нас не только профессионал в приусадебном хозяйстве, но и руководитель конференции TeamLead Conf и автор канала Мир глазами другого человека - Рома Ивлиев. Слушайте наш подкаст в Spotify, Яндекс Музыке, Apple Podcasts и много ещё где по ссылке: https://script.mave.digital/ep-6. И как всегда - подписывайтесь, пишите комментарии, закидывайте идеи. Мы рады всем!

Думай медленно, разрабатывай быстро Все мои команды сейчас используют подход Tech Design Review. Мы применяем его для проработки больших частей системы, обсуждения архитектуры, создания новых сервисов. Года четыре назад этот подход у нас только-только стартовал. Я писал в команде первый TDR, и на тот момент мне этот процесс показался занудным и бюрократичным. Но сейчас я сторонник этого подхода и активно топлю за то, чтобы команды выделали время на написание и защиту. TDR - это наша локальная разновидность RFC. RFC (Request for comments) - это документ, где инженер описывает предлагаемое решение до того, как написан код, и выносит его на обсуждение. Основная идея - обсуждать замысел в модели, пока он ещё дёшев. Обсуждать готовую систему поздно, ведь она уже создана, и любое улучшение - это уже переделывание и, скорее всего, костыли. В компании, которую я консультирую, RFC не писали. Делали сразу в лоб: есть задача - есть код. Быстро же. С другой стороны команда на тот момент уже увязла в постоянных исправлениях после релизов. Проведя несколько встреч, мы начали внедрять RFC. Команда сопротивлялась, приходилось тратить время, доказывать что-то. Хорошо, что были early adopters, которые все таки попробовали пойти по процессу. И тут как в меме - «Вот это поворот!». Оказывается, если подумать на старте, можно убрать кучу багов ещё до раскатки. Причем, даже не багов уровня архитектуры, а баги корнеркейсов. «А что будет, если сюда придёт пусто?» или «А что произойдет в полночь?». RFC заставил задать эти вопросы до того, как они превратились в инцидент. Самое дешёвое место починить баг - это модель, макет. И RFC является как раз такой моделью, где решение существует целиком в голове и в тексте, и его можно дешево прокрутить целиком. В коде ты уже видишь фрагмент за фрагментом, а вот целое из виду теряешь. Когда решение проговорено и записано, оно принадлежит команде, а не автору. Через полгода, когда автор в отпуске, а маленькую правку просят срочно, есть документ, объясняющий почему так. Но не подумайте, что это панацея RFC может навредить, если применять его везде. Допустим, на изменение конфига или переименование метода написание RFC - это чистой воды бюрократия. Люди начинают писать документ ради галочки, ритуал вытесняет смысл, и очень скоро RFC ненавидят все. Порог должен быть явным: пишем на решения, которые дорого откатывать или которые затрагивают несколько команд. Если согласование RFC превращается в бег с препятствиями, команда просто перестаёт предлагать изменения. Документ, который задумывался ускорить, начинает замораживать. Поэтому тут важен лёгкий шаблон и как можно более короткий цикл ревью. Защищённый RFC ощущается как гарантия, что всё продумано. Но документ - это гипотеза, а не истина. Реальность на раскатке может  преподнести сюрприз. Как отличить работающий RFC от карго-культа? Если после внедрения RFC у вас стало меньше тупых багов на раскатке, значит RFC работает. Если нагрузки стало больше, а багов столько же, значит проблема пока не там. Например, если в системе всё в принципе горит, то сначала надо убрать пожары, а потом работать с RFC. Также мы с командами различаем разные уровни важности RFC. Например, команда вполне может внутри себя согласовать сервис, который не затронет всех. Но вот сквозной сервис очень важно обсуждать всем вместе. И это еще одна часть управления ценами разработки, так как RFC помогает посмотреть на все четыре цены на старте! Кстати, хотите побольше поговорить про практику RFC? Или и так понятно? #разработка #процессы #tdr

Пусть программисты сразу пишут хорошо Сколько же раз я слышал этот лозунг от разных людей. Произнося эту фразу, руководители пытаются оправдать отсутствие выделенного времени на разработку автоматических тестов в командах. И в 2026 я до сих пор пугающе часто вижу крупные и не очень системы с отсутствующим тестированием. Несколько лет назад я пришёл работать в одну компанию уже в позиции руководителя. Полноценного автотестирования там не было, только зачатки. На момент начала моей работы компания была крохотная, это кое-как спасало. С моим приходом начался новый большой проект, и команда резко выросла: четыре продуктовых команды, не считая инфраструктуры и поддержки. Кода стало генерироваться на порядок больше, а вот тестирование за этим не поспевало. Очень быстро каждый релиз превратился в лотерею «а что же отрыгнет в этот раз». Отвалиться могла любая видимая пользователю часть, и предсказать заранее было нельзя. В какой-то момент я принудительно остановил разработку новых фич. Первый же после этого спринт был чисто техническим, иначе каждый коммит разваливал систему. Через спринт начали осторожно подмешивать продуктовые задачи, потом всё больше. Система стабилизировалась, команда перестала жечь человекодни на починку релизов. А это, в свою очередь, разблокировало бизнес: маленькие итерации, моментальная обратная связь, нормальные A/B-тесты, потому что под ними наконец появилась стабильная и быстрая сборка. Кто же пишет тесты? Разработчик пишет тесты на то, что видно изнутри. Он знает граничные условия своей логики, знает, где она хрупкая, что должно сломаться при неверном входе. Юниты и значительная часть интеграционных тестов - это работа того, кто написал код. Тест здесь часть кода, а не проверка поверх него. Тестировщик закрывает то, что видно уже снаружи и на стыках. Сквозные пользовательские сценарии, регресс через несколько команд и модулей, хитрые комбинации, до которых разработчик, закопавшийся в свою фичу, не успеет дойти. Современный QA - это полноценный инженер, который пишет код на своем уровне, продумывает тест-дизайн, ловит то, что проваливается между командами. Ручная проверка при этом тоже остаётся, но уже как исследование, а не как quality gate. Живой человек находит то, что не формализуешь заранее: странный UX, неожиданный сценарий. Почему ручное тестирование не масштабируется? Потому что ПО невероятно комплексно. Представим простенькую функцию деления одного рационального числа на другое: два float на вход, один в результате. Чтобы убедиться, что она работает не только в идеальных условиях, но и когда пользователь начнет передавать туда всякое, надо проверить и стандартную работу с положительными и отрицательными числами, и попытку передачи туда integer вместо float (не везде же статическую типизацию завезли), и попробовать на ноль поделить. Как видите, уже пачка тестов. Но вроде можем прогнать руками. А таких функций в коде сотни и тысячи! Они объединяются в фичи со своими ветвлениями, состояниями, комбинациями входов. У системы из нескольких модулей число состояний растёт быстрее, чем кто-либо способен прокликать руками. И объём растёт нелинейно. В какой-то момент ручная проверка отстаёт навсегда, и релиз превращается в лотерею, потому что покрыть всю вариативность физически некому. Так пусть программисты просто пишут без багов Не смогут. И дело не в квалификации. Ошибка здесь уже не характеризует разработчика. Она является сопутствующим свойством сложной задачи. Человек не удерживает в голове всю систему целиком, ведь мы можем держать в голове в среднем около 4-5 абстракций. А именно на стыках удержанного и неудержанного баги и живут. «Если хотите быть здоровыми, не болейте». Вроде бы в бой активно вступает AI, который, как человек из Кемерово, придет и молча поправит все. Код будет писать AI, баги исчезнут. Держите карман шире! AI-агент ошибается по той же причине - задача больше и комплекснее, чем помещается в его контекст. Он ещё и генерирует код на порядок быстрее человека, то есть наращивает ту самую вариативность, которую нечем проверить. В итоге получаем больше кода с той же плотностью багов. Поэтому тесты здесь становятся еще важнее! Что тогда такое хорошее тестирование? Многие считают, что X% покрытия тестами - это отличная метрика. Но это заблуждение.  На мой взгляд хорошее тестирование проверяет устойчивое поведение. Тест должен переживать рефакторинг, когда мы меняем внутренности, а тест остается зелёным, потому что снаружи контракт тот же. Тесты должны формировать пирамиду. Много быстрых юнитов на логику, поменьше интеграционных, еще меньше медленных E2E на критичные пользовательские пути. При этом немаловажна скорость! Тест, который идёт двадцать минут и иногда флакает, это барьер, который команда учится обходить. Медленная или флакающая сборка убивает саму идею: смысл теста в мгновенной обратной связи, а не в галочке. Чем платят за отсутствие тестов? Дежурный чинит ночью то, что тест поймал бы на коммите. Это Run с процентами за выгорание. Change замирает, система костенеет. И, что дороже всего, бизнес теряет право на маленькие шаги. Без стабильной сборки нет ни быстрых итераций, ни нормальных A/B, ни оперативной петли обратной связи. Мы жгли человекодни на починку релизов, пока не заплатили этот долг разом. Тесты дают нам право менять систему быстро и не бояться. #процессы #разработка #тестирование #ценаразработки

It's Wednesday, my dudes! Время для нового выпуска "Пенсионного скрипта"! Слушайте на удаленке, в офисе, в машине, в метро и на пляже) Сегодня у нас в гостях Владимир Балун, основатель онлайн-школы Balun.cources, выходец из бигтех-компаний. Поговорим о том, чего стоит создать платформу с курсами, насколько это себя оправдывает и обеспечит ли она спокойную и счастливую пенсию. Слушайте наш подкаст в Spotify, Яндекс Музыке, Apple Podcasts и много ещё где по ссылке: https://script.mave.digital/ep-5. Лайк-шер-Алишер! ❤️

Цена выключателя Мы наконец-то добрались до последней составляющей цены разработки. И это цена, о которой не думает почти никто. Цена Exit. Конечно же нам всем хочется, чтобы фича или система работали всегда. Но рано или поздно мы сталкиваемся с моментом, когда эту часть системы надо убрать. Например, если мы рефакторинг бизнес-процесс целиком, а подсистема встроена настолько плотно, что даже построив систему рядом, выключить старую систему нереально - настолько она вросла в архитектуру.  На одной из моих прошлых работ в логике был большущий модуль, который отвечал за систему распределения товаров по посылкам. Эдакая интерпретация задачи про рюкзак, только решенная в о лоб, а не методами динамического программирования. Мы с командой видели, что возможности оптимизации в той части системы кончились, и приняли решение построить рядом замещающую систему. Когда та была готова, старую надо было выпилить. Мы начали тестировать переход, но поскольку легасевая система была без нормальных тестов и документации, за все время существования на неё завязались и другие системы. А данные вообще пишутся повсеместно. Выпиливание, которое должно было занять день, заняло гораздо больше времени. Срабатала та же ловушка, что с Run. Когда этот кусок делался на этапе стартапа, надо было делать быстро с тем, что есть. В итоге сначала получаем монстра, а потом - некрокод, которы не выпилить, а за него на пустом месте платится налог в виде Run и Change.  Доходит до абсурда. Когда я работал в роли CTO впервые, я поехал в Германию - забирать систему на отчуждение от материнской компании. Мы долгие часы проводили с командой, разбирая, как же устроен изящный на первый взгляд фреймворк. Но вот мы дошли до одного из кусков кода, где у меня состоялся забавный диалог с архитектором Я: Так, а за что отвечает этот класс? Архитектор: Он описывает логику формирования заказа Я: Но почему у него название с окончанием -ext? Архитектор: А, он наследуется от другого класса Я: А почему вы не стали писать логику в классе-родителе? Архитектор: Дело в том, что уже никто не помнит, как там что устроено. Тестов мало. Поэтому мы там ничего не меняем, а пишет классы-расширения. Как думаете, убрать мертвую логику из такого класса-родителя реально? Распределённый монолит из прошлого поста - это еще одна система, у которой цена Exit очень высока. Нельзя независимо отключить сервис, потому что на нём висят пять других . Нельзя удалить неоптимальный столбец в БД, потому что туда напрямую смотрят непонятно, какие сервисы. Цена Exit закладывается на старте теми же решениями, что и Change. Следует изолировать подсистемы вместо того, чтобы встраивать их напрямую. Нужно продумывать прямую и обратную совместимость в данных. Кстати, многие читали Книжку с кабанчиком, но мало кто реально умеет делать то, что в ней описано :)  По сути хороший вклад в Change почти сразу даёт хорошую цену Exit. И тут вся моя серия сходится в одну мысль. Build - единственная цена, которую видно на старте. Остальные три приходят потом и чаще всего - к другим людям. Run будит дежурного, Change тормозит того, кто придёт после вас, Exit достаётся тому, кто застанет конец. Решение «сделать быстро» оказывается совсем не дает скорости. Это решение отправить три кредита в будущее, не спросив тех, кому платить. Зрелость же решений тут не в том, чтобы каждый раз выбирать дорогой и правильный путь. Иногда быстрый хардкод - это вполне себе верное решение. Зрелость в том, чтобы увидеть все четыре цены до старта, назвать их вслух и решить осознанно, где можно сэкономить, записать где и почему, чтобы долг был виден, а не всплыл ночью на корнер-кейсе. #архитектура #разработка #процессы #ценаразработки

Не буду оставлять традицию делиться с вами по выходным красотами разных мест. Сегодня - это озеро Севан. На одном из его берегов можно с удовольствием провести выходные. Правда, не факт, что удастся искупаться. Озеро находится на высоте 2000 метров над уровнем моря. Здешний климат гораздо более холодный, чем в Ереване, расположенном всего лишь в 100 километрах. Здесь дуют ветра, часто меняется погода. Купальный сезон (если можно так выразиться) здесь короткий - вода относительно пригодна для купания с конца июля до конца августа. Тем не менее, это невероятно живописное место с чистейшей водой. По всему периметру озеро окружают горы, но Севан настолько большой, что легко забыть, что ты не на море.

Как выбираться из распределённого монолита В прошлом посте я разобрал, откуда берётся распределённый монолит и почему он хуже обычного. Логичный вопрос: что с этим делать? Капитан Очевидность говорит нам: «Надо переписать всё, как надо». Но в реальности это не сработает. Для того, чтобы переписать все разом, надо тормозить всю разработку. Бизнесу нужны доработки, развитие, а это значит, что выбираться приходится постепенно, маленькими шагами, каждый из которых должен окупаться сам по себе. Поэтому давайте разбираться на практике. Шаг 0. Диагноз Не всякая сильная связность есть распределённый монолит. Поэтому проверяем по признакам: одна БД на несколько сервисов, фиксированный порядок деплоя, синхронные цепочки на критическом пути, релиз-поезд с созвоном. Обычный монолит лечится чуть иначе. Шаг 1. Иногда правильно схлопнуть обратно Непопулярная мысль, но она работает. Если распределение оказалось недостроем, а границы проведены неудачно, то дешевле собрать обратно в модульный монолит, чем достраивать. Модули с явными интерфейсами, один деплой. Понятно, что это не финиш, но это выход из состояния, в котором вы будете платить цену распределённой системы, не получая её плюсов. Шаг 2. Резать по данным, а не по коду Следующая ошибка - начинать с распила репозиториев. Пока таблица общая, сервисы общие, любой из них может её изменить, значит, ни один не владеет своим состоянием. Разделение схемы - это почти всегда первый стоящий шаг. Однако, тут важно понять, как именно будут делить данные. Если говорить общо, то выделяем сервиса-владельца таблицы, убираем прямые запросы соседей, потом физически разносим. А как найти владельца? Для этого хорошо подходит процесс Event Storming, о котором я думаю написать чуть позже. Он в свою очередь реализует процесс выделения ограниченных контекстов с точки зрения DDD, который считаю оптимальным подходом для разделения системы на составляющие части (заметьте, необязательно микросервисы). Шаг 3. Контракты как барьер То, что можно сделать быстро и что сразу снимает часть боли: версионирование контрактов, обратная совместимость по умолчанию. Кстати, об этой отлично написано в Книжке с кабанчиком. Контракты позволяют контролировать изменения между подсистемами, что, в свою очередь, уже работает на снижение связности и усиление зацепления. Правило простое: сначала выкатываем новую версию контракта, потом переводим потребителей, потом убираем старую. Три релиза вместо одного, но каждый независимый и тестируемый. Шаг 4. Добавляем асинхронность Синхронная цепочка вызовов часто делает деплой связанным. Часть таких цепочек вполне нормально превращается в события. Асинхронность не убирает сложность, но переносит её в наблюдаемость и в обработку ошибок. Если у вас нет нормального трейсинга, асинхронный распределённый монолит будет хуже синхронного. Поэтому озаботьтесь построением мониторинга дальше, чем наблюдением за CPU/RAM/HDD. Шаг 5. Как не скатиться в новый недострой Распределённый монолит появляется не только потому, что команда не знает про bounded context и DDD (хотя, и поэтому тожу). Но зачастую еще и потому, что команда не отстояла ресурс на обеспечение технического качества. Ведь бизнесу по сути не очень важно, какой архитектурой оперирует ПО. Считайте цену Change. Сколько человеко-дней уходит на согласование трёх релизов. Сколько стоит откат. Сколько времени дежурный тратит ночью на разбор чужого контракта. Это цифры, с которыми можно прийти и попросить долю ресурса. Вы уже выходите не на рефакторинг, а на снижение конкретной статьи расходов. Общий принцип: каждый шаг должен приносить пользу сам по себе, даже если следующего не будет. Тогда недострой перестаёт быть смертельным, появляются вехи. На моей практике распил одного такого монолита занимает около 1,5 - 2 лет работы в параллель с выполнением бизнес-задач. Поэтому будьте готовы к таким цифрам. А вы как выбирались? Или всё ещё катитесь по цепочке? #разработка #процессы #ценаразработки

Слышите этот звук? Вам не показалось! Новый выпуск "Пенсионного скрипта" несется по просторам Интернета! У нас в гостях Евгений Антонов, ведущий технический менеджер в Yandex Infrastructure, автор канала "Тимлид Очевидность", сооснователь сообщества для руководителей "Management Hub" и один из ведущих подкастов "Кода Кода" и "Три тимлида заходят в бар". Мы постим этот пост в телеграм-канале, чтобы поговорить о телеграм-каналах! Как тебе такое, West Coast Customs?! Насколько сообщества помогают вне работы? Как трудно их вести? Что, если тебя отменят? Слушаем новый выпуск и узнаём от Жени кучу инсайтов. Слушайте наш подкаст в Spotify, Яндекс Музыке, Apple Podcasts и много ещё где по ссылке: https://script.mave.digital/ep-4. И конечно же подписывайтесь, пишите комментарии, закидывайте идеи. Мы рады всем!