<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
Атомарные изменения лучше
Уже рассуждал про то, как ПР может быть отражением инженерной культуры. Но как будто настало время еще раз про это поговорить.
Что случилось?
На днях опытный разработчик добавлял локализацию для вертикальной библиотеки.
Кратко: захардкоженные тексты оборачивались в константу (токен), который указывал путь на json определенной локали, по которому следует резолвить тексты.
Это была первая итерация к локализации. Констант, которые нужно было перевести таким образом, было очень много. По грубым прикидкам: 30+ файлов.
Я, как один из оунеров библиотеки, провел честный код ревью, потратил около часа, чтобы разобраться, что происходит, но каких-то проблем не заметил.
Единственное, что я подсветил: меняется способ организации констант в проекте и предложил его описать, чтобы у контрибьютеров не было проблем с новым подходом.
При этом, моя внутренняя интуиция сообщала, что при таком количестве изменений вероятность, что не все пройдет плавно, крайне велика, но непосредственную проблему я не видел, чтобы заблокировать ПР.
И все бы ничего, но на следующий день появляется непонятный баг в неожиданном месте...
При помощи 2 разработчиков и 2 QA, созданием кастомного деплоя удалось установить проблему: при рефакторинге констант, заодно зарефакторили и ключ конфигурации в одном из виджетов.
Заметить такое на ревью, когда у тебя десятки файлов - нереально. Если только уже с таким не сталкивался и знаешь место, которое нужно проверять.
А что тесты?
Тесты были, но и они были изменены соответствующим образом, чтобы код с багом проходил :)
Думаю, что при таком количестве изменяемые файлов, был использован скрипт, возможности IDE по автозамене или даже AI.
Мораль
Делать как можно более мелкие и локальные изменения в одном ПР-е. Это не всегда возможно, но к этому следует стремиться.
За / против:
+ ощутимо снижается когнитивная нагрузка у ревьюеров, которые смотрят ПР (что внимательнее человек посмотрит 50 измененных строк кода или 1000?);
+ легкий деплой - при небольших изменения вы можете значительно снизить скоуп наблюдаемых метрик при раскатке;
+ автономный откат - чем меньше изменяемых файлов, тем более точно можно откатывать свои изменения без аффекта на то, что работает штатно;
- может удлиняться код-ревью, а вместе с ним - деливери фичи, если этот процесс происходит медленно и требует внимания соседних команд;
- "экономия" времени; с одной стороны кажется, что удобно все изменения за один раз заделиверить, но с другой - при наличии проблем, времени можно потратить гораздо больше.
Рекомендую держать в голове вышеописанное при создании очередного ПР и всегда прислушиваться к себе.
@time2code
Уже рассуждал про то, как ПР может быть отражением инженерной культуры. Но как будто настало время еще раз про это поговорить.
Что случилось?
На днях опытный разработчик добавлял локализацию для вертикальной библиотеки.
Кратко: захардкоженные тексты оборачивались в константу (токен), который указывал путь на json определенной локали, по которому следует резолвить тексты.
Это была первая итерация к локализации. Констант, которые нужно было перевести таким образом, было очень много. По грубым прикидкам: 30+ файлов.
Я, как один из оунеров библиотеки, провел честный код ревью, потратил около часа, чтобы разобраться, что происходит, но каких-то проблем не заметил.
Единственное, что я подсветил: меняется способ организации констант в проекте и предложил его описать, чтобы у контрибьютеров не было проблем с новым подходом.
При этом, моя внутренняя интуиция сообщала, что при таком количестве изменений вероятность, что не все пройдет плавно, крайне велика, но непосредственную проблему я не видел, чтобы заблокировать ПР.
И все бы ничего, но на следующий день появляется непонятный баг в неожиданном месте...
При помощи 2 разработчиков и 2 QA, созданием кастомного деплоя удалось установить проблему: при рефакторинге констант, заодно зарефакторили и ключ конфигурации в одном из виджетов.
Заметить такое на ревью, когда у тебя десятки файлов - нереально. Если только уже с таким не сталкивался и знаешь место, которое нужно проверять.
А что тесты?
Тесты были, но и они были изменены соответствующим образом, чтобы код с багом проходил :)
Думаю, что при таком количестве изменяемые файлов, был использован скрипт, возможности IDE по автозамене или даже AI.
Мораль
Делать как можно более мелкие и локальные изменения в одном ПР-е. Это не всегда возможно, но к этому следует стремиться.
За / против:
+ ощутимо снижается когнитивная нагрузка у ревьюеров, которые смотрят ПР (что внимательнее человек посмотрит 50 измененных строк кода или 1000?);
+ легкий деплой - при небольших изменения вы можете значительно снизить скоуп наблюдаемых метрик при раскатке;
+ автономный откат - чем меньше изменяемых файлов, тем более точно можно откатывать свои изменения без аффекта на то, что работает штатно;
- может удлиняться код-ревью, а вместе с ним - деливери фичи, если этот процесс происходит медленно и требует внимания соседних команд;
- "экономия" времени; с одной стороны кажется, что удобно все изменения за один раз заделиверить, но с другой - при наличии проблем, времени можно потратить гораздо больше.
Рекомендую держать в голове вышеописанное при создании очередного ПР и всегда прислушиваться к себе.
@time2code
❤1
Документация лжет вам? Можно ли сохранить свежесть? 🥖
Когда приходится работать с чужим доменом, часто бывает, что единственное, на что можно полагаться во время предварительного ресерча продуктовой инициативы или другой задачи - это документация или слова владельцев функциональности или других коллег, кто с этим недавно работал.
Конечно, документация изначально выглядит надежнее: само слово предполагает наличие документа, который должен фиксировать какую-то договоренность или принцип работы.
Выступая ярым апологетом документации, все-таки признаю, что у нее есть явная особенность, которая легко превращается в недостаток - актуальность.
И, если вам кажется, что забытые на столе фрукты склонны быстро портиться, то это ничто по сравнению с тем, как быстро устаревает документация особенно в быстрорастущих компаниях, если ее регулярно не поддерживать.
С одной стороны, любая документация уже хорошо (так как многие команды/компании грешат тем, что ее нет ни в каком виде), но с другой - наличие неактуальной документации опасно.
Инженер, прочитав документацию, берет ее за основу будущей реализации задачи. Все последующие гипотезы и решения он начинает строить на ее базе. Конечно, если есть какая-то неточность, то уточняет, но вряд ли усомнится в правдивости какого-то утверждения, если в тексте оно однозначно.
Однако, на своем опыте я не раз уже обжигался об это. И то, что должно работать как написано, так не работает: уже или пока еще не научилось работать.
Например, документация обещает, что вы можете использовать данный инструмент, чтобы протестировать события, летящие в шину данных. Но, когда доходит до реализации, то оказывается, что протестировать вы можете не все события, а только определенные (конечно, события с нужным вам суффиксом пока не поддержаны).
Таким образом, неактуальная документация значительно уступает свежей коммуникации с владельцами домена или специалистами, которые в этом домене работают, так как опыт работы с системой не устаревает так же быстро, как документация.
Совет:
- Если у вас есть важная инициатива, реализацию которой вы планируете, опираясь исключительно на документацию или что-то еще, то, как и в журналистике, лучше заручиться несколькими источниками информации. Не всегда можно сразу проверить работу системы, поэтому прием: "прочитал в документации, что X=Y, уточните, пожалуйста, так ли это?" - отлично работает в большинстве ситуаций.
- Поддерживайте документацию в актуальном состоянии. Можно добавить в DoD пункт об обновлении документации. Это критично для владельцев горизонтальных доменов, которыми пользуется много команд. Сделайте это своей привычкой.
Писать документацию - непросто, а понятную для других и актуальную - очень сложно. Но это ценный навык, который серьезно поможет вам и пользователям вашей системы.
@time2code
Когда приходится работать с чужим доменом, часто бывает, что единственное, на что можно полагаться во время предварительного ресерча продуктовой инициативы или другой задачи - это документация или слова владельцев функциональности или других коллег, кто с этим недавно работал.
Конечно, документация изначально выглядит надежнее: само слово предполагает наличие документа, который должен фиксировать какую-то договоренность или принцип работы.
Выступая ярым апологетом документации, все-таки признаю, что у нее есть явная особенность, которая легко превращается в недостаток - актуальность.
И, если вам кажется, что забытые на столе фрукты склонны быстро портиться, то это ничто по сравнению с тем, как быстро устаревает документация особенно в быстрорастущих компаниях, если ее регулярно не поддерживать.
С одной стороны, любая документация уже хорошо (так как многие команды/компании грешат тем, что ее нет ни в каком виде), но с другой - наличие неактуальной документации опасно.
Инженер, прочитав документацию, берет ее за основу будущей реализации задачи. Все последующие гипотезы и решения он начинает строить на ее базе. Конечно, если есть какая-то неточность, то уточняет, но вряд ли усомнится в правдивости какого-то утверждения, если в тексте оно однозначно.
Однако, на своем опыте я не раз уже обжигался об это. И то, что должно работать как написано, так не работает: уже или пока еще не научилось работать.
Например, документация обещает, что вы можете использовать данный инструмент, чтобы протестировать события, летящие в шину данных. Но, когда доходит до реализации, то оказывается, что протестировать вы можете не все события, а только определенные (конечно, события с нужным вам суффиксом пока не поддержаны).
Таким образом, неактуальная документация значительно уступает свежей коммуникации с владельцами домена или специалистами, которые в этом домене работают, так как опыт работы с системой не устаревает так же быстро, как документация.
Совет:
- Если у вас есть важная инициатива, реализацию которой вы планируете, опираясь исключительно на документацию или что-то еще, то, как и в журналистике, лучше заручиться несколькими источниками информации. Не всегда можно сразу проверить работу системы, поэтому прием: "прочитал в документации, что X=Y, уточните, пожалуйста, так ли это?" - отлично работает в большинстве ситуаций.
- Поддерживайте документацию в актуальном состоянии. Можно добавить в DoD пункт об обновлении документации. Это критично для владельцев горизонтальных доменов, которыми пользуется много команд. Сделайте это своей привычкой.
Писать документацию - непросто, а понятную для других и актуальную - очень сложно. Но это ценный навык, который серьезно поможет вам и пользователям вашей системы.
@time2code
👍5
Сколько нужно людей, чтобы поменять лампочку в Биг Техе?
It depends ...
- эксперт, который обозначит правильный цоколь и необходимую мощность, чтобы она не взорвалась;
- дизайнер, чтобы оценил, насколько она вписывается в текущую концепцию;
- аналитик, чтобы просчитал затраты на эксплуатацию на протяжении 20 лет;
- юрист, который оценит возможные риски;
- специалист по закупкам, который закупит расходник в соответствии со спецификацией;
- руководитель, чтобы скоординировать процесс;
- и непосредственно исполнитель.
Гротеск? -Отчасти.
Многое зависит от решаемых задач и возможных рисков, которые важно избежать.
В Биг Техе крайне важна точность, так как любая ошибка очень дорого обходится. Поэтому такой подход применим.
Кейс из практики
Задача: уведомить определенных пользователей об изменении условий использования продукта, то есть оферты.
Предлагаю сделать паузу, подумать и сказать, сколько по времени может занять эта работа (в часах или днях).
Напишите в комментариях и сверьтесь с ответом под спойлером.
.
.
.
.
.
.
.
.
.
.
->30 дней
За которые:
1. PM определит концепцию сообщения, правильный тайминг и согласует с поддержкой изменения регламентов.
2. Аналитик выгрузит список пользователей, на которых нужно сделать рассылку.
3. Редактор напишет текст, который пойдет в рассылку.
4. Юрист вычитает текст редактора с точки зрения рисков.
5. Разработчик проведет ресеч по настройке шаблонов для рассылки и настроит.
6. CRM-менеджер вычитает настроенный шаблон письма с текстом и необходимыми параметрами.
7. Разработчик сделает скрипт в сервисе, чтобы отправка стала возможной, так как существует огромная очередь на отправку готовых шаблонов, если это делается силами команды CRM.
8. QA проконтролирует по трейсам, что все хорошо и пользователям сообщение доставили.
9. Тимлид всех скоординирует и проследит, чтобы задача была сделана в срок.
Стартап же справится с этой задачей менее чем за час (фаундер самостоятельно может всех точечно уведомить).
Но когда речь идет про продукт, которым пользуются миллионы, то лучше потратить дополнительное время, чтобы снять возможные риски.
И это нормально. Важно это учитывать.
Не нужно недооценивать задачу, какой бы маленькой и простой она ни казалась.
Серьезный и системный подход к решению любой проблемы - истинное отражение инженерной культуры.
@time2code
It depends ...
- эксперт, который обозначит правильный цоколь и необходимую мощность, чтобы она не взорвалась;
- дизайнер, чтобы оценил, насколько она вписывается в текущую концепцию;
- аналитик, чтобы просчитал затраты на эксплуатацию на протяжении 20 лет;
- юрист, который оценит возможные риски;
- специалист по закупкам, который закупит расходник в соответствии со спецификацией;
- руководитель, чтобы скоординировать процесс;
- и непосредственно исполнитель.
Гротеск? -Отчасти.
Многое зависит от решаемых задач и возможных рисков, которые важно избежать.
В Биг Техе крайне важна точность, так как любая ошибка очень дорого обходится. Поэтому такой подход применим.
Кейс из практики
Задача: уведомить определенных пользователей об изменении условий использования продукта, то есть оферты.
Предлагаю сделать паузу, подумать и сказать, сколько по времени может занять эта работа (в часах или днях).
Напишите в комментариях и сверьтесь с ответом под спойлером.
.
.
.
.
.
.
.
.
.
.
->
За которые:
1. PM определит концепцию сообщения, правильный тайминг и согласует с поддержкой изменения регламентов.
2. Аналитик выгрузит список пользователей, на которых нужно сделать рассылку.
3. Редактор напишет текст, который пойдет в рассылку.
4. Юрист вычитает текст редактора с точки зрения рисков.
5. Разработчик проведет ресеч по настройке шаблонов для рассылки и настроит.
6. CRM-менеджер вычитает настроенный шаблон письма с текстом и необходимыми параметрами.
7. Разработчик сделает скрипт в сервисе, чтобы отправка стала возможной, так как существует огромная очередь на отправку готовых шаблонов, если это делается силами команды CRM.
8. QA проконтролирует по трейсам, что все хорошо и пользователям сообщение доставили.
9. Тимлид всех скоординирует и проследит, чтобы задача была сделана в срок.
Стартап же справится с этой задачей менее чем за час (фаундер самостоятельно может всех точечно уведомить).
Но когда речь идет про продукт, которым пользуются миллионы, то лучше потратить дополнительное время, чтобы снять возможные риски.
И это нормально. Важно это учитывать.
Не нужно недооценивать задачу, какой бы маленькой и простой она ни казалась.
Серьезный и системный подход к решению любой проблемы - истинное отражение инженерной культуры.
@time2code
👍8
Продолжаем изучать ключевые идеи "Микросервисов".
Ранее:
-> загрузить v1
-> загрузить v2
-> загрузить v3
💡 После прочтения Главы 4 мы загрузим в себя следующие идеи:
1. Для поддержания согласованности данных следует использовать транзакции.
2. В распределенных системах рекомендуется применять повествования (саги), нежели распределенные транзакции.
3. Хореография и оркестрация - основные способы координации повествований.
4. Хореография хорошо работает с простыми повествованиями, но в более сложных случаях лучше применять оркестрацию.
5. Лучше проектировать повествование как модель конечного автомата.
6. Недостаточная изолированность - основной недостаток повествований.
7. Следует применять контрмеры как решение возможных аномалии при использовании повествований.
#it #литература #разбор #микросервисы
@time2code
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Июль 2025:
ключевые события
✔️ Успешно прошел 6-ой перф-ревью в компании. За последние 6 месяцев много перформил и устал - сейчас это ощущается. Но получил отличный результат и фидбек от коллег. Отдельно планирую порефлексировать на этот счет и подробнее рассказать про прошедшее ревью.
✔️ В июле сделал ставку на нетворкинг - много общался со знакомыми тимлидами, изучая проблемы других команд и находя возможности помочь им. В результате уже есть один успешный кейс.
✔️ Попрактиковался в функциональной композиции, избавлении от stateful в проекте и организации модульности.
✔️ Решил углубиться в дизайн программ: правильно думать про разделение реализации и спецификации, доказывать корректность программы через Триплы Хоара и пр.
✔️ Не могу не отметить очередной забег (на этот раз айтишный) на 10 км по 30-градусной жаре. Почти уложился в 50'... Подобные события серьезно помогают восстанавливаться после работы. Ментальная усталость замещается физической.
посты
⭐️ Сколько нужно людей, чтобы поменять лампочку в Биг Техе -> читать
🔖 Документация лжет вам. Можно ли сохранить свежесть? -> читать
🔖 Атомарные изменения лучше -> читать
#дайджест
@time2code
ключевые события
✔️ Успешно прошел 6-ой перф-ревью в компании. За последние 6 месяцев много перформил и устал - сейчас это ощущается. Но получил отличный результат и фидбек от коллег. Отдельно планирую порефлексировать на этот счет и подробнее рассказать про прошедшее ревью.
✔️ В июле сделал ставку на нетворкинг - много общался со знакомыми тимлидами, изучая проблемы других команд и находя возможности помочь им. В результате уже есть один успешный кейс.
✔️ Попрактиковался в функциональной композиции, избавлении от stateful в проекте и организации модульности.
✔️ Решил углубиться в дизайн программ: правильно думать про разделение реализации и спецификации, доказывать корректность программы через Триплы Хоара и пр.
✔️ Не могу не отметить очередной забег (на этот раз айтишный) на 10 км по 30-градусной жаре. Почти уложился в 50'... Подобные события серьезно помогают восстанавливаться после работы. Ментальная усталость замещается физической.
посты
⭐️ Сколько нужно людей, чтобы поменять лампочку в Биг Техе -> читать
🔖 Документация лжет вам. Можно ли сохранить свежесть? -> читать
🔖 Атомарные изменения лучше -> читать
#дайджест
@time2code
👍6
⏳ Сколько времени нужно, чтобы стать Senior? — Соединяю точки.
В декабре 2022 я предположил, что мне потребуется около трех лет, чтобы дорасти до 5-го грейда (senior по меркам Авито).
Прошло 2.5 года и вот я здесь...
Для меня это очень крупная веха. Возможно, самая крупная на этом карьерном треке.
Символизма добавляет пятилетний юбилей канала, который случился в июне.
Интересно, но в 2020 году у меня не было образа конечного результата, а только долгий и непонятный путь.
Знаменитая цитата очередной раз обрела смысл:
Еще два года назад я рисовал дорожную карту с привязкой к грейдам и планированием на несколько лет вперед.
Был ли я уверен, что смогу ей соответствовать? — Отнюдь. Слишком много переменных, но очень хотелось.
> Желание, системность и дисциплина - ключевые игроки, когда речь идет о реализации поставленных планов.
Конечно, сложно долгое время поддерживать все три составляющие на высоком уровне, возможна волатильность, но, если хотя бы одна сторона сильна, то она подтянет остальные. — Удивительно, но это работает.
Что дальше?
Если следовать дорожной карте, есть еще буфер в этом и следующем году, чтобы ничего радикального не предпринимать, а просто продолжить плыть по течению... но такая стратегия не по мне, нет в ней авантюры.
Когда-то я рассуждал, что интересно пойти в менеджерскую ветку, но пока это не сформировавшееся желание, а лишь одна из возможностей "на столе".
Последний год я плотно работал с высокогрейдовыми инженерами компании, видел их преимущества, но также и недостатки, а также возможность вырасти до их уровня или даже выше. Аппетит приходит во время еды...
Сейчас самое сложное — восстановиться, так как последний год работал в режиме форсажа и вкус жизни стал немного пресным.
Также важно пересмотреть долгосрочные планы на 2-3 года и, конечно, навалиться на последние 4 месяца 2025-го, чтобы постараться закрыть поставленные цели.
Планов много, энергии мало — впрочем, редко было иначе. Если вдруг есть рабочие рецепты по глубокой работе, а затем и полному восстановлению, то буду рад что-то перенять!
Для себя заметил, что восстанавливать энергию и находить силы помогает переключение фокуса. Все-таки многие недооценивают влияние когнитивной нагрузки на общее состояние, способности к работе и отдыху.
Поэтому ближайший маневр: замедлиться и осмотреться, куда привела меня работа последних лет, затем провести тщательный анализ и "пересобрать" лучшую версию себя.
@time2code
В декабре 2022 я предположил, что мне потребуется около трех лет, чтобы дорасти до 5-го грейда (senior по меркам Авито).
Прошло 2.5 года и вот я здесь...
Для меня это очень крупная веха. Возможно, самая крупная на этом карьерном треке.
Символизма добавляет пятилетний юбилей канала, который случился в июне.
Интересно, но в 2020 году у меня не было образа конечного результата, а только долгий и непонятный путь.
Знаменитая цитата очередной раз обрела смысл:
You can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.
Еще два года назад я рисовал дорожную карту с привязкой к грейдам и планированием на несколько лет вперед.
Был ли я уверен, что смогу ей соответствовать? — Отнюдь. Слишком много переменных, но очень хотелось.
> Желание, системность и дисциплина - ключевые игроки, когда речь идет о реализации поставленных планов.
Конечно, сложно долгое время поддерживать все три составляющие на высоком уровне, возможна волатильность, но, если хотя бы одна сторона сильна, то она подтянет остальные. — Удивительно, но это работает.
Что дальше?
Если следовать дорожной карте, есть еще буфер в этом и следующем году, чтобы ничего радикального не предпринимать, а просто продолжить плыть по течению... но такая стратегия не по мне, нет в ней авантюры.
Когда-то я рассуждал, что интересно пойти в менеджерскую ветку, но пока это не сформировавшееся желание, а лишь одна из возможностей "на столе".
Последний год я плотно работал с высокогрейдовыми инженерами компании, видел их преимущества, но также и недостатки, а также возможность вырасти до их уровня или даже выше. Аппетит приходит во время еды...
Сейчас самое сложное — восстановиться, так как последний год работал в режиме форсажа и вкус жизни стал немного пресным.
Также важно пересмотреть долгосрочные планы на 2-3 года и, конечно, навалиться на последние 4 месяца 2025-го, чтобы постараться закрыть поставленные цели.
Планов много, энергии мало — впрочем, редко было иначе. Если вдруг есть рабочие рецепты по глубокой работе, а затем и полному восстановлению, то буду рад что-то перенять!
Для себя заметил, что восстанавливать энергию и находить силы помогает переключение фокуса. Все-таки многие недооценивают влияние когнитивной нагрузки на общее состояние, способности к работе и отдыху.
Поэтому ближайший маневр: замедлиться и осмотреться, куда привела меня работа последних лет, затем провести тщательный анализ и "пересобрать" лучшую версию себя.
@time2code
🔥10👍4👏3❤1
Цель, которая работает на вас: умная практика для инженера и менеджера
В качестве ментора провожу регулярные встречи с менти.
Работаем с запросом: "составить структурированный индивидуальный план развития (ИПР) и получить понимание о том, как развивать сильные стороны".
— И это очень логично, прекрасно помню, как я составлял абсолютно такой же, когда подавал заявку на менторство и хотел расти, но в нем есть недостатки.
Если декомпозировать запрос, то на выходе получаем два фокуса:
1. Составить ИПР
2. Получить новое знание
И, если с ИПР относительно все понятно, так как нет ничего более конкретного чем наличие материального артефакта или его отсутствие (за исключением: какой ИПР нам нужен, для чего и когда), то с получением знаний всегда есть сложность, так как это очень абстрактная история.
Как можно оценить "получение знание", какую метрику применить? — Очевидно, что это очень субъективно, если, конечно, мы не захотим использовать какую-то методику оценки полученного знания, которая добавляет дополнительных действий и обозначает, тот факт, что непосредственно знания — не конечная точка, а лишь определенный момент перед условной аттестацией, которая впоследствии и сможет служить метрикой для оценки результата.
Я предложил менти переместиться на другой уровень абстракции и попробовать сформировать более четкий образ результата, который мы можем корректно оценить, когда его достигнем.
Наводящие вопросы:
- Является ли составленный ИПР конечной точкой при работе с ментором или это лишь одна из составляющей чего-то большего?
- С какой целью мы хотим получить новые знания или развить сильные стороны?
Нам важно сформировать точку Б, к которой хотим прийти, а чтобы понимать, что мы туда пришли нам важно уметь правильно формировать цели.
Вероятно, самый популярный фреймворк для этого - SMART.
Я всегда рекомендую его использовать, если есть проблемы с постановкой и достижением целей.
Конечно, к идеальной модели, которую предполагает фреймворк бывает прийти сложно, так как некоторые нюансы могут быть спорными или неочевидными, но сам по себе SMART "вытягивает" любую абстрактную цель в более конкретную, с которой легко работать.
Например, переформулируем составление ИПР:
Когда мы переложим и второй фокус на эту систему, то получим буквально план действия из сформированных целей, по достижению которого мы легко сможем ответить пришли ли мы к точке Б или еще далеко от нее.
Грамотное составление цели требует очень много ресурсов. Признаюсь, что я не всегда нахожу в себе силы формировать правильно, но держу в голове эту методику, чтобы из "плохих" целей делать средние, с которыми уже можно работать.
@time2code
В качестве ментора провожу регулярные встречи с менти.
Работаем с запросом: "составить структурированный индивидуальный план развития (ИПР) и получить понимание о том, как развивать сильные стороны".
— И это очень логично, прекрасно помню, как я составлял абсолютно такой же, когда подавал заявку на менторство и хотел расти, но в нем есть недостатки.
Если декомпозировать запрос, то на выходе получаем два фокуса:
1. Составить ИПР
2. Получить новое знание
И, если с ИПР относительно все понятно, так как нет ничего более конкретного чем наличие материального артефакта или его отсутствие (за исключением: какой ИПР нам нужен, для чего и когда), то с получением знаний всегда есть сложность, так как это очень абстрактная история.
Как можно оценить "получение знание", какую метрику применить? — Очевидно, что это очень субъективно, если, конечно, мы не захотим использовать какую-то методику оценки полученного знания, которая добавляет дополнительных действий и обозначает, тот факт, что непосредственно знания — не конечная точка, а лишь определенный момент перед условной аттестацией, которая впоследствии и сможет служить метрикой для оценки результата.
Я предложил менти переместиться на другой уровень абстракции и попробовать сформировать более четкий образ результата, который мы можем корректно оценить, когда его достигнем.
Наводящие вопросы:
- Является ли составленный ИПР конечной точкой при работе с ментором или это лишь одна из составляющей чего-то большего?
- С какой целью мы хотим получить новые знания или развить сильные стороны?
Нам важно сформировать точку Б, к которой хотим прийти, а чтобы понимать, что мы туда пришли нам важно уметь правильно формировать цели.
Вероятно, самый популярный фреймворк для этого - SMART.
Я всегда рекомендую его использовать, если есть проблемы с постановкой и достижением целей.
Конечно, к идеальной модели, которую предполагает фреймворк бывает прийти сложно, так как некоторые нюансы могут быть спорными или неочевидными, но сам по себе SMART "вытягивает" любую абстрактную цель в более конкретную, с которой легко работать.
Например, переформулируем составление ИПР:
Конкретная (Specific): Разработать индивидуальный план развития (ИПР) для собственного профессионального роста в текущей должности.
Измеримая (Measurable): ИПР должен включать как минимум 3 конкретные цели развития (например, "пройти курс X", "освоить навык Y до уровня Z", "реализовать проект А"), 2 ключевых показателя успеха (KPI) для оценки прогресса по каждой цели и список необходимых ресурсов/действий.
Достижимая (Achievable): Цели в ИПР должны быть реалистичными с учетом текущей нагрузки и доступных ресурсов (время, бюджет на обучение).
Актуальная (Relevant): Разработка ИПР напрямую связана с повышением моей эффективности в текущей роли и подготовкой к будущим задачам/продвижению.
Ограниченная по времени (Time-bound): Завершить разработку и согласовать ИПР с моим руководителем к, например, 28 августа 2025 года.
Когда мы переложим и второй фокус на эту систему, то получим буквально план действия из сформированных целей, по достижению которого мы легко сможем ответить пришли ли мы к точке Б или еще далеко от нее.
Грамотное составление цели требует очень много ресурсов. Признаюсь, что я не всегда нахожу в себе силы формировать правильно, но держу в голове эту методику, чтобы из "плохих" целей делать средние, с которыми уже можно работать.
@time2code
✍1