Коллективное владение кодом

Сегодня с утра вы увидели что билд вашего проекта не собирается. В модуле логгирования кто-то изменил сигнатуру метода и теперь компилятор выдает 286 ошибок.

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

Знакомая картина, не правда ли? Если ваш проект достаточно велик, чтобы на нем работало более двух программистов, то подобные проблемы возникают постоянно и воспринимаются как обыденные и неизбежные. Причина их в политике владения кодом (code ownership), точнее в политике персонального владения кодом.

Такая политика весьма распространена и по большей части складывается стихийно. Проводники этой политики - менеджеры проектов. Менеджер распределяет задачи между программистами. Менеджер хочет чтобы ресурсы на проекте использовались с максимальной эффективностью (если кто не в теме, для менеджера ресурсы на проекте - это люди), поэтому он старается разбить систему на блоки (вертикально, по функциональным признакам, или горизонтально по структурным) и закрепить эти блоки за конкретными программистами. Работая над одним и тем же блоком, программист будет работать быстрее, потому что ему не надо постоянно разбираться с чужим кодом. Так думает менеджер, и он ошибается.
Политика персонального владения кодом возводит в разрабатываемой системе барьеры, там где их не должно быть. Барьеры, для которых нет никаких причин, ни функциональных, ни системных, кроме причин чисто субъективных, психологических и организационных. Потери времени на преодоление этих барьеров многократно превышают полученный выигрыш. Но если бы терялось только время... Часто бывает, что устав ожидать пока программист сделает нужные изменения в "своем" коде, другой разработчик дублирует этот код в "своем" модуле, разрушая тем самым структуру и целостность системы.

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

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

Тем не менее, коллективное владение кодом не только не приводит к хаосу в разработке, но и помогает решить многие проблемы в разработке. Потому что, как обычно в XP, за парадоксальным названием стоят весьма прагматичные правила и принципы. Давайте разберемся какие.

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


2. При этом каждый программист несет ответственность за весь код системы.


3. Изменяя код в одном месте, программист обязан внести соответствующие изменения во всех остальных частях системы, чтобы обеспечить собираемость и правильное функционирование.


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

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

Какие плюсы дает политика коллективного владения кодом:

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


• Большая устойчивость кода. Программист который вносит изменения в код должен добиться собираемости всей системы. Если его изменения затрагивают другие части системы, он вносит туда изменения самостоятельно, а не оставляет эту работу другим программистам (в это время система не собираема). Если изменения рушат какую-то часть системы или противоречат дизайну другой части системы, программист узнает об этом сразу, а не спустя некоторое время.


• Более высокое качество кода. Программисты в процессе работы просматривают код, написанный другими программистами. Меньше посторяющихся кусков кода. Отсутствует ситуация когда программисту проще скопировать "чужой" кусок кода и самому внести в него изменения, чем дождаться пока нужные изменения сделает владелец кода.


• Лучшие коммуникации. Каждый программист более менее хорошо знает всю систему. Нет таких ситуаций, когда из команды уходит программист и никто не знает что делать с частью системы, которую он писал.

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

Политику коллективного владения кодом можно применять не только в проектах выполняемых по методологиям XP или Agile. Важно только понимать, что она не будет работать без определенного набора "поддерживающих" практик:

• Должна использоваться система контроля версий исходного кода.


• Должна практиковаться непрерывная интеграция (разработчик не сидит неделями в своем коде, а сбрасывает свои изменения в репозиторий после завершения каждой микро-задачи) и регулярные автоматизированные сборки проекта.


• Должны быть модульные тесты.

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

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