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

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

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

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

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

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

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

Предметно-ориентированный подход (DDD, Domain-Driven Design) в проектировании программного обеспечения является наиболее эффективным способом моделирования бизнес-процессов. Сегодня мы поговорим о стратегическом и тактическом проектировании, после чего рассмотрим инструмент ускорения проектирования под названием «событийный штурм» (event storming).

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