Уставший техдир

Разрабы должны чувствовать последствия своих решений

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

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

"Практика you build it - you run it" предлагает радикально другой подход: пусть тот, кто создает проблему, сам с ней и разбирается. Не из садизма, а из понимания простой истины — только почувствовав боль, разработчик начинает писать код по-другому. Когда разработчик знает, что в 3 утра его разбудит алерт от его собственного кода, магическим образом меняется отношение к качеству:
- Логирование становится осмысленным, а не формальным
- Обработка ошибок из "авось пронесет" превращается в продуманную стратегию
- Мониторинг закладывается на этапе проектирования, а не добавляется постфактум, чтобы номинально удовлетворить требования
- Архитектурные решения перестают приниматься по модели "и так сойдет"

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

А вообще, в идеале: Синьор, который никогда не дежурил по своему коду — это не синьор. Это теоретик. Настоящая экспертиза приходит только через понимание операционных последствий архитектурных решений.

Хороший разработчик думает не только "как это реализовать", но и:
- Как это будет деплоиться?
- Как это будет мониториться?
- Что будет, если это упадет?
- Как быстро можно будет найти и исправить проблему?

Это своего рода триггер культурного сдвига. В командах, где разработчики "чувствуют" последствия своих решений:
- Исчезает менталитет "не моя проблема"
- Появляется проактивное мышление о надежности
- Растет эмпатия к операционным командам и пользователям
- Формируется внутренний стандарт качества, который не зависит от внешнего контроля

П.С. Знали бы вы, сколько я контр-аргументов против выслушал по этому поводу
П.П.С. На КДПВ девелоперы заботливо развивают свои микросервисы ^__^

1💯41❤13👍11🔥7🥱3🤡1👀1

www.group-telegram.com/hk/tired_glebmikheev.com/2157

6.86K viewsedited  Sep 22 at 18:41

Разрабы должны чувствовать последствия своих решений

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

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

"Практика you build it - you run it" предлагает радикально другой подход: пусть тот, кто создает проблему, сам с ней и разбирается. Не из садизма, а из понимания простой истины — только почувствовав боль, разработчик начинает писать код по-другому. Когда разработчик знает, что в 3 утра его разбудит алерт от его собственного кода, магическим образом меняется отношение к качеству:
- Логирование становится осмысленным, а не формальным
- Обработка ошибок из "авось пронесет" превращается в продуманную стратегию
- Мониторинг закладывается на этапе проектирования, а не добавляется постфактум, чтобы номинально удовлетворить требования
- Архитектурные решения перестают приниматься по модели "и так сойдет"

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

А вообще, в идеале: Синьор, который никогда не дежурил по своему коду — это не синьор. Это теоретик. Настоящая экспертиза приходит только через понимание операционных последствий архитектурных решений.

Хороший разработчик думает не только "как это реализовать", но и:
- Как это будет деплоиться?
- Как это будет мониториться?
- Что будет, если это упадет?
- Как быстро можно будет найти и исправить проблему?

Это своего рода триггер культурного сдвига. В командах, где разработчики "чувствуют" последствия своих решений:
- Исчезает менталитет "не моя проблема"
- Появляется проактивное мышление о надежности
- Растет эмпатия к операционным командам и пользователям
- Формируется внутренний стандарт качества, который не зависит от внешнего контроля

П.С. Знали бы вы, сколько я контр-аргументов против выслушал по этому поводу
П.П.С. На КДПВ девелоперы заботливо развивают свои микросервисы ^__^

BY Уставший техдир