понедельник, апреля 14, 2008

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

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

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

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

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

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


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

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

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

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

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



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

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

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

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

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


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

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

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

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

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


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

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

5 комментариев:

sse комментирует...

все настолько верно и essential, что по болшому счету и прокомментировать нечем :)

Анонимный комментирует...

точно! не о чем и спорить :)
кстати некоторые менеджеры целенаправленно "тусуют" людей между разными участками системы как раз на случай если кто уйдет/заболеет

Анонимный комментирует...

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

Анонимный комментирует...

Нужно делать оговорку - это всё справедливо только в том случае, когда вы имеете хорошо мотивированную команду.

Sergey Rozovik комментирует...

Ответы господам Анонимам

> зачастую у разработчиков просто не будет хватать времени смотреть код коллеги и тем более разбираться в нём и что-то потом исправлять

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

>это всё справедливо только в том случае, когда вы имеете хорошо мотивированную команду
Всегда надо иметь хорошо мотивированную команду :) Однако если в команде установлены правила, то либо ты их выполняешь, либо ты уходишь из этой команды.
Сегодня с утра я могу быть жутко немотивирован (например после вчерашнего дня рождения), но я не имею права комитить код который порушит билд. В соседней команде есть даже специальный переходящий флажок на подставке с надписью "Build destroyer" для таких случаев. Мы обходимся без флажка :)