Исходный код
Промежуточный плод совместных усилий и, собственно, самое важное из того, для чего нужны такие совместные усилия. Как бы ни были далеки друг от друга участники команды, они неизбежно пересекутся здесь. Поэтому так важно планировать и организовывать процесс командного внесения изменений в код. Существует несколько подходов к этому вопросу:
- Коллективное владение кодом. Подход хорошо описан в литературе по экстремальному программированию (XP), и в теории обладает целым рядом преимуществ, включая непрерывный обмен знаниями о системе, взаимозаменяемость участников команды, однообразие получаемого кода и непрерывное его улучшение. На практике, чтобы получить все эти преимущества, надо иметь либо по-настоящему сплоченную команду единомышленников, либо ограничиться вариантом, когда один ведущий разработчик выдает конкретные задания нескольким исполнителям и сам определяет степень их вмешательства в работу друг друга. С моей точки, коллективное владение кодом подходит лишь для очень небольших команд – от 1 до 5 человек. В любом случае надо быть готовым к тому, что коллективное владение кодом очень быстро может превратиться в бесконтрольное. В самом плохом сценарии это приведет к тому, что одни разработчики будут исправлять написанный другими код, не вникая в его детали или откатывать сделанные другими изменения, другие будут до последнего защищать свою часть кода от вмешательства со стороны. Такая ситуация порождает безответственность и напряженные отношения в группе.
- Каждый пишет свою часть кода. Разделяя зоны ответственности программистов, мы имеем плюсы в виде довольных программистов, часто предпочитающих работать в одиночку, и персональной ответственности за выделенную часть функциональности. Однако недостатков тоже хватает: каждый программист зачастую пишет в своем стиле, плохо понимает чужой код, а потому, когда один программист уходит из проекта, его код иногда оказывается невозможно сопровождать. Кроме того, малое внимание уделяется взаимодействию модулей, написанных разными программистами, которых больше заботит внутреннее устройство модуля, чем его интеграция с модулями других разработчиков.
- Худшей комбинацией обоих подходов видится мне ситуация, когда один разработчик пишет код, другой исправляет ошибки. В этом случае получаем безответственность первого программиста и разочарование второго. Должен отметить, что если исправить ошибку в собственном коде для программиста – дело чести, то доделывать некачественную работу других – крайне неприятное занятие.
- Наиболее привлекательной мне кажется другая комбинация подходов, возможная при компонентной архитектуре: каждый компонент разрабатывается только одной локальной командой, внутри команды – коллективное владение кодом. Взаимозаменяемость и обмен знаниями обеспечивается на уровне каждой команды, причем локальность команды гарантирует быстрое и безболезненное решение возможных спорных вопросов. Границы компонентов препятствуют непосредственному вмешательству одной команды в работу другой. В то же время ориентация на компонентную архитектуру предполагает, что вопросам взаимодействия компонентов (интерфейсам) будет уделено должное внимание.
