Всем привет! Меня зовут Сергей, и у меня есть жгучее желание поделиться с вами концепцией разработки через капсулы. Если вы пока не понимаете, что это означает — это нормально. Термин новый, и его определение я как раз дам в этой статье. Я решил ввести понятие «капсула», потому что не нашёл существующего термина с нужным смыслом — пришлось придумать свой.
Статья будет посвящена в основном процессам разработки внутри одной абстрактной компании: их организации и улучшению с помощью нового термина «капсула». Я приведу примеры из своего опыта осознанного применения капсул в разных проектах и процессах. Но прежде чем дать определение самому термину и рассказать, как это работает, важно разобраться в причинах его появления. Поэтому начнём с самого главного — с опыта.
Серия «Разработка через капсулы»:
Часть I: Опыт, который нельзя потерять: что такое капсула и зачем она нужна ← вы здесь
Часть II: Капсульный фреймворк: как мы упаковали архитектуру в ДНК проектов (скоро)
Часть III: Капсулы и AI-агенты: как передать опыт разработчика машине (скоро)
Опыт
Опыт — это ценный ресурс, который мы добываем в процессе разработки программного обеспечения. Работая над новым продуктом, мы можем использовать добытый опыт, чтобы сделать следующий продукт лучше: учесть ошибки, применить шаблоны, о которых слишком поздно подумали в прошлом. И этот процесс по своей сути бесконечен.
Эта простая схема интуитивно понятна, но в ней не хватает одного важного звена. Опыт — это ресурс. Значит, должен существовать процесс, позволяющий хранить добытый потом и кровью опыт, очищать его, упаковывать и предо��тавлять к нему простой и понятный доступ, когда он понадобится для новой разработки.
Без такого процесса опыт остаётся внутри тех сотрудников, которые участвовали в его получении. Передача знаний становится хаотичной и стихийной. Как передать опыт внутри компании между разными командами? Как не потерять накопленный и замкнутый на одном разработчике или команде ценный ресурс? Вопрос далеко не тривиальный.
Сложность ещё и в том, что опыт, полученный в конкретном проекте, во многом уникален и «сырой». На процесс разработки всегда влияют разные факторы: бизнес, внутренние процессы, сами люди, участвующие в проекте, и наконец, предыдущий «неочищенный» опыт. Каждый продукт создаётся не в вакууме, а в конкретном контексте, и этот контекст оставляет след в виде примесей в опыте. Эти примеси нежелательно переносить в будущие проекты.
Какие примеси может содержать опыт?
(Небольшое пояснение: когда я пишу «например», я имею в виду то, с чем сам сталкивался, а не придуманные случаи.)
Антипаттерны в процессах. Часто скорость разработки ставится выше всего: главное — реализовать функционал, а остальное потом «догоним». Основания у такого подхода вполне понятные, но однажды закрепившись в одном проекте, он превращается в привычку. С этим свыкаются, и последствия догоняют позже — обычно продукт, а не самих разработчиков. Например, в проекте могут полностью отсутствовать тесты или релизный цикл. Наверняка и вы сталкивались с этим. Такой опыт не должен переходить дальше, даже если продукт получился успешным. «Антипаттерны в процессах» должны превращаться в вопросы для следующего продукта: Как организовать тестирование? Как выстроить релизный цикл в условиях дефицита времени?
Серебряная пуля. Это опыт, который когда-то подсмотрели и теперь применяют повсюду. Чаще всего носителями такого подхода становятся опытные разработчики с высоким авторитетом. «Пуля» может быть как паттерном, так и технологией. Например, вы привыкли использовать PostgreSQL и тащите её во все проекты. Или решаете, что бизнес-логику всегда нужно хранить в хранимых процедурах. Я не утверждаю, что PostgreSQL или хранимые процедуры — плохая практика. Но такие решения не должны переходить из проекта в проект автоматически. Для них нужны основания.
Ошибка выжившего. Эта примесь особенно опасна, потому что подкрепляется реальным успешным кейсом. Например, в одном проекте вы применили ClickHouse — отличную СУБД от Яндекса. Но если проект требовал OLTP-хранилища с точечными запросами, это был неверный выбор. В конкретном проекте эта ошибка могла и не стать проблемой (нагрузка оказалась небольшой), но опыт закрепился. В следующем проекте это может привести к катастрофе.
Опыт с примесями не хочется передавать дальше. Его трудно структурировать, и ещё труднее отделить контекст, в котором он был получен, от самой сути. В итоге мы стремимся переиспользовать только чистый опыт, без лишних и вредных примесей.
Таким образом, формируется правильный зацикленный конвейер разработки:
Итак, мы поняли, что опыт — ценный, но "сыр��й" ресурс, требующий осмысленного подхода. Но что делать с обнаруженными примесями? Давайте разберёмся, как превратить этот сырой материал в чистое знание.
Очистка опыта
Очистка опыта — сложный, но необходимый этап. Примесей может быть много, и список, который я привёл выше, далеко не полный. Убирать их можно разными методами:
Ретроспективы. Идея непрерывного улучшения через саморефлексию лежит в основе Agile. Обычно ретроспективы помогают улучшать команду в рамках конкретного продукта, но этот ритуал можно расширить — добавить общую рефлексию над полученным в проекте опытом. Например, если вы не пишете тесты из-за сжатых сроков или постоянно копите технический долг — стоит прямо обозначить это как проблему. Конечно, обозначение и решение — не одно и то же. Но в контексте удаления примесей важно, чтобы у участников отложилось: это проблема. И даже если здесь её не получится решить, на следующем проекте она не станет чем-то «само собой разумеющимся». Более того, именно в такой рефлексии может родиться идея собственной «капсулы» (о них — в следующем разделе), которая поможет системно решать подобные проблемы в будущем.
Бритва Хитченса. Гносеологический принцип, отлично подходящий для отсечения «серебряных пуль». Он звучит так: кто утверждает — тот и доказывает или «то, что легко утверждается, так же легко и отбрасывается». Кто-то предлагает использовать PostgreSQL? Отличный вариант! Но нужны аргументы «за» и «против». Если плюсов меньше, чем минусов, или они слабее — значит, решение сомнительное. А аргумент «мы всегда так делали» вообще не должен приниматься во внимание.
Техрадар. Отличный инструмент, о котором я подробнее расскажу чуть позже. Хорош он тем, что уже почти является капсулой. Многие примеси в опыте проявляются именно в выборе или неправильном использовании технологий. Техрадар помогает отсеивать такие примеси: он фиксирует, какие технологии компания использует и на каком уровне зрелости.
Обычно категории выглядят так:
Используем смело
Пробуем в безопасных проектах
На исследовании
Больше не используем
Если у вас есть техрадар и процессы работы с ним, вы просто не начнёте использовать технологию, которой в компании никогда не было. Соответственно, сильно снижаете риск получить «ошибку выжившего». Даже если такая примесь всё же просочится, она не приведёт к катастрофическим последствиям и с большой вероятностью будет устранена рефлексией.
В итоге мы получаем набор инструментов, которые помогают убрать примеси и оставить только чистый опыт, готовый к повторному использованию. А теперь — к самому главному: как упаковать этот опыт.
Упаковка опыта и что такое капсула?
Как вы уже, наверное, догадались, под «капсулой» я подразумеваю конечный продукт, полученный в результате упаковки очищенного опыта.
Капсула — это самодостаточная, минималистичная система, которая инкапсулирует экспертные знания и опыт в конкретной предметной области, предоставляя готовый инструмент для решения узкоспециализированной задачи без необходимости прямого участия экспертов.
Формулу можно записать так:
Капсула = Экспертное знание + Минимализм + Готовый инструмент
По сути, капсула — это компактная система, где опыт и конкретные данные вашего контекста превращаются в ядро процесса, его ДНК. При этом капсула может принимать разные формы в зависимости от процесса. Чтобы лучше показать разницу, приведу два примера — с капсулой и без неё.
1. Процесс разработки
Рассмотрим ситуацию, когда в компании несколько команд и несколько схожих проектов.
Без капсулы:
Каждая команда сама выделяет архитектурные паттерны и принципы, на которых строится проект. Иногда они совпадают, иногда нет.
Далее подключаются сторонние фреймворки. Они универсальны и не диктуют, как именно их использовать. Например, один проект может реализовать JSON-REST-API, другой — HTTP-RPC, даже если использован один и тот же роутер.
В итоге схожие проекты расходятся по структуре и принципам.
Каждый проект сильно зависит от собственных экспертов: убрать их без вреда невозможно.
С капсулой:
Вначале выделяется и формируется капсула — например, в форме минималистичного фреймворка, основанного на опыте экспертов.
Допустим, нам нужна микросервисная архитектура, управляемая событиями. Тогда мы создаём фреймворк, который позволяет создавать сервисы и генерировать события. В отличие от универсальных решений, у него нет вариативности — только жёсткая структура.
Эксперты развивают этот фреймворк, тем самым влияя на все проекты, построенные на этой капсуле.
Эффекты:
Схожие проекты сохраняют одинаковую структуру и принципы на всём протяжении жизни (как клетки, одинаковые за счёт одной ДНК).
Капсульный фреймворк диктует реализацию в своей зоне ответственности до мелочей — вплоть до расположения и нейминга файлов.
Весь опыт сконцентрирован в самом фреймворке. Даже если эксперты уйдут, капсула сохранит их знания.
2. Оценка проекта на входе
Задача: выяснить, сколько времени займёт реализация проекта по размытым вводным от заказчика.
Без капсулы:
Нужно привлекать эксперта.
Результаты сильно зависят от личности эксперта и могут отличаться у разных специалистов.
Каждый раз тратится время экспертов на один и тот же процесс.
Оценка часто носит субъективный характер и не воспроизводима.
С капсулой:
Эксперты один раз формируют капсулу — методологию оценки и математическую модель, основанную на опыте и свойствах проектов.
Капсула используется повторно, без постоянного привлечения экспертов.
Эксперты же направляют усилия на развитие капсулы: корректируют ДНК процесса по результатам её применения.
Эффекты:
Нет зависимости от конкретного эксперта и его настроения.
Для одинаковых входных данных результат всегда один.
Время экспертов уходит на развитие ядра процесса, а не на рутинные оценки.
Оценка получает твёрдое и прозрачное основание — модель.
Мы разобрались, что такое капсула, и увидели её пользу на примерах. Теперь стоит взглянуть на инструмент, который уже широко используется в компаниях и по своей сути близок к капсуле. Речь идёт о техрадаре.
Техрадар — как пример почти капсулы
Техрадар — это инструмент стратегического планирования, который помогает командам разработки и IT-департаментам отслеживать, оценивать и принимать обоснованные решения о внедрении новых технологий, инструментов, платформ и практик. Проще говоря, это «карта» технологического ландшафта, помогающая выбирать технологии для проектов. Сама идея и устройство этой карты основаны на обширном опыте консалтинговой компании ThoughtWorks, в частности на опыте архитекторов и технических экспертов во главе с бывшим CTO Ребеккой Парсонс. Это отличный пример «запечатанного» чужого опыта в модель, структуру, которую могут переиспользовать другие компании.
Но давайте проверим эту методологию по формуле капсулы:
✓ Экспертное знание. Техрадар — это методология, в которую «запечатан» опыт.
✓ Минимализм. Техрадар сосредоточен только на управлении технологиями. Ничего лишнего.
❌ Готовый инструмент. С этим есть проблема. Можно ли просто использовать техрадар? Нет, и вот почему.
Техрадар очень похож на капсулу, но есть ключевое отличие: сам по себе он не диктует конкретные правила, которым нужно следовать именно вам. Как технологии появляются на техрадаре? Как они перемещаются между квадрантами? Когда и каким образом пересматриваются их уровни? Это только самые очевидные вопросы.
Ответить на них можете только вы, основываясь на своём опыте и контексте. Эта грань отделяет инструменты, фреймворки и методологии от капсул. Капсула — это модель с конкретными правилами использования, и эти правила задаёте вы сами, поскольку только вы в полной мере обладаете знаниями о своём контексте.
Если проводить аналогию с программированием, то Техрадар — это абстрактный класс с базовой функциональностью и набором абстрактных методов. Без вашего личного контекста он остаётся абстракцией. Реализация этих «абстрактных методов» — правил и процессов — превращает его в вашу капсулу, в ядро процесса управления технологиями в вашей компании.
Как мы выяснили, техрадар — это почти капсула, но ему не хватает контекста и конкретных методов работы с ним. Давайте теперь рассмотрим полноценную капсулу в действии — на примере нашего капсульного фреймворка для распределённых систем.
Как понять, что процесс созрел для капсулы?
Процессы в компании часто складываются стихийно и держатся исключительно на знаниях конкретных сотрудников. У таких процессов есть «имена и фамилии» — когда уходит ключевой специалист, процесс либо кардинально меняется, либо «перерождается» под новым именем. Иногда это идёт на пользу, но чаще нет. Хаотичная смена процессов редко сказывается на компании положительно.
Выделяя ядро процесса в капсулу, мы делаем его стабильнее. Роль сотрудников, работающих с капсулой, остаётся важной, но перестаёт влиять на само ядро кардинальным образом. Ядро сохраняется даже после ухода человека — пусть и может временно замедлить развитие.
Из этого следует простой способ проверки: если ядром вашего процесса является конкретный человек — это сигнал к созданию капсулы. Сотрудник, который раньше был ядром, теперь должен ядро развивать.
Например: только senior-разработчик Иван умеет оценивать сложные проекты, и с его уходом процесс оценки рушится. Это явный повод создать капсулу оценки — методологию и модель, которая останется в компании независимо от Ивана.
Таким способом можно проверить любой процесс — от верхнеуровневых до самых прикладных. Если вы уже используете какой-то инструмент, прогоните его по формуле:
Капсула = Экспертное знание + Минимализм + Готовый инструмент
Возможно, вы уже неосознанно пользуетесь капсулой. Если инструмент не соответствует всем трём компонентам — его стоит доработать.
Итого
Итак, к чему мы пришли. Опыт — ценный ресурс, но в сыром виде он ненадёжен: содержит примеси, привязан к конкретным людям и плохо передаётся. Чтобы опыт работал на следующий проект, а не просто оседал в головах команды, его нужно очистить и упаковать. Результат этой упаковки — капсула.
Капсула — не очередной фреймворк и не методология в вакууме. Это инструмент, в котором живёт именно ваш контекст, ваши решения, ваши правила. Именно поэтому нельзя взять чужую капсулу и использовать как свою — она станет вашей только после того, как вы вложите в неё собственный опыт.
В следующей части я покажу, как мы создавали свою первую капсулу — капсульный фреймворк для микросервисов. Что закладывали в основу, какие решения принимали и почему. И как эта капсула стала ДНК наших проектов.
