🧑💻 Почему на интервью не проверяют прикладные скиллы и зачем нужен лайвкодинг?
Часто можно встретить мнение, что алго-секция и лайвкодинг - не нужны, и компаниям* следует проверять знания, которые непосредственно применимы в работе.
* Рассуждения в данном посте преимущественно применимы к большим компаниям с сотнями и тысячами сотрудников, где найм идет потоком без остановки.
Попробую высказать непопулярное мнение в защиту ненавистного формата.
Основные моменты
1️⃣ Во всем мире подобные интервью стали своеобразным стандартом - метрикой для оценки инженера, поэтому ее легко применить и адаптировать под себя.
2️⃣ Такой формат легко масштабируется. Когда у тебя сотни заявок в неделю, то легко создавать воронку из нескольких собеседований, как это делают Биг Техи.
3️⃣ Так или иначе, алгоритмы и структуры данных - основа CS и работы программиста. Без их понимания невозможно стать сильным инженером.
4️⃣ Лайвкодинг буквально перемещает тебя в зону дискомфорта и стресса. Во время интервью важно оценить, насколько ты способен с ним справляться.
5️⃣ Очевидно, что компания из десятка человек хочет получить лучшего для "перекладывания json", а если все справились отлично, то как выбрать?
6️⃣ Подготовка интервью, на котором бы проверялись реальные скиллы для работы, очень ресурсоемкий процесс, который сложно масштабировать.
Конечно, так или иначе, но большинство интервью "хакается". Сейчас много возможностей, чтобы получить информацию изнутри или заплатить ментору, который тебя подготовит к реальному собесу через мок-интервью.
Поэтому кроме проверки технических скиллов существуют так называемые "поведенческие интервью" (behavioral interview), где идет уже проверка софтов и которую уже хакнуть или натренировать сложнее. По крайней мере, заученный текст популярных ответов или неискренность будут сразу бросаться в глаза.
Что на практике
В посте прикрепил табличку по MAANG'у, в которой наглядно представлено количество этапов:
- Recruiter Screen - быстрый созвон, чтобы обсудить ожидания и соответствие компании
- Tech Phone Screen - лайвкодинг, вайт-борд и пр.
- Onsite Rounds - смесь кодинга, системного дизайна и поведенческих раундов
В среднем насчитывается 7 интервью, что не мало! Но вполне допустимо для компаний такого уровня.
Комфортный режим
Для всех остальных по эмпирическим данным предельное комфортное количество: 5 интервью (для редких позиций типа: лидов, директоров, архитекторов - вполне может быть другое число, так как роль ответственная).
Например, для backend инженера:
0) быстрый созвон с рекрутером, чтобы познакомиться с компанией
1) быстрый тех. скрининг (не более 30 минут)
2) секция лайвкодинга (пара задач с литкода easy/medium)
3) платформенная секция, где спрашивается специфика домена, в котором предстоит работать
4) сист. дизайн (для высоких грейдов)
5) финальное интервью с командой без технических вопросов
Столько этапов предстоит пройти в Авито. И мне до сих пор кажется это адекватным (у меня, правда, было аж три финальных интервью, чтобы подобрать идеальную команду).
В Касперском, например, всего 3 этапа (все технические секции схлопываются в одну большую).
А в Т-банке то ли 4, то ли 5 (пишите в комментариях, если знаете, сколько точно).
Так или иначе, но адекватность компании можно оценить по тому, как она выстраивает свой процесс найма и сколько времени вам необходимо потратить на трудоустройство в нее.
Тестовое задание
Еще стоит кратко отметить, что тестовое задание на позиции >=middle для меня является своеобразным красным флагом.
В 2025 году это выглядит не очень здоровой практикой (говорю как человек, который решал однажды тестовое, где нужно было написать алгоритм сортировки очень больших файлов, выполнение которого занимало бы не более минуты).
Поделитесь опытом сколько у вас было этапов и как вы относитесь к такому количеству интервью?
Осуждаете ли лайв-кодинг? :)
@time2code
Часто можно встретить мнение, что алго-секция и лайвкодинг - не нужны, и компаниям* следует проверять знания, которые непосредственно применимы в работе.
* Рассуждения в данном посте преимущественно применимы к большим компаниям с сотнями и тысячами сотрудников, где найм идет потоком без остановки.
Попробую высказать непопулярное мнение в защиту ненавистного формата.
Основные моменты
1️⃣ Во всем мире подобные интервью стали своеобразным стандартом - метрикой для оценки инженера, поэтому ее легко применить и адаптировать под себя.
2️⃣ Такой формат легко масштабируется. Когда у тебя сотни заявок в неделю, то легко создавать воронку из нескольких собеседований, как это делают Биг Техи.
3️⃣ Так или иначе, алгоритмы и структуры данных - основа CS и работы программиста. Без их понимания невозможно стать сильным инженером.
4️⃣ Лайвкодинг буквально перемещает тебя в зону дискомфорта и стресса. Во время интервью важно оценить, насколько ты способен с ним справляться.
5️⃣ Очевидно, что компания из десятка человек хочет получить лучшего для "перекладывания json", а если все справились отлично, то как выбрать?
6️⃣ Подготовка интервью, на котором бы проверялись реальные скиллы для работы, очень ресурсоемкий процесс, который сложно масштабировать.
Конечно, так или иначе, но большинство интервью "хакается". Сейчас много возможностей, чтобы получить информацию изнутри или заплатить ментору, который тебя подготовит к реальному собесу через мок-интервью.
Поэтому кроме проверки технических скиллов существуют так называемые "поведенческие интервью" (behavioral interview), где идет уже проверка софтов и которую уже хакнуть или натренировать сложнее. По крайней мере, заученный текст популярных ответов или неискренность будут сразу бросаться в глаза.
Что на практике
В посте прикрепил табличку по MAANG'у, в которой наглядно представлено количество этапов:
- Recruiter Screen - быстрый созвон, чтобы обсудить ожидания и соответствие компании
- Tech Phone Screen - лайвкодинг, вайт-борд и пр.
- Onsite Rounds - смесь кодинга, системного дизайна и поведенческих раундов
В среднем насчитывается 7 интервью, что не мало! Но вполне допустимо для компаний такого уровня.
Комфортный режим
Для всех остальных по эмпирическим данным предельное комфортное количество: 5 интервью (для редких позиций типа: лидов, директоров, архитекторов - вполне может быть другое число, так как роль ответственная).
Например, для backend инженера:
0) быстрый созвон с рекрутером, чтобы познакомиться с компанией
1) быстрый тех. скрининг (не более 30 минут)
2) секция лайвкодинга (пара задач с литкода easy/medium)
3) платформенная секция, где спрашивается специфика домена, в котором предстоит работать
4) сист. дизайн (для высоких грейдов)
5) финальное интервью с командой без технических вопросов
Столько этапов предстоит пройти в Авито. И мне до сих пор кажется это адекватным (у меня, правда, было аж три финальных интервью, чтобы подобрать идеальную команду).
В Касперском, например, всего 3 этапа (все технические секции схлопываются в одну большую).
А в Т-банке то ли 4, то ли 5 (пишите в комментариях, если знаете, сколько точно).
Так или иначе, но адекватность компании можно оценить по тому, как она выстраивает свой процесс найма и сколько времени вам необходимо потратить на трудоустройство в нее.
Тестовое задание
Еще стоит кратко отметить, что тестовое задание на позиции >=middle для меня является своеобразным красным флагом.
В 2025 году это выглядит не очень здоровой практикой (говорю как человек, который решал однажды тестовое, где нужно было написать алгоритм сортировки очень больших файлов, выполнение которого занимало бы не более минуты).
Поделитесь опытом сколько у вас было этапов и как вы относитесь к такому количеству интервью?
Осуждаете ли лайв-кодинг? :)
@time2code
На прошлой неделе заметил, что одна из RPC-ручек стала отвечать медленно. Решил выяснить в чем проблема.
Поднял трейсы микросервиса, посмотрел профили через pyroscope - стало понятно, что проблема в медленном запросе.
Запрос был простым, были нужные индексы, но почему-то в какой-то момент он стал выполняться ощутимо медленнее.
Несмотря на отсутствие в стандарте SQL команд для изучения запроса, в большинстве баз данных есть возможность использовать специальные команды для построения плана и анализа выполнения запросов.
Прикрепляю наглядную табличку.
PostgreSQL EXPLAIN
Так как у нас PostgreSQL, то используя
EXPLAIN ANALYZE в связке мы получаем мощные возможности для анализа запросов.После выполнения на интересующего запроса можно увидеть что-то подобное:
Nested Loop (cost=0.10..32.99 rows=4 width=85) (actual time=0.056..123.456 rows=3 loops=1)
-> Index Scan using uidx_elem_backlog_id on backlog bl (cost=0.05..2.65 rows=1 width=8) (actual time=0.034..0.035 rows=1 loops=1)
Index Cond: (backlog_id = '1168201980'::bigint)
-> Index Scan using idx_backlog_element_backlog_id on backlog_element elem (cost=0.05..30.32 rows=13 width=93) (actual time=0.019..123.421 rows=3 loops=1)
Index Cond: (backlog_id = bl.id)
Filter: (deleted_at IS NULL)
Rows Removed by Filter: 2
Planning time: 0.309 ms
Execution time: 123.456 ms
Как детально анализировать, я описал в статье, но базово нас интересует 2 вещи:
1. Cost - оценочная стоимость операции в у.е. => (cost=0.10..32.99) - видим начальную стоимость до возвращения первой записи и общую стоимость возвращения всех записей. В большинстве случаев нас будет интересовать общая стоимость.
2. Execution time - время выполнения (если применяется ANALYZE).
EXPLAIN ANALYZE с осторожностью, так как он действительно выполняет запрос и может изменить данные. Для безопасного использования оборачивайте в транзакцию:BEGIN;
EXPLAIN ANALYZE ...;
ROLLBACK;
Составной индекс (рабочий кейс)
Благодаря EXPLAIN я заметил, что у меня тратилось лишнее время на фильтрацию итоговой выборки, а это легко можно оптимизировать с помощью составного индекса по нескольким столбцам.
Создав индекс, получил ускорение запроса на 50% и решил проблему медленного времени выполнения.
Более подробно кейс рассматриваю в блоге, написал на эту тему небольшую статью и дал базовые рекомендации по работе с этой командой.
@time2code
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5
Чем опасен разрыв контекста?
Собирался написать про дорогое переключение контекста, возможно, провести аналогию с процессами и потоками системы, как случайно наткнулся на свежую статью, где подробно разбирают тему и приводят красивые картинки, конкурировать с которыми бессмысленно.
Сперва немного расстроился, а потом взбодрился и даже порадовался, что так хорошо проиллюстрировали мысль, которую хотел обозначить.
Если нет времени на статью, то вот ключевая цитата:
Внеплановый митинг посреди рабочего времени, звонкая нотификация о новом сообщении - все может выбить из колеи и творческого процесса, которым является разработка.
Вот и получается, что при 8-часовом рабочем дне, двух-трех митингах в день и всего лишь 4-5 упоминаний в рабочих чатах у нас остается менее 5 часов на разработку.
И это, если мы не оставляли своих задач, а просто отвлеклись и попросили нас не беспокоить, то есть не потратили еще дополнительных 10-20 минут на ответ или объяснение того, что написано в документации, которую вы скидывали вчера.
В прошлом году анализировал сколько времени ушло на созвоны и цифра была около 20 000 минут.
Если тема откликнется, то сделаю замер, сколько реально времени в день уходит на код (включая размышления о нем).
Проблема ясна, но что с ней можно сделать?
В статье, на которую ссылаюсь выше, есть советы как быть продуктивным, быстрее входить в состояние потока и т.д.
Я хочу выделить только один, так как хоть и пытаюсь быть эффективным, но меня так или иначе раздражает философия "слепого достигаторства" и следованию карго-культу, обложившись матрицами Эйзенхауера, помодоро-таймерами и бесконечными туду-листами.
1️⃣ Оставляем зацепки контекста
Оставляйте комментарии в IDE о том, что вы делали, чтобы была возможность быстро восстановить разрушенный контекст, так называемые "хлебные крошки".
Я это делаю везде: в текстовом редакторе, черновике документа конфлюенс, на миро-доске и пр. Это отлично работает и просто мастхэв, чтобы вернуться в состояние, которое было до отвлечения.
Смысл в том, чтобы выгружать свой контекст и формализовать его.
Во-первых, помогает иначе взглянуть на проблему, а во-вторых, это необходимость на случай, когда вас отвлекли, и вы пытаетесь потом вернуться в работу.
Как можно еще себе помочь?
2️⃣ Фокус дня
Чтобы не завязнуть в длинных туду-листах, можно фокусироваться на важных событиях дня, сужая скоуп задач, убрав все ненужное.
Уже писал про свой фреймворк, который мне помогает. В таких вещах важно экспериментировать и найти то, что работает для вас.
3️⃣ Ставим защитный барьер
Работая над важными задачами, не пренебрегайте режимами "Не беспокоить" и соответствующими статусами в мессенджерах - это помогает управлять ожиданиями собеседника, если он от вас хочет получить обратную связь.
4️⃣ Игнорируем "срочное"
Это навык, который мне осваивать труднее всего. Я такой человек, что люблю оперативно отвечать, если у меня есть возможность. И я ожидаю того же отношения от других.
Поэтому, если я отвлекся на сообщение, то мне быстрее сразу ответить или написать, что отвечу позже, если это требует времени.
Таким образом, в первую очередь, я облегчаю жизнь себе - мне не нужно помнить о том, что кто-то ожидает обратную связь или обдумывать то, как я ему буду отвечать.
Важно оценивать степень срочности и важности.
Если лежит прод, то тут уже не до состояния потока и переживаний о контексте - сразу чинить.
Но зачастую 90% поступающих запросов могут подождать, а некоторые из них - даже сами и разрешатся, так как человек, формализовав свой вопрос нередко сразу находит на него ответ :)
@time2code
Собирался написать про дорогое переключение контекста, возможно, провести аналогию с процессами и потоками системы, как случайно наткнулся на свежую статью, где подробно разбирают тему и приводят красивые картинки, конкурировать с которыми бессмысленно.
Сперва немного расстроился, а потом взбодрился и даже порадовался, что так хорошо проиллюстрировали мысль, которую хотел обозначить.
Если нет времени на статью, то вот ключевая цитата:
Исследование от UC Irvine показывает, что разработчикам необходимо в среднем 23 минуты, чтобы полностью заново выстроить свой фокус после того, как их отвлекли.
Внеплановый митинг посреди рабочего времени, звонкая нотификация о новом сообщении - все может выбить из колеи и творческого процесса, которым является разработка.
Вот и получается, что при 8-часовом рабочем дне, двух-трех митингах в день и всего лишь 4-5 упоминаний в рабочих чатах у нас остается менее 5 часов на разработку.
И это, если мы не оставляли своих задач, а просто отвлеклись и попросили нас не беспокоить, то есть не потратили еще дополнительных 10-20 минут на ответ или объяснение того, что написано в документации, которую вы скидывали вчера.
В прошлом году анализировал сколько времени ушло на созвоны и цифра была около 20 000 минут.
Если тема откликнется, то сделаю замер, сколько реально времени в день уходит на код (включая размышления о нем).
Проблема ясна, но что с ней можно сделать?
В статье, на которую ссылаюсь выше, есть советы как быть продуктивным, быстрее входить в состояние потока и т.д.
Я хочу выделить только один, так как хоть и пытаюсь быть эффективным, но меня так или иначе раздражает философия "слепого достигаторства" и следованию карго-культу, обложившись матрицами Эйзенхауера, помодоро-таймерами и бесконечными туду-листами.
1️⃣ Оставляем зацепки контекста
Оставляйте комментарии в IDE о том, что вы делали, чтобы была возможность быстро восстановить разрушенный контекст, так называемые "хлебные крошки".
Я это делаю везде: в текстовом редакторе, черновике документа конфлюенс, на миро-доске и пр. Это отлично работает и просто мастхэв, чтобы вернуться в состояние, которое было до отвлечения.
Смысл в том, чтобы выгружать свой контекст и формализовать его.
Во-первых, помогает иначе взглянуть на проблему, а во-вторых, это необходимость на случай, когда вас отвлекли, и вы пытаетесь потом вернуться в работу.
Как можно еще себе помочь?
2️⃣ Фокус дня
Чтобы не завязнуть в длинных туду-листах, можно фокусироваться на важных событиях дня, сужая скоуп задач, убрав все ненужное.
Уже писал про свой фреймворк, который мне помогает. В таких вещах важно экспериментировать и найти то, что работает для вас.
3️⃣ Ставим защитный барьер
Работая над важными задачами, не пренебрегайте режимами "Не беспокоить" и соответствующими статусами в мессенджерах - это помогает управлять ожиданиями собеседника, если он от вас хочет получить обратную связь.
4️⃣ Игнорируем "срочное"
Это навык, который мне осваивать труднее всего. Я такой человек, что люблю оперативно отвечать, если у меня есть возможность. И я ожидаю того же отношения от других.
Поэтому, если я отвлекся на сообщение, то мне быстрее сразу ответить или написать, что отвечу позже, если это требует времени.
Таким образом, в первую очередь, я облегчаю жизнь себе - мне не нужно помнить о том, что кто-то ожидает обратную связь или обдумывать то, как я ему буду отвечать.
Важно оценивать степень срочности и важности.
Если лежит прод, то тут уже не до состояния потока и переживаний о контексте - сразу чинить.
Но зачастую 90% поступающих запросов могут подождать, а некоторые из них - даже сами и разрешатся, так как человек, формализовав свой вопрос нередко сразу находит на него ответ :)
@time2code
❤5👍5🔥1
☕️ 25% на код, 75% на тыквенный латте! Сколько времени мы пишем код?
В продолжении прошлого поста я решил сделать замер, чтобы оценить, сколько реально в день уходит на код.
Среднее значение получилось в районе двух-трех часов*.
Это составляет 25% от рабочего дня, что может показаться не так много для программиста.
«Эффективные» менеджеры могут решить, что остальное время идет на тыквенный латте, но это не так. На тыквенный латте нужно не более 15 минут :)
Разберемся, куда уходит время.
* Конечно, есть гораздо более загруженные спринты, здесь лучше собрать аналитику хотя бы за период от 6 месяцев, но описываемые проблемы так или иначе имеют место быть.
✍️ Коммуникации
Это самый большой потребитель вашего времени. Сюда попадает все: Slack, MatterMost, Teams, общение на код-ревью или документах Конфлюенс.
Но что можно реально сделать?
1. Ставить явные блоки в календаре, во время которых включаете режим "Не беспокоить" и переходите в режим Deep Work. Лучше их делать небольшими, например, по 50 минут, чтобы была возможность восстановить свои силы и при необходимости ответить на срочные сообщения.
2. Фасилитировать дискуссию. Если видите, что разговор зашел в тупик, или вы не понимаете, чего хочет собеседник, то попробуйте разбить проблему на пункты и проработайте каждую отдельно. Если изначальная тема раздувается, то рассмотрите вариант - звонок на 10-15 минут, иногда это может быть эффективнее.
3. Выстраивайте границы. Если вы понимаете, что вопрос или тема лишь косвенно относится к вам как к техническому специалисту, и вы больше спорите об организационных моментах или о самом продукте, не стесняйтесь призывать своего лида или продакта - это одна из их обязанностей: снимать с вас нагрузку в виде излишних коммуникаций.
🗣 Встречи
Встречи - это тоже коммуникации, но более формальные и фиксированные в календаре, поэтому их стоит рассматривать отдельно.
В лучшем случае, 30 минут, а в худшем - целый день, плюс затраты на переключение контекста и подготовку к встрече.
Хоть PM и тимлид защищают разработчиков от избытка встреч, но совсем от них избавиться все равно не получится. Одним словом - Agile.
Вы, в свою очередь, как опытный инженер, можете и здесь поучаствовать фасилитатором и предложить отпустить тех участников встречи, которые не нужны для обсуждения темы (включая вас, если понимаете, что не приносите пользу, а просто параллельно работаете с выключенной камерой).
🥱 Рутина
Есть еще несколько категорий, на которые может уйти немало времени.
Например, можно легко полдня потратить на поиск проблемы или локализацию бага. Здесь сложно что-то предложить, кроме как не писать код с багами :)
Но нередко бывает, когда баг чужой, но задета функциональность вашей команды. В любом случае потребуется время, чтобы разобраться кто виноват и торжественно передать для починки в другую команду.
Еще в мире микросервисов и одержимости лучшими DevOps-практиками можно зависнуть на долгое время, если твой ПР не проходит пайплайн, билды падают, а ты всего лишь изменил название константы.
По моему опыту, 90% упавших билдов связаны с проблемами в инфраструктуре или сервисах, находящихся в чужой зоне ответственности.
В категорию рутинных тайм-консьюмеров также попадают различные системы по управлению метаданными, на работу с которыми можно потратить немало времени в виду их несовершенства.
Вывод
Даже, если вы будете следовать всем рекомендациям и станете сверхэффективным, едва ли удастся большую часть времени посвящать написанию кода.
Полагаю, что это особенность работы продуктового разработчика.
Есть ощущение, что, если хочется писать много кода, то нужно заниматься системным программированием или писать опен-сорс.
@time2code
В продолжении прошлого поста я решил сделать замер, чтобы оценить, сколько реально в день уходит на код.
Среднее значение получилось в районе двух-трех часов*.
Это составляет 25% от рабочего дня, что может показаться не так много для программиста.
«Эффективные» менеджеры могут решить, что остальное время идет на тыквенный латте, но это не так. На тыквенный латте нужно не более 15 минут :)
Разберемся, куда уходит время.
* Конечно, есть гораздо более загруженные спринты, здесь лучше собрать аналитику хотя бы за период от 6 месяцев, но описываемые проблемы так или иначе имеют место быть.
✍️ Коммуникации
Это самый большой потребитель вашего времени. Сюда попадает все: Slack, MatterMost, Teams, общение на код-ревью или документах Конфлюенс.
Но что можно реально сделать?
1. Ставить явные блоки в календаре, во время которых включаете режим "Не беспокоить" и переходите в режим Deep Work. Лучше их делать небольшими, например, по 50 минут, чтобы была возможность восстановить свои силы и при необходимости ответить на срочные сообщения.
2. Фасилитировать дискуссию. Если видите, что разговор зашел в тупик, или вы не понимаете, чего хочет собеседник, то попробуйте разбить проблему на пункты и проработайте каждую отдельно. Если изначальная тема раздувается, то рассмотрите вариант - звонок на 10-15 минут, иногда это может быть эффективнее.
3. Выстраивайте границы. Если вы понимаете, что вопрос или тема лишь косвенно относится к вам как к техническому специалисту, и вы больше спорите об организационных моментах или о самом продукте, не стесняйтесь призывать своего лида или продакта - это одна из их обязанностей: снимать с вас нагрузку в виде излишних коммуникаций.
🗣 Встречи
Встречи - это тоже коммуникации, но более формальные и фиксированные в календаре, поэтому их стоит рассматривать отдельно.
В лучшем случае, 30 минут, а в худшем - целый день, плюс затраты на переключение контекста и подготовку к встрече.
Хоть PM и тимлид защищают разработчиков от избытка встреч, но совсем от них избавиться все равно не получится. Одним словом - Agile.
Вы, в свою очередь, как опытный инженер, можете и здесь поучаствовать фасилитатором и предложить отпустить тех участников встречи, которые не нужны для обсуждения темы (включая вас, если понимаете, что не приносите пользу, а просто параллельно работаете с выключенной камерой).
🥱 Рутина
Есть еще несколько категорий, на которые может уйти немало времени.
Например, можно легко полдня потратить на поиск проблемы или локализацию бага. Здесь сложно что-то предложить, кроме как не писать код с багами :)
Но нередко бывает, когда баг чужой, но задета функциональность вашей команды. В любом случае потребуется время, чтобы разобраться кто виноват и торжественно передать для починки в другую команду.
Еще в мире микросервисов и одержимости лучшими DevOps-практиками можно зависнуть на долгое время, если твой ПР не проходит пайплайн, билды падают, а ты всего лишь изменил название константы.
По моему опыту, 90% упавших билдов связаны с проблемами в инфраструктуре или сервисах, находящихся в чужой зоне ответственности.
В категорию рутинных тайм-консьюмеров также попадают различные системы по управлению метаданными, на работу с которыми можно потратить немало времени в виду их несовершенства.
Вывод
Даже, если вы будете следовать всем рекомендациям и станете сверхэффективным, едва ли удастся большую часть времени посвящать написанию кода.
Полагаю, что это особенность работы продуктового разработчика.
Есть ощущение, что, если хочется писать много кода, то нужно заниматься системным программированием или писать опен-сорс.
@time2code
Dependency hell. Есть ли выход?
Очередной раз убеждаюсь, что самое неприятное в разработке - работа с зависимостями.
Еще со времен проектов на .NET постоянно страдал, что программа отказывает запускаться из-за отсутствия какого-нибудь *dll. Хотя ты на 1000% был уверен, что всего должно хватать...
Поэтому, когда перешел на Go и увидел, что все зависимости можно скомпилировать в один бинарный файл, то это как будто просто развязало руки и дало почувствовать больше свободы (представьте, что вам не нужно думать: все ли вы взяли, уходя из дома).
* * *
Сколько времени потребуется, чтобы добавить проверку на еще одну константу в
Порассуждаем:
1) Мы знаем какую константу нужно добавить и куда? -> Да
2) У нас есть юнит-тест на этот
3) Нужно будет протестировать в тестовом окружении
Выглядит как работа на несколько часов. Однако...
1. Оказывается обновить код нужно в библиотеке
2. А еще существует древняя библиотека
Узнаем, конечно, это неожиданно.
Мы поднимаем
3. Проблема с зависимостью понятна: в словаре безвозвратно было удалено одно из значений, которое использовалось в некотором сценарии, а без него уже и юнит-тесты начинают падать...
Из вариантов: сделать быструю заплатку хардкодом и добавлением комментария или можно найти оунеров и разобраться в том, как в текущих реалиях должно все работать и поправить…
4. Когда все проблемы решены, начинаем делать последовательные ПР-ы, сопровождаемые каскадным поднятием версий библиотек, но настроенный CI вносит свои коррективы, сигнализируя "красной" сборкой и предлагая нам так сильно не ускоряться и чуть насладиться моментом резолвинга зависимостей, вручную перезапуская билды и анализируя, что могло пойти не так.
5. Не забываем собрать тестовый контур, чтобы быстрым взглядом оценить, что наши изменения привели к ожидаемому поведению, что мы действительно знали, какую константу нужно править и ничего не сломали в процессе.
Нам нужно поднять множество сервисов с обновленной версией библиотек, иначе весь флоу протестировать невозможно, а без этого мы не можем гарантировать, что ничего не сломалось.
6. Код-ревью везде пройдено. Торжественно мерджим 8-ПРов и выкатываем несколько сервисов.
7. Замечаем одиноко стоящий почти распиленный монолит. У него нет зависимостей, все живет в нем.
Радостно правим одну строчку и делаем всего лишь один ПР, попутно ужасаясь тысяче тестов на CI, которые должны пройти (они не пройдут и ты их будешь побеждать еще 2 дня, по крайней мере, ты готов к этому).
8. Теперь все хорошо, изменения в проде. Бизнес доволен, а ты - ретроспективно улучшаешь оценку своих задач. Тебе теперь известно, что поправить одну константу в "одном месте" занимает больше двух часов и даже больше двух дней.
Ты не понимаешь почему фича имеет такую архитектуру, но ты точно знаешь, что лишняя зависимость - это то, с чем нужно бороться.
@time2code
Очередной раз убеждаюсь, что самое неприятное в разработке - работа с зависимостями.
Еще со времен проектов на .NET постоянно страдал, что программа отказывает запускаться из-за отсутствия какого-нибудь *dll. Хотя ты на 1000% был уверен, что всего должно хватать...
Поэтому, когда перешел на Go и увидел, что все зависимости можно скомпилировать в один бинарный файл, то это как будто просто развязало руки и дало почувствовать больше свободы (представьте, что вам не нужно думать: все ли вы взяли, уходя из дома).
* * *
Сколько времени потребуется, чтобы добавить проверку на еще одну константу в
if? Порассуждаем:
1) Мы знаем какую константу нужно добавить и куда? -> Да
2) У нас есть юнит-тест на этот
if? -> Да, но нужно будет поддержать тест-кейс с учетом новой логики3) Нужно будет протестировать в тестовом окружении
Выглядит как работа на несколько часов. Однако...
1. Оказывается обновить код нужно в библиотеке
dict-lib, которую использует logic-lib, которую используют два сервиса и shared-lib, которую используют еще два сервиса...2. А еще существует древняя библиотека
old-logic-lib, которая серьезно завязана на старое поведение dict-lib при этом очень давней версии. Узнаем, конечно, это неожиданно.
Мы поднимаем
dict-lib до 3.14, но old-logic-lib перестает компилироваться, так как использует версию 2.71, что не позволяет обновить shared-lib, пока не будет устранена проблема с зависимостью.3. Проблема с зависимостью понятна: в словаре безвозвратно было удалено одно из значений, которое использовалось в некотором сценарии, а без него уже и юнит-тесты начинают падать...
Из вариантов: сделать быструю заплатку хардкодом и добавлением комментария или можно найти оунеров и разобраться в том, как в текущих реалиях должно все работать и поправить…
4. Когда все проблемы решены, начинаем делать последовательные ПР-ы, сопровождаемые каскадным поднятием версий библиотек, но настроенный CI вносит свои коррективы, сигнализируя "красной" сборкой и предлагая нам так сильно не ускоряться и чуть насладиться моментом резолвинга зависимостей, вручную перезапуская билды и анализируя, что могло пойти не так.
5. Не забываем собрать тестовый контур, чтобы быстрым взглядом оценить, что наши изменения привели к ожидаемому поведению, что мы действительно знали, какую константу нужно править и ничего не сломали в процессе.
Нам нужно поднять множество сервисов с обновленной версией библиотек, иначе весь флоу протестировать невозможно, а без этого мы не можем гарантировать, что ничего не сломалось.
6. Код-ревью везде пройдено. Торжественно мерджим 8-ПРов и выкатываем несколько сервисов.
7. Замечаем одиноко стоящий почти распиленный монолит. У него нет зависимостей, все живет в нем.
Радостно правим одну строчку и делаем всего лишь один ПР, попутно ужасаясь тысяче тестов на CI, которые должны пройти (они не пройдут и ты их будешь побеждать еще 2 дня, по крайней мере, ты готов к этому).
8. Теперь все хорошо, изменения в проде. Бизнес доволен, а ты - ретроспективно улучшаешь оценку своих задач. Тебе теперь известно, что поправить одну константу в "одном месте" занимает больше двух часов и даже больше двух дней.
Ты не понимаешь почему фича имеет такую архитектуру, но ты точно знаешь, что лишняя зависимость - это то, с чем нужно бороться.
@time2code
👍5🤔1🫡1
Март 2025:
ключевые события
✔️ Много работал над достижением KR из поставленных на текущий год ОКР'ов приоритета P0. По каждому из них обозначил план, каждая часть которого состоит из понятных инкрементов. Если не сбавлять темп, то закрытие ОКР-а выглядит весьма вероятным в текущем квартале.
✔️ Решил системно подойти к изучению тех. литературы и делиться прочитанным. Завел страничку на Бусти, где разбираю модные книжки и делаю выжимки с ключевыми идеями. С мая планирую прикрыть пейволлом. Начал с «Микросервисов» и выложил одну из частей Главы 1, где мы знакомимся с антипаттерном "Большой комок грязи" и погружаемся в "монолитный ад".
✔️ Познакомился с библиотекой fyne.io для создания нативного UI в Go и написал простенький визуализатор работы по алгоритму раунд-робин.
✔️ Попрактиковался избавляться от if.
✔️ Размышлял о модели данных в проекте и практиковал избыточность, а также анализировал возможно ли отказаться от ORM.
✔️ Учился правильно готовить юнит-тесты, проверяя абстрактный эффект при помощи моков.
✔️ Впервые закоммитил в монолит на php (было больно, но не так больно, как поднимать версию зависимости в десятке микросервисов -> пост).
✔️ А еще решил задачу по удалению 15 миллионов строк из продового PG, не блокируя потребителей сервиса и не зависнув надолго. Обязательно хочу про это написать (ключевые слова: dead tuples, autovacuum и прочее).
посты
⭐️ Чем опасен разрыв контекста? -> читать
🔖 Почему на интервью не проверяют прикладные скиллы и зачем нужен лайвкодинг? -> читать
🔖 Кейс из практики: как составной индекс ускорил запрос на 50% -> читать
🔖 Сколько времени мы пишем код? -> читать
🔖 Dependency hell. Есть ли выход? -> читать
#дайджест
@time2code
ключевые события
✔️ Много работал над достижением KR из поставленных на текущий год ОКР'ов приоритета P0. По каждому из них обозначил план, каждая часть которого состоит из понятных инкрементов. Если не сбавлять темп, то закрытие ОКР-а выглядит весьма вероятным в текущем квартале.
✔️ Решил системно подойти к изучению тех. литературы и делиться прочитанным. Завел страничку на Бусти, где разбираю модные книжки и делаю выжимки с ключевыми идеями. С мая планирую прикрыть пейволлом. Начал с «Микросервисов» и выложил одну из частей Главы 1, где мы знакомимся с антипаттерном "Большой комок грязи" и погружаемся в "монолитный ад".
✔️ Познакомился с библиотекой fyne.io для создания нативного UI в Go и написал простенький визуализатор работы по алгоритму раунд-робин.
✔️ Попрактиковался избавляться от if.
✔️ Размышлял о модели данных в проекте и практиковал избыточность, а также анализировал возможно ли отказаться от ORM.
✔️ Учился правильно готовить юнит-тесты, проверяя абстрактный эффект при помощи моков.
✔️ Впервые закоммитил в монолит на php (было больно, но не так больно, как поднимать версию зависимости в десятке микросервисов -> пост).
✔️ А еще решил задачу по удалению 15 миллионов строк из продового PG, не блокируя потребителей сервиса и не зависнув надолго. Обязательно хочу про это написать (ключевые слова: dead tuples, autovacuum и прочее).
посты
⭐️ Чем опасен разрыв контекста? -> читать
🔖 Почему на интервью не проверяют прикладные скиллы и зачем нужен лайвкодинг? -> читать
🔖 Кейс из практики: как составной индекс ускорил запрос на 50% -> читать
🔖 Сколько времени мы пишем код? -> читать
🔖 Dependency hell. Есть ли выход? -> читать
#дайджест
@time2code
👌3🔥1🫡1
Сила единого языка. DDD в действии
В марте согласовывал очередной архитектурный документ по новой фиче, требующей интеграции с сервисами горизонтальной команды.
На согласование ушло в 4 раза больше времени, чем изначально закладывалось.
Почему так вышло
Причина оказалась банальная - непонимание рассматриваемого домена и отсутствие единой терминологии.
Другими словами, один из ревьюеров, когда читал документ, не обратил внимание на зону ответственности проектируемой фичи, а привычная терминология сбила столку, что в совокупности не позволило оценить предлагаемое решение и ввело в замешательство.
Что может помочь
И тут на сцену выходят софт-скиллы.
По тому, как продвигалось согласование документа, мне стало понятно, что существует какая-то проблема или непонимание.
Когда все разумные сроки вышли и асинхронно в мессенджере вопрос не решился, было предложено перевести общение в вербальную плоскость.
За 30 минут я погрузил ревьюера и его коллег в контекст рассматриваемого решения, пояснил непонятную терминологию, которая могла вызвать двусмысленность, и ответил на все возникающие вопросы.
Фактически пропитчил архитектуру своей фичи перед стейкхолдерами, но вместо 30 секунд на это ушло столько же минут.
Результатом встречи стало согласование документа, а также обмен опытом, фичареквестами и будущими планами по совместной работе.
Domain-driven design
Вот так на своем опыте я заново открываю DDD, ключевой концепцией которого является наличие единого языка (Ubiquitous Language), способствующего понятной коммуникации для всех заинтересованных сторон проекта.
В последнее время все чаще слышу про использование или внедрение DDD в работе - обязательно планирую погрузиться в тему и поделиться инсайтами.
Положил к себе в бэклог книжку Domain-Driven Design: Tackling Complexity in the Heart of Software, разберу и выложу со временем здесь.
Кстати говоря, в основе курса по анализу систем, который проходил прошлым летом, лежит стратегический DDD.
↘️ Выводы
1. При составлении любого документа (не только архитектурного) явно обращайте внимание читателей на рассматриваемый контекст и используемую терминологию.
Особенно, если у вас есть внешние ревьюеры (коллеги за пределами вашей команды).
2. Вырабатывайте единый язык в своей команде. Если возникают спорные моменты касательно определений, то останавливайте дискуссию и формально закрепляйте используемые термины, иначе вы будете бесконечно друг с другом спорить, но каждый будет прав в рамках своего контекста.
3. Если вы блокируетесь ожиданием решения, то явно про это говорите. Если чувствуете, что что-то идет не так, то уточните не нужна ли помощь или комментарии.
Хорошим вариантом может быть - встреча на 30 минут для погружения в контекст и закрытия всех возникающих вопросов.
Парадоксально, но сейчас недостаточно говорить на одном языке, чтобы понимать друг друга, нужно еще, чтобы язык был единым.
@time2code
В марте согласовывал очередной архитектурный документ по новой фиче, требующей интеграции с сервисами горизонтальной команды.
На согласование ушло в 4 раза больше времени, чем изначально закладывалось.
Почему так вышло
Причина оказалась банальная - непонимание рассматриваемого домена и отсутствие единой терминологии.
Другими словами, один из ревьюеров, когда читал документ, не обратил внимание на зону ответственности проектируемой фичи, а привычная терминология сбила столку, что в совокупности не позволило оценить предлагаемое решение и ввело в замешательство.
Что может помочь
И тут на сцену выходят софт-скиллы.
По тому, как продвигалось согласование документа, мне стало понятно, что существует какая-то проблема или непонимание.
Когда все разумные сроки вышли и асинхронно в мессенджере вопрос не решился, было предложено перевести общение в вербальную плоскость.
За 30 минут я погрузил ревьюера и его коллег в контекст рассматриваемого решения, пояснил непонятную терминологию, которая могла вызвать двусмысленность, и ответил на все возникающие вопросы.
Фактически пропитчил архитектуру своей фичи перед стейкхолдерами, но вместо 30 секунд на это ушло столько же минут.
Результатом встречи стало согласование документа, а также обмен опытом, фичареквестами и будущими планами по совместной работе.
Domain-driven design
Вот так на своем опыте я заново открываю DDD, ключевой концепцией которого является наличие единого языка (Ubiquitous Language), способствующего понятной коммуникации для всех заинтересованных сторон проекта.
В последнее время все чаще слышу про использование или внедрение DDD в работе - обязательно планирую погрузиться в тему и поделиться инсайтами.
Положил к себе в бэклог книжку Domain-Driven Design: Tackling Complexity in the Heart of Software, разберу и выложу со временем здесь.
Кстати говоря, в основе курса по анализу систем, который проходил прошлым летом, лежит стратегический DDD.
↘️ Выводы
1. При составлении любого документа (не только архитектурного) явно обращайте внимание читателей на рассматриваемый контекст и используемую терминологию.
Особенно, если у вас есть внешние ревьюеры (коллеги за пределами вашей команды).
2. Вырабатывайте единый язык в своей команде. Если возникают спорные моменты касательно определений, то останавливайте дискуссию и формально закрепляйте используемые термины, иначе вы будете бесконечно друг с другом спорить, но каждый будет прав в рамках своего контекста.
3. Если вы блокируетесь ожиданием решения, то явно про это говорите. Если чувствуете, что что-то идет не так, то уточните не нужна ли помощь или комментарии.
Хорошим вариантом может быть - встреча на 30 минут для погружения в контекст и закрытия всех возникающих вопросов.
Парадоксально, но сейчас недостаточно говорить на одном языке, чтобы понимать друг друга, нужно еще, чтобы язык был единым.
@time2code
👍10
💔 Мои боли в программировании
Есть всего несколько вещей, которые очень не люблю. И на это есть причины.
1️⃣ Системное администрирование (включая DevOps-практики, но между ними нельзя ставить знак равенства)
Появилось ощущение, что первой профессией программирование не стало именно по этой причине (я везде видел сис. админство).
Настройка любых конфигов, пробрасывание портов, организация прав доступа и все в этом духе - сильно отталкивали меня, пожалуй, всю сознательную жизнь.
Сейчас (особенно в крупных компаниях), описанным выше все чаще занимаются профильные инженеры. Но базовые знания в этой области должны быть у каждого.
Крайне полезно: поправить конфиги в микросервисе, развернуть пет-проект на VPS-сервере через Docker, самостоятельно настроить CI/CD.
Fun fact: несмотря на мою нелюбовь - заставляю в себе культивировать подобные скиллы (особенно DevOps). В прошлом году даже задумывался про то, чтобы уйти в эту специфику из продуктовой разработки, но пока решил этот вопрос отложить, так как экспертиза, чтобы этим заниматься все время, нужна объемная.
2️⃣ Миграции для баз данных
Миграцией я буду называть процесс, при котором создается файл миграции в формате "20250422-add-table.sql" и впоследствии исполняется (накатывается) автоматизированным инструментом для миграций (мигратором).
Когда только начинал свой путь, одно слово "миграции" - пугало. И не просто так.
⚠️ Важно понимать, что работа с миграциями сопряжена с серьезной ответственностью, в особенности, если работаете с большими данными.
Вам нужно помнить про кучу вещей:
- не выполняете ли вы какой-то длительный запрос, который заблокирует вашу таблицу, пока не будет исполнен (здесь применимы советы: обработка данных небольшими чанками, запуск миграции в самый непопулярный период и т.д.);
- правильно ли вообще спроектирована БД: корректный ли выбранный индекс, есть ли нужные ограничения на таблицы, хватит или инта или лучше перестраховаться и взять бигинт;
- и другие вопросы, непосредственно относящиеся к проектированию баз данных, а также доступности данных на период миграции.
На прошлой неделе я еще столкнулся с тем, что любой пуш кода на удаленный репозитории приводил к автоматическому запуску интеграционных тестов, чему предшествовало исполнение миграции в тестовом окружении.
И, если вы немного ошиблись с миграцией, то, чтобы все исправить, необходимо делать новую миграцию, откатывающую это поведение...
С учетом того, что человеку свойственно ошибаться, то это очень неприятное поведение.
Вероятно, поэтому одной из основных рекомендаций при работе с миграциями в нагруженной среде:
Новая миграция - новый файл и отдельный ПР.
Другим неплохим советом может быть - составить чек-лист, чтобы перепроверять себя: не упустили ли что-то важное.
* * *
Интересно, но между 1️⃣ и 2️⃣ есть сходство. Они не с проста в одном посте.
Несмотря на мою усидчивость, я могу быть очень нетерпеливым или даже импульсивным в некоторых ситуациях, а если к этому еще и добавляется невнимательность, то получается удивительная смесь.
Что миграции для БД, что любое конфигурирование - не любят неточностей. Они их не прощают.
Любое необдуманное действие в лучшем случае ни к чему не приведет, в худшем - может сломать вся систему, восстановление работоспособности которой займет в разы больше времени, чем вы затратили на поломку.
Поэтому, если работаете с подобными вещами, то лучше притормозите. Перепроверьте несколько раз, перестрахуйтесь. И только, когда уверены в успехе, заливайте на прод.
Интересно, какие у вас есть нелюбимые вещи или боли в разработке?
Чинить какой-то мутный баг или разбираться в чужом легаси - не в счет :)
@time2code
Есть всего несколько вещей, которые очень не люблю. И на это есть причины.
1️⃣ Системное администрирование (включая DevOps-практики, но между ними нельзя ставить знак равенства)
Появилось ощущение, что первой профессией программирование не стало именно по этой причине (я везде видел сис. админство).
Настройка любых конфигов, пробрасывание портов, организация прав доступа и все в этом духе - сильно отталкивали меня, пожалуй, всю сознательную жизнь.
Сейчас (особенно в крупных компаниях), описанным выше все чаще занимаются профильные инженеры. Но базовые знания в этой области должны быть у каждого.
Крайне полезно: поправить конфиги в микросервисе, развернуть пет-проект на VPS-сервере через Docker, самостоятельно настроить CI/CD.
Fun fact: несмотря на мою нелюбовь - заставляю в себе культивировать подобные скиллы (особенно DevOps). В прошлом году даже задумывался про то, чтобы уйти в эту специфику из продуктовой разработки, но пока решил этот вопрос отложить, так как экспертиза, чтобы этим заниматься все время, нужна объемная.
2️⃣ Миграции для баз данных
Миграцией я буду называть процесс, при котором создается файл миграции в формате "20250422-add-table.sql" и впоследствии исполняется (накатывается) автоматизированным инструментом для миграций (мигратором).
Когда только начинал свой путь, одно слово "миграции" - пугало. И не просто так.
⚠️ Важно понимать, что работа с миграциями сопряжена с серьезной ответственностью, в особенности, если работаете с большими данными.
Вам нужно помнить про кучу вещей:
- не выполняете ли вы какой-то длительный запрос, который заблокирует вашу таблицу, пока не будет исполнен (здесь применимы советы: обработка данных небольшими чанками, запуск миграции в самый непопулярный период и т.д.);
- правильно ли вообще спроектирована БД: корректный ли выбранный индекс, есть ли нужные ограничения на таблицы, хватит или инта или лучше перестраховаться и взять бигинт;
- и другие вопросы, непосредственно относящиеся к проектированию баз данных, а также доступности данных на период миграции.
На прошлой неделе я еще столкнулся с тем, что любой пуш кода на удаленный репозитории приводил к автоматическому запуску интеграционных тестов, чему предшествовало исполнение миграции в тестовом окружении.
И, если вы немного ошиблись с миграцией, то, чтобы все исправить, необходимо делать новую миграцию, откатывающую это поведение...
С учетом того, что человеку свойственно ошибаться, то это очень неприятное поведение.
Вероятно, поэтому одной из основных рекомендаций при работе с миграциями в нагруженной среде:
Новая миграция - новый файл и отдельный ПР.
Другим неплохим советом может быть - составить чек-лист, чтобы перепроверять себя: не упустили ли что-то важное.
* * *
Интересно, но между 1️⃣ и 2️⃣ есть сходство. Они не с проста в одном посте.
Несмотря на мою усидчивость, я могу быть очень нетерпеливым или даже импульсивным в некоторых ситуациях, а если к этому еще и добавляется невнимательность, то получается удивительная смесь.
Что миграции для БД, что любое конфигурирование - не любят неточностей. Они их не прощают.
Любое необдуманное действие в лучшем случае ни к чему не приведет, в худшем - может сломать вся систему, восстановление работоспособности которой займет в разы больше времени, чем вы затратили на поломку.
Поэтому, если работаете с подобными вещами, то лучше притормозите. Перепроверьте несколько раз, перестрахуйтесь. И только, когда уверены в успехе, заливайте на прод.
Интересно, какие у вас есть нелюбимые вещи или боли в разработке?
Чинить какой-то мутный баг или разбираться в чужом легаси - не в счет :)
@time2code
👍8
<disclaimer>
В конце марта начал делиться разбором популярных IT-книг.
Мне показалось, что это может быть ценно широкой аудитории, так как по своему опыту знаю насколько сложно подходить к технической литературе, а тем более читать ее вдумчиво и отделять важное от второстепенного.
Основная проблема - это требует больших инвестиций времени.
А делать саммари с ключевыми идеями, оборачивать в удобный формат без потери смысла, подкреплять прочитанное практическим опытом - требует в разы больше времени.
Поэтому, чтобы добавить ценности к таким саммари, я решил их выкладывать отдельно от своего блога.
С 1 мая планирую все прикрыть пейволлом, чтобы была возможность оценить, насколько такой контент полезен и добавить себе дополнительную мотивацию, так как заниматься подобным разбором в стол - контрпродуктивно.
</disclaimer>
Сегодня выложил заключительную часть Главы 1 книги "Микросервисы" (Крис Ричардсон).
Каждая из частей читается не более, чем за 5-10 минут в зависимости от нужного уровня рефлексии.
💡 После прочтения Главы 1 мы загрузим в себя следующие идеи:
1. Архитектура приложения может определяться по тому, как развертывается система: для монолита это единая развертываемая сущность, а для микросервисов - независимые развертываемые сервисы (каждый со свой базой).
2. Монолитный стиль рекомендуется применять для простых приложений в начале их развития.
3. Микросервисный стиль ускоряет темп разработки, позволяя небольшим и автономным командам работать параллельно.
4. МС архитектура сопряжена с повышенной сложностью поддержки (привлечение DevOps и пр.), поэтому перед ее внедрением тщательно проанализируйте свою ситуацию.
5. Язык шаблонов (в т.ч. МС архитектуры) - это набор методик, который помогает эффективно проектировать приложение и отвечать на вопросы в рамках своего контекста.
6. Не забывайте про человеческий фактор, учитывайте настрой разработчиков особенно при переходе на новую технологию.
А также узнаем, что такое: монолитный ад, распределенный монолит, куб масштабирования, большой комок грязи и Suck/Rock Dichotomy.
#it #литература #разбор #микросервисы
@time2code
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10
Хороши ли ваши инструменты?
Когда перешел на VS Code (как переходил здесь), то случилось так, что я невольно на нем замкнулся.
У меня было явное отторжение любых IDE, а так как кроме написания кода, нужно работать с БД, тестировать API, то я невольно ставил плагины, постепенно превращая свой редактор текста в IDE.
И вот дошел до ситуации, когда у меня начались проблемы с удобством:
- перестал работать CTRL+C, так как другой плагин что-то сюда забиндил, хоть явно VS Code это не показывал
- для работы с Redis, вынужден был писать скрипты на Lua, чтобы решать свои задачи
- и мелкий другой дискомфорт, как, например, работа с PostgreSQL
В общем, решил, что так жить нельзя и SRP никто не отменял.
Как в жизни, лучше использовать специализированный инструмент для каждой из задач, так и в работе не нужно пытаться решить абсолютно все одним убер-инструментом.
Поэтому решил серьезно навести здесь порядок и начинаю с того, что отправляюсь на поиски удобной тулзы для управления БД.
Сейчас из рассматриваемых вариантов: DataGrip, DBeaver. Если используете их или что-то другое в своей работе, то поделитесь, пожалуйста, опытом.
ТГ не любит «лонгридов», поэтому полную статью опубликовал в блоге, там же мой сетап для разработки и lua-скрипт для Redis, удаляющий ключи по паттерну:
➡️ Читать статью в блоге
@time2code
Когда перешел на VS Code (как переходил здесь), то случилось так, что я невольно на нем замкнулся.
У меня было явное отторжение любых IDE, а так как кроме написания кода, нужно работать с БД, тестировать API, то я невольно ставил плагины, постепенно превращая свой редактор текста в IDE.
И вот дошел до ситуации, когда у меня начались проблемы с удобством:
- перестал работать CTRL+C, так как другой плагин что-то сюда забиндил, хоть явно VS Code это не показывал
- для работы с Redis, вынужден был писать скрипты на Lua, чтобы решать свои задачи
- и мелкий другой дискомфорт, как, например, работа с PostgreSQL
В общем, решил, что так жить нельзя и SRP никто не отменял.
Как в жизни, лучше использовать специализированный инструмент для каждой из задач, так и в работе не нужно пытаться решить абсолютно все одним убер-инструментом.
Поэтому решил серьезно навести здесь порядок и начинаю с того, что отправляюсь на поиски удобной тулзы для управления БД.
Сейчас из рассматриваемых вариантов: DataGrip, DBeaver. Если используете их или что-то другое в своей работе, то поделитесь, пожалуйста, опытом.
ТГ не любит «лонгридов», поэтому полную статью опубликовал в блоге, там же мой сетап для разработки и lua-скрипт для Redis, удаляющий ключи по паттерну:
@time2code
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Апрель 2025:
ключевые события
✔️ Запустил проект, где делюсь ключевыми идеями из популярных IT-книг. Начал с "Микросервисов". Добавил удобную навигационную страницу по главам из личного блога.
✔️ Поразмышлял о качественном код-ревью в соответствии с лучшими практиками.
✔️ Научился обращать внимание на "страшные" слова в спецификациях ("все", "всего" и пр.), которым мы часто не придаем значение.
✔️ Познакомился с хаос-тестированием (chaos engineering) и совместно с коллегами из инфраструктуры запланировал такой тест своего сервиса. Результатами и впечатлениями поделюсь в отдельном посте ближе к лету.
✔️ Много общался с горизонтальными командами: организовал и фасилитировал встречи по аналитике, новым интеграциям и плавного отказа от легаси кода.
посты
⭐️ Сила единого языка. DDD в действии -> читать
🔖 Мои боли в программировании -> читать
🔖 Загружаем ключевые идеи -> читать
🔖 Хороши ли ваши инструменты? -> читать
#дайджест
@time2code
ключевые события
✔️ Запустил проект, где делюсь ключевыми идеями из популярных IT-книг. Начал с "Микросервисов". Добавил удобную навигационную страницу по главам из личного блога.
✔️ Поразмышлял о качественном код-ревью в соответствии с лучшими практиками.
✔️ Научился обращать внимание на "страшные" слова в спецификациях ("все", "всего" и пр.), которым мы часто не придаем значение.
✔️ Познакомился с хаос-тестированием (chaos engineering) и совместно с коллегами из инфраструктуры запланировал такой тест своего сервиса. Результатами и впечатлениями поделюсь в отдельном посте ближе к лету.
✔️ Много общался с горизонтальными командами: организовал и фасилитировал встречи по аналитике, новым интеграциям и плавного отказа от легаси кода.
посты
⭐️ Сила единого языка. DDD в действии -> читать
🔖 Мои боли в программировании -> читать
🔖 Загружаем ключевые идеи -> читать
🔖 Хороши ли ваши инструменты? -> читать
#дайджест
@time2code
👍4❤1
В посте про разрыв контекста и эффективность я уже упоминал технику "хлебных крошек", которые позволяют вам быстрее вернуться в прерванное состояние с минимальными усилиями.
И также не раз говорил про важность цифрового следа при подготовке к perf-review (кстати, уже скоро будет актуально, у кого, как у меня, он проходит в июне).
Все это можно обобщить, как фиксируйте договоренности.
Почему это важно?
1️⃣ Зафиксированный формально итог встречи помогает выровнять выводы всех ее участников.
2️⃣ Дополнительный уровень верификации. Если вы что-то упустили из виду, то велика вероятность, что вас поправят.
3️⃣ То, с чем столкнулся после 4-х дневного перерыва в работе: из-за множества стримов и контекстов очень легко про что-то забыть, упустить из виду, но на помощь могут прийти явно зафиксированные договоренности или их отсутствие.
Так, пытаясь найти ответ на вопрос, поднимаемый 2 недели назад, и не обнаружив зафиксированных договоренностей кроме как "давайте обсудим на встрече", был сделан вывод, что на встрече ничего не обсудили и решения до сих пор нет.
Как итог - инициализация нового обсуждения по этой теме.
4️⃣ Еще раз подчеркну, что это отлично помогает при подготовке фактуры во время периода перформанс-ревью или аттестации.
5️⃣ Возврат в контекст, как и с хлебными крошками, любая фиксация договоренностей отлично позволяет погрузиться в тему, которой вы непосредственно не занимались какое-то время.
Это удивительно, но софты в жизни инженера зачастую играют большую роль, чем харды. И чем опытнее инженер, тем более явным становится этот разрыв.
Поэтому, активно развивая хард скиллы, не забывайте и про софты.
Интересное наблюдение: развитие некоторых софтов требует меньше времени и трудозатрат от вас, чем от погружения в технически сложную тему, но может принести в разы большую пользу.
@time2code
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤1
Продолжаем изучать ключевые идеи "Микросервисов".
Ранее:
-> загрузить v1
💡 После прочтения Главы 2 мы загрузим в себя следующие идеи:
1. Архитектура определяет качественные характеристики приложения, влияющие на темпы разработки.
2. Микросервисная архитектура (МСА) - это архитектурный стиль, который делает приложение хорошо поддерживаемым, тестируемым, развертываемым.
3. Сервисы в МСА организованы вокруг бизнес-возможностей или поддоменов, а не технических характеристик (это основные виды декомпозиции).
4. Избавиться от божественных классов, которые препятствуют декомпозиции можно применяя DDD и определяя отдельную доменную модель для каждого сервиса.
А также узнаем, что такое: модель представления архитектуры 4+1, многоуровневый архитектурный стиль, шестигранная архитектура, как описывать архитектуру с помощью 3 шагов и многое другое.
#it #литература #разбор #микросервисы
@time2code
Please open Telegram to view this post
VIEW IN TELEGRAM
На прошлой неделе под конец спринта состоялось хаос-тестирование одного из разрабатываемых мной сервисов.
Но перед тем, как рассказать о результате, несколько интересных фактов.
Из истории
Хаос-инженерия (хаос-тестирование в частности) предполагает экспериментирование над системой в промышленном окружении, чтобы оценить ее устойчивость к серьезным аномалиям, а также возможности к самовосстановлению.
Согласно странице на Вики пионером в этой области был инженер компании Apple, который в 1983 году для MacPaint на Apple Macintosh написал небольшую программку под названием "Monkey".
Программа запускалась вместе с приложением и произвольно генерировало множество событий, имитируя пользовательское взаимодействие с UI.
В связи со спецификой железа того времени фактически такой тест заменял современные автотесты, создавая внештатный сценарий во время использования программы и помогая отлавливать ошибки.
Впоследствии практика по созданию чрезвычайной ситуации в сервисе или ПО получила распространение и стала использоваться IT-гигантами: Amazon с их "игровыми днями", Google с DiRT и другие - очень полюбили хаос-тестирование.
Chaos Monkey
Но самымой заметной компанией, на которую часто ссылаются статьи про хаос-инженерию, стал Netflix с open-source разработкой Chaos Monkey.
Приложение написано на Go и при запуске случайным образом завершает работу экземпляра виртуального машины или контейнера в продакш-среде 🙈
Сбилдив приложение, предлагается запускать его по крону, настроив регулярное расписание.
Практика подобных принудительных сбоев может помочь значительно улучшить устойчивость ваших приложений.
Мой опыт
Перед тем, как запланировать работы по хаос-тестированию у меня был бриф с профильной командой.
Мы обсудили:
- зона ответственности сервиса
- возможные риски и негативный эффект на пользователях
- наблюдаемые метрики
- составили план по созданию внештатной ситуации и механизмы отката
Основная цель - сделать существующие реплики хранилищ недоступными (стригеррить перевыборы для PG, а на Redis отключить RW-реплику) и посмотреть на поведение системы, а затем на то, как она восстанавливается.
1️⃣ Первым этапом отключили PG.
Серьезных деградаций не было за исключением того, что стала забиваться внутренняя очередь сообщениями, которые ожидали сохранение в БД.
Если бы не было предусмотренно внутренней очереди на такой случай, то мы бы легко потеряли новые данные, агрегировавшиеся во время отключения.
2️⃣ Отключив RW-реплику на Redis, получили гораздо больше проблем, связанных с ощутимым ростом времени ответа rpc-ручек.
Начали приходить настроенные алерты (это тоже важный момент, который проверяется в тесте).
Было ясно, что без Redis сервису жилось очень плохо.
Каждый из тестов продлился не более 5-10 минут, после которых сервис полностью восстановил работоспособность, когда убрали аномалию.
Так как у нас был предусмотрен механизм Gracefull degradation, то временная неработоспособность сервиса не повлияла на пользовательский опыт.
Основным выводом из эксперимента было: сервис удовлетворяет базовым условиям восстановления после чрезвычайной ситуации. Никакие экстренные AI предпринимать не нужно.
Мне, как оунеру сервиса, было очень полезно вживую по метрикам наблюдать за тем, что происходит с сервисом в момент внештатных ситуаций.
Составил список того, что хочу дополнительно проресечить, чтобы понять как можно повысить стабильность системы.
.
📚 По данной теме рекомендую заглянуть в документацию Amazon и ознакомиться с основными принципами хаос-инженерии.
.
Что думаете о такой практике? Стоит внедрять хаос-инженерию или слишком опасно?
@time2code
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤1
Продвинутая работа с БД. Нужна ли она вам?
В начале мая задался вопросом: как лучше работать с БД?
Поэтому решил собрать мнения разных инженеров и попробовать на своем опыте популярные подходы.
Опыт
Изучая системы по управлению базами данных, за этот месяц попробовал две: Dbeaver и DataGrip.
Dbeaver выглядит интересно, но оказалось, что в Community Edition версии нет Redis, поэтому с задачей по управлению NoSQL и SQL из бесплатной коробки не справился.
Цена за платную версию начинается от 110$ и доходит до 500$.
А если нужно платить, то можно уже и в сторону решений от JetBrains посмотреть с его DataGrip за 229$.
Лайфхак: в большинстве IDE от JetBrains есть плагин, позволяющий получить все функции по работе с БД, которые предоставляет DataGrip.
Так, если вы пишите на Go, то покупаете Goland за 249$ и получаете все в одном инструменте.
Цена указана за 1 год использования.
Опыт других
Обсудив вопрос с коллегами, все единогласно проголосовали за Goland со встроенным DataGrip, отмечают элементарное удобство.
Из альтернатив еще советовали TablePlus, но я его не стал тестировать, так как все выводы для себя уже сделал.
Также собрал мнения инженеров, кто меня читает, - результат получился разнообразным.
Есть те, кому удобнее работать с простым psql, а также те, кто кроме удобной IDE ничего не принимает.
Выводы
1. Продвинутые инструменты для работы с БД, а именно отдельная IDE нужна тем, кто ежедневно с ними работает (проектирует базу или поддерживает текущую).
2. В большинстве случаев у продуктового разработчика потребность по взаимодействию с БД ограничивается несколькими запросами, которые можно выполнить даже в терминале psql, и это может быть эффективнее, чем запускать отдельное приложение.
3. В настоящий момент понял для себя, что отдельная IDE создает ненужный оверхэд и тормозит работу конкретно мою работу.
Что в итоге?
Продолжаю использовать CLI для работы с БД и простенький плагин на VS Code (для PG и для официальный Redis for VS Code), но для серьезной работы держу наготове продвинутый тулинг.
@time2code
В начале мая задался вопросом: как лучше работать с БД?
Поэтому решил собрать мнения разных инженеров и попробовать на своем опыте популярные подходы.
Опыт
Изучая системы по управлению базами данных, за этот месяц попробовал две: Dbeaver и DataGrip.
Dbeaver выглядит интересно, но оказалось, что в Community Edition версии нет Redis, поэтому с задачей по управлению NoSQL и SQL из бесплатной коробки не справился.
Цена за платную версию начинается от 110$ и доходит до 500$.
А если нужно платить, то можно уже и в сторону решений от JetBrains посмотреть с его DataGrip за 229$.
Лайфхак: в большинстве IDE от JetBrains есть плагин, позволяющий получить все функции по работе с БД, которые предоставляет DataGrip.
Так, если вы пишите на Go, то покупаете Goland за 249$ и получаете все в одном инструменте.
Цена указана за 1 год использования.
Опыт других
Обсудив вопрос с коллегами, все единогласно проголосовали за Goland со встроенным DataGrip, отмечают элементарное удобство.
Из альтернатив еще советовали TablePlus, но я его не стал тестировать, так как все выводы для себя уже сделал.
Также собрал мнения инженеров, кто меня читает, - результат получился разнообразным.
Есть те, кому удобнее работать с простым psql, а также те, кто кроме удобной IDE ничего не принимает.
Выводы
1. Продвинутые инструменты для работы с БД, а именно отдельная IDE нужна тем, кто ежедневно с ними работает (проектирует базу или поддерживает текущую).
2. В большинстве случаев у продуктового разработчика потребность по взаимодействию с БД ограничивается несколькими запросами, которые можно выполнить даже в терминале psql, и это может быть эффективнее, чем запускать отдельное приложение.
3. В настоящий момент понял для себя, что отдельная IDE создает ненужный оверхэд и тормозит работу конкретно мою работу.
Что в итоге?
Продолжаю использовать CLI для работы с БД и простенький плагин на VS Code (для PG и для официальный Redis for VS Code), но для серьезной работы держу наготове продвинутый тулинг.
@time2code
👍3❤1
🆎 Запуск крупного AB
Вчера состоялся долгожданный запуск AB-эксперимента, к которому я готовился последние несколько месяцев, из-за чего даже мой work-life balance пошатнулся 😅
Вероятно, это пока самый ответственный эксперимент для меня, который пришлось лидировать.
Разрабатываемая функциональность вобрала в себя:
- асинхронную архитектуру;
- разработку новой нагруженной ручки (включая переезд со старой);
- нагрузочное тестирование сервиса, чтобы снять риски возможных проблем с БД;
- интеграцию с новым механизмом платформенной команды (включая всю боль коммуникации и мисскоммуникации по этому вопросу);
- тесную работу с аналитиком, так как для запуска пришлось вручную собирать список пользователей, которые не должны были попасть в эксперимент;
- нюансы при будущей раскатке;
- активную работу с дискавери-командой (редактором, дизайнером, продактом, аналитиком), включая построение CJM для продумывания всех нюансов;
- взаимодействие со службой поддержки и ее подготовка перед запуском;
- особенности работы горизонтальных сервисов (проблема с отправкой хэдеров на клиентах при повторных запросах), в связи с чем пришлось буквально по-горячему на этапе интеграционного тестирования придумывать новое работающее решение, которое не ухудшало бы пользовательский опыт;
- запуск ручных скриптов для пересчета продовой базы данных из-за особенностей архитектуры сервиса;
- и многое другое, про что сейчас уже сложно вспомнить.
Конечно, запуск не означает отсутствие проблем после, которые могут начать проявляться с каждым днем все активнее и активнее, когда больше пользователей будет сталкиваться с новым поведением.
🚀 Но как и при старте ракеты, так и при запуске эксперимента спокойный и штатный старт во многом является залогом успеха.
Для возможности убедиться, что все спокойно, следует заранее озаботиться о необходимых метриках и логировании, чтобы при переводе трафика на новую функциональность, была возможность наблюдать за состоянием системы и оперативно реагировать.
В день запуска поймал себя на мысли, что наблюдая плавно увеличивающуюся нагрузку на новую ручку, также плавно уменьшалось и мое напряжение, которое сопровождало все время до непосредственного старта.
Приятное ощущение. Вероятно, ради него и работаю.
@time2code
Вчера состоялся долгожданный запуск AB-эксперимента, к которому я готовился последние несколько месяцев, из-за чего даже мой work-life balance пошатнулся 😅
Вероятно, это пока самый ответственный эксперимент для меня, который пришлось лидировать.
Разрабатываемая функциональность вобрала в себя:
- асинхронную архитектуру;
- разработку новой нагруженной ручки (включая переезд со старой);
- нагрузочное тестирование сервиса, чтобы снять риски возможных проблем с БД;
- интеграцию с новым механизмом платформенной команды (включая всю боль коммуникации и мисскоммуникации по этому вопросу);
- тесную работу с аналитиком, так как для запуска пришлось вручную собирать список пользователей, которые не должны были попасть в эксперимент;
- нюансы при будущей раскатке;
- активную работу с дискавери-командой (редактором, дизайнером, продактом, аналитиком), включая построение CJM для продумывания всех нюансов;
- взаимодействие со службой поддержки и ее подготовка перед запуском;
- особенности работы горизонтальных сервисов (проблема с отправкой хэдеров на клиентах при повторных запросах), в связи с чем пришлось буквально по-горячему на этапе интеграционного тестирования придумывать новое работающее решение, которое не ухудшало бы пользовательский опыт;
- запуск ручных скриптов для пересчета продовой базы данных из-за особенностей архитектуры сервиса;
- и многое другое, про что сейчас уже сложно вспомнить.
Конечно, запуск не означает отсутствие проблем после, которые могут начать проявляться с каждым днем все активнее и активнее, когда больше пользователей будет сталкиваться с новым поведением.
🚀 Но как и при старте ракеты, так и при запуске эксперимента спокойный и штатный старт во многом является залогом успеха.
Для возможности убедиться, что все спокойно, следует заранее озаботиться о необходимых метриках и логировании, чтобы при переводе трафика на новую функциональность, была возможность наблюдать за состоянием системы и оперативно реагировать.
В день запуска поймал себя на мысли, что наблюдая плавно увеличивающуюся нагрузку на новую ручку, также плавно уменьшалось и мое напряжение, которое сопровождало все время до непосредственного старта.
Приятное ощущение. Вероятно, ради него и работаю.
@time2code
👍11💅2❤1
Май 2025:
ключевые события
✔️ Месяц, когда написал очень много кода (тысячи строк), чтобы запуск эксперимента стал возможным.
✔️ Организовал и провел 2 совершенно разных типа тестирования: нагрузочное тестирование, чтобы снять риск отказа БД при высокой нагрузке, и chaos-тестирование.
✔️ Официально (на уровне компании) стал ментором. Занимаюсь профессиональным развитием бэкенд-инженера с запросом "переход на следующий грейд": составляем план развития с упором на матрицу компетенций, принятую в компании, укрепляем слабые места, учимся презентовать свои достижения.
✔️ Задокументировал часть важной функциональности (которую разработал в феврале) горизонтального сервиса. Это важно делать, так как контекст со временем может теряться, а документация для инструментов, которыми пользуются десятки команды крайне важна.
✔️ Поразмышлял о том как задавать правильные(=широкие) вопросы при отладке, а также о том какая альтернатива существует хранению логических значений в БД.
✔️ Посмотрел как Дефункционализация и CPS (Continuation Passing Style) могут работать вместе, потренировавшись на примерах.
посты
⭐️ Еще одна важная вещь -> читать
🔖 Загружаем ключевые идеи V2 -> читать
🔖 Chaos Engineering -> читать
🔖 Продвинутая работа с БД. Нужна ли она вам? -> читать
#дайджест
@time2code
ключевые события
✔️ Месяц, когда написал очень много кода (тысячи строк), чтобы запуск эксперимента стал возможным.
✔️ Организовал и провел 2 совершенно разных типа тестирования: нагрузочное тестирование, чтобы снять риск отказа БД при высокой нагрузке, и chaos-тестирование.
✔️ Официально (на уровне компании) стал ментором. Занимаюсь профессиональным развитием бэкенд-инженера с запросом "переход на следующий грейд": составляем план развития с упором на матрицу компетенций, принятую в компании, укрепляем слабые места, учимся презентовать свои достижения.
✔️ Задокументировал часть важной функциональности (которую разработал в феврале) горизонтального сервиса. Это важно делать, так как контекст со временем может теряться, а документация для инструментов, которыми пользуются десятки команды крайне важна.
✔️ Поразмышлял о том как задавать правильные(=широкие) вопросы при отладке, а также о том какая альтернатива существует хранению логических значений в БД.
✔️ Посмотрел как Дефункционализация и CPS (Continuation Passing Style) могут работать вместе, потренировавшись на примерах.
посты
⭐️ Еще одна важная вещь -> читать
🔖 Загружаем ключевые идеи V2 -> читать
🔖 Chaos Engineering -> читать
🔖 Продвинутая работа с БД. Нужна ли она вам? -> читать
#дайджест
@time2code
❤1
Жизнеспособная архитектура
Одно из преимуществ микросервисной архитектуры - делать сервисы автономными: независимое развертывание, свой технологический стек (идеальный для конкретной задачи), отдельная команда, которая поддерживает сервис и объединена одной целью.
Все бы ничего, но именно автономность разработки и поддержки микросервисов вносит сумятицу.
Кто-то придерживается чистой архитектуры, кто-то лучшим практикам, а кто-то реализует Big Ball of Mud.
Конечно, можно было бы попробовать все стандартизировать, но это требует серьезных ресурсов да и в конечном счете делает систему менее гибкой.
Изучая десятки (если не сотни) микросервисов, заметил у них интересную особенность - они все спроектированы по-разному.
И это ни хорошо и ни плохо.
Зачастую это обусловлено внутренними договоренностями команды, которая занимается поддержкой микросервиса.
И это нормально, если система соответствует SLA, а команда работает эффективно.
Но что, если внутренних договоренностей нет, команда только формируется, а тебе нужно спроектировать новую систему или новый модуль?
Хорошо следовать лучшим практикам, но, к сожалению, не всегда это возможно.
Minimal Viable Architecture (MVA)
На своем опыте я понял, что в первую очередь следует проектировать архитектуру, которая способна быстро меняться и быть гибкой.
Новые требования влетают каждый день и крайне важно уметь под них подстраиваться, чтобы не снижать TTM.
Никому не нужна правильная и чистая архитектура, если при этом вы поставляете новые фичи, срывая сроки и руша планы и надежды менеджеров на быстрый захват рынка.
Необходимость и достаточность - вот основные принципы при проектировании архитектуры в быстроменяющейся среде.
Поэтому важно придерживаться тому, чтобы архитектура была достаточно гибкая для возможности нативно эволюционировать в результате новых требований или проверки гипотез.
Фактически на своем опыте я открыл идеи MVA, которые существуют десятки лет 😅
Интересно будет углубиться и дополнительно рассказать про это. Базово с подходом можно ознакомиться здесь.
Напишите, если открыли MVA только недавно или уже активно применяете в работе (я раньше нигде не встречал даже упоминания).
@time2code
Одно из преимуществ микросервисной архитектуры - делать сервисы автономными: независимое развертывание, свой технологический стек (идеальный для конкретной задачи), отдельная команда, которая поддерживает сервис и объединена одной целью.
Все бы ничего, но именно автономность разработки и поддержки микросервисов вносит сумятицу.
Кто-то придерживается чистой архитектуры, кто-то лучшим практикам, а кто-то реализует Big Ball of Mud.
Конечно, можно было бы попробовать все стандартизировать, но это требует серьезных ресурсов да и в конечном счете делает систему менее гибкой.
Изучая десятки (если не сотни) микросервисов, заметил у них интересную особенность - они все спроектированы по-разному.
И это ни хорошо и ни плохо.
Зачастую это обусловлено внутренними договоренностями команды, которая занимается поддержкой микросервиса.
И это нормально, если система соответствует SLA, а команда работает эффективно.
Но что, если внутренних договоренностей нет, команда только формируется, а тебе нужно спроектировать новую систему или новый модуль?
Хорошо следовать лучшим практикам, но, к сожалению, не всегда это возможно.
Minimal Viable Architecture (MVA)
На своем опыте я понял, что в первую очередь следует проектировать архитектуру, которая способна быстро меняться и быть гибкой.
Новые требования влетают каждый день и крайне важно уметь под них подстраиваться, чтобы не снижать TTM.
Никому не нужна правильная и чистая архитектура, если при этом вы поставляете новые фичи, срывая сроки и руша планы и надежды менеджеров на быстрый захват рынка.
Необходимость и достаточность - вот основные принципы при проектировании архитектуры в быстроменяющейся среде.
Поэтому важно придерживаться тому, чтобы архитектура была достаточно гибкая для возможности нативно эволюционировать в результате новых требований или проверки гипотез.
Фактически на своем опыте я открыл идеи MVA, которые существуют десятки лет 😅
Интересно будет углубиться и дополнительно рассказать про это. Базово с подходом можно ознакомиться здесь.
Напишите, если открыли MVA только недавно или уже активно применяете в работе (я раньше нигде не встречал даже упоминания).
@time2code
👍5
Продолжаем изучать ключевые идеи "Микросервисов".
Ранее:
-> загрузить v1
-> загрузить v2
💡 После прочтения Главы 3 мы загрузим в себя следующие идеи:
1. МСА является распределенной, поэтому межпроцессное взаимодействие является ключевым.
2. К развитию API нужно подходить тщательно и осторожно. Следует вносить обратно совместимые изменения, чтобы не влиять на работу клиентов.
3. Существует множество IPC-технологий, каждую из которых следует выбирать под свои требования. Ключевым решением на этапе проектирования является выбор между синхронным и асинхронным взаимодействием.
4. Для предотвращения каскадных сбоев клиент, реализующий синхронный протокол, должен уметь справляться с частичными отказами (таймаут запросов, использовать "предохранитель").
5. Архитектура с синхронными протоколами должна использовать механизмы обнаружения (лучше всего остановиться на платформенных).
6. Модель сообщений и каналов - хороший выбор при проектировании соответствующей архитектуры.
7. При обмене сообщениями основной трудностью является их публикация и обновление базы данных, поэтому следует использовать шаблоны: "Публикация событий", "Опрашивающй издатель" или "Отслеживание транзакционного журнала".
#it #литература #разбор #микросервисы
@time2code
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5
Пока я был занят запуском очередного АБ, а затем и написанием селф-ревью (сейчас в компании активно идет процесс performance-review), канал отметил пятилетие с момента создания.
5 июня 2020 года я решил завести бортовой журнал - дневник, который станет отражением моих мыслей, целей и достижений.
А 2 года назад канал пережил ребрендинг - он стал более персонализированным и чуть более серьезным, чем безликие заметки инженера.
Очевидно, что на тот момент я совершенно не знал как сложится моя карьера и получится ли хоть как-то преуспеть в новом.
Так или иначе каждый свой пост я писал для себя, чтобы вырабатывать дисциплину, мотивировать двигаться дальше, а затем и ретроспективно рефлексировать над пройденным.
Довольно долгое время единственным читателем был я, и это было очень комфортно.
Сейчас канал вырос более чем в 100 раз, и для меня это серьезный вызов и даже в некоторой степени давление, так как приходится каждый пост взвешивать и тщательно анализировать перед публикацией на предмет реальной пользы для аудитории.
В погоне за полезными постами я понял, что загнал себя в жесткие рамки. И писать новое стало все сложнее и сложнее.
Поэтому в ближайшей перспективе планирую эту ситуацию поправить, добавить большей легкости и по возможности учесть обратную связь от тех, кто меня читает.
Полагаю, что сейчас также идеальное время сообщить о том, что я очень благодарен и ценю каждого, кто подписан на канал!
Спасибо за то, что читаете, оставляете комментарии и реакции
В связи с юбилеем канала провожу небольшой пульс-опрос.
Пожалуйста, напишите в анонимной форме или в реплаях к посту: почему вы подписаны на канал или почему подписались когда-то, что находите интересным, что откликается, а что совершенно неинтересно читать.
Обязательно все проанализирую и постараюсь найти баланс между своим стилем и тем, что может быть потенциально интересно, но я почему-то не затрагиваю.
Please open Telegram to view this post
VIEW IN TELEGRAM
7❤6👍2😱2🍾2
Июнь 2025:
ключевые события
✔️ Этому каналу исполнилось 5 лет! 🎈
✔️ Написал 6-ой селф-ревью в компании. Пора уже организовать ультимативный гайд в продолжение поста.
✔️ Завершил курс по работе и поддержке Легаси систем.
✔️ Рассмотрел способ смысловых группировок на уровне функции и ситуации, когда наследование предпочтительнее композиции.
✔️ Важная для меня веха - пробежал первый трейл: 23.3 км, +900м - за 3 часа.
✔️ Сходил в недельный отпуск - понравилось.
посты
⭐️ Запуск крупного AB -> читать
🔖 Жизнеспособная архитектура -> читать
🔖 Загружаем ключевые идеи V3 -> читать
#дайджест
@time2code
ключевые события
✔️ Этому каналу исполнилось 5 лет! 🎈
✔️ Написал 6-ой селф-ревью в компании. Пора уже организовать ультимативный гайд в продолжение поста.
✔️ Завершил курс по работе и поддержке Легаси систем.
✔️ Рассмотрел способ смысловых группировок на уровне функции и ситуации, когда наследование предпочтительнее композиции.
✔️ Важная для меня веха - пробежал первый трейл: 23.3 км, +900м - за 3 часа.
✔️ Сходил в недельный отпуск - понравилось.
посты
⭐️ Запуск крупного AB -> читать
🔖 Жизнеспособная архитектура -> читать
🔖 Загружаем ключевые идеи V3 -> читать
#дайджест
@time2code
👏4👍2🔥1