Совместное владение кодом

Это когда любой разработчик из любой команды может внести изменения в любой программный компонент. Когда писал пост, с удивлением узнал, что эта практика относится к экстремальному программированию 🙂

Такой подход дает продукту гибкость и сокращает Time-to-Market для фич. Номинально каждый разработчик несет ответственность за весь исходный код. Но в этом есть опасность.

Collective code ownership, — коллективное хозяйство. По-другому — «Колхоз». Для кого-то это слово с явно негативным оттенком, пахнет навозом и потными людьми.

Почему оттенок негативный? Проблема в среде.
Общее - значит ничье. Не свое, не жалко.
Так рождаются костыли, код замусоривается и начинает пахнуть. Проблема не в том, что программисты плохие. Проблема в том, что среда вокруг поощряет «пятилетку в три года» и «быстро-быстро, срочно в прод еще вчера». Зачастую в такой среде программисты увольняются раньше, чем сталкиваются с последствиями своих технических решений.

Чтобы выжить и преуспеть, продукт должен быть здоровым и не должен деградировать по скорости внесения изменений. А для этого все компоненты должны быть здоровы.

Мы можем создать среду, поощряющую внутреннее качество системы и её компонентов.

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

А как вы поддерживаете внутреннее качество?
Поделитесь экспертизой в комментах