Не по документации

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

Синдром самоповтора. Управляемая неопределённость В конструкции, где задачи между системами распределяются не структурно, а по уровню бизнес-приоритетов, со временем проявляется ещё одна проблема. Связанные компоненты одних и тех же бизнес-процессов начинают жить в обеих версиях. Это во многом следствие длительной миграции функционала с параллельной реализацией новых концепций на стадии MVP. Если развитие системы 1 не ограничено и приоритеты смещены в сторону скорости создания новых фич под конк...

Почему без владельца архитектуры система всегда выбирает деградацию В любой сложной системе изменения происходят постоянно. Вопрос не в том, будут ли они, а кто и на каких условиях за них отвечает. Когда у архитектуры нет владельца, система не «замирает». Она продолжает изменяться, но по пути наименьшего сопротивления. Каждое локальное решение принимается рационально в своём контексте: - быстрее закрыть задачу; - снизить риск локального инцидента; - не трогать опасные участки. Но при отсутствии ...

Синдром самоповтора. Переломный момент Итак, решение принято - системе 2 быть. Мы можем выбрать фреймворки, сопутствующие технологии и библиотеки, методологию, стиль кода, новый проект в трекере задач и так далее. Нужно определиться с составом команды: нанять новых людей и/или выбрать нескольких «старичков» из тех, кто «готов». Иными словами - определить конфигурацию системы и её управленческие границы до написания первой строчки кода. Это важно. Здесь нельзя действовать наобум. Такие решения на...

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

Синдром самоповтора. Вступление На этапе создания MVP компания обычно готова пожертвовать всем, что замедляет разработку. Для запуска прежде всего важна скорость - обо всём остальном решат позже. В основу платформы выбирается простая и распространённая технология. В случае успешного запуска она продолжает развиваться по тем же лекалам: компания закрепляет достигнутый результат и фактически закладывает это решение в основание своего бизнеса. Со временем наступает момент, когда выбранное решение п...

Устаревшие рамки и свобода внутри Архитектурные рамки почти всегда формируются в прошлом, под прошлые задачи. Если они не пересматриваются, возникает парадокс: - сверху изменения блокируются; - внутри рамок полная свобода. Команда выживает внутри устаревшей модели, оптимизируя локально. Каждый компонент начинает жить по своим правилам, алгоритмы и данные дублируются, интеграции усложняются. Любое изменение (даже направленное на развитие) требует дополнительных «подстраховок». Это объясняется не ...

Почему “равная команда без иерархий” ломается на джунах Идея “все равны, давайте договариваться” работает только в системе, где: - участники примерно одного уровня; - цена ошибки низкая; - решения обратимы; - у всех есть навык принятия ответственности; Как только в систему попадает джун эта модель начинает трещать. У джуна нет внутренней опоры. Он ещё не отличает: - плохое решение от непопулярного; - критику идеи от критики себя; - обсуждение от конфликта; В “равной” системе он вынужден защищать...

Про проверки идентификаторов и границы ответственности Иногда встречается подход: если в функцию по сигнатуре приходит id, то его нужно проверить на существование в БД. И так в каждой функции, через которую этот id проходит. Формально логика понятна: функция не знает, валиден ли вход. Но архитектурно это сигнал о другой проблеме - в системе отсутствуют доверенные границы. В любой системе есть: - точки входа, где данные считаются недоверенными и валидируются; - внутренний контур, где действуют ин...

CTO без мандата — это не роль, а ловушка Иногда в стартапе дают титул CTO. Это выглядит как рост. На практике - это позиция с максимальной ответственностью и нулевыми рычагами. Ниже - признаки, по которым это можно распознать до входа в проект. 1. Нет зафиксированного финального решения. Контрольный вопрос: «Кто принимает финальное техническое решение?» Тревожные ответы: - «обсуждаем вместе»; - «зависит от ситуации»; - «решаем консенсусом»; Перевод: финального решения нет. Значит, любое решение ...