Как писать код при коллективной разработке

Семь принципов, сводящихся к «не навреди».
4 минуты6264

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

Сервисы Git, SVN, Mercurial упрощают коллективную разработку, но не заменяют основных правил эффективного взаимодействия. Именно о них и пойдет речь.

Принцип первый. Разделение по интересам

Главный вопрос — как делить области ответственности? Личный интерес здесь имеет первостепенное значение. Без желания каждого члена коллектива выложиться на максимум невозможно получить на финише успешный проект. Поэтому в основе разделения должен быть не опыт и не слепой жребий, а инициатива участников, которые хотят отвечать за конкретный участок работы.

Распределить все обязанности только по такому признаку не получится. Есть спецы без предпочтений — они бы с радостью взялись и за полноценную разработку. Или на одну область будут претендовать несколько человек, а на другую — ни одного. Тогда в ход идет второй принцип.

Принцип второй. Разделение по опыту

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

А вот личностные характеристики должны отойти на второй план. Если человек с резюме «халтурщика» горит идеей реализовать модуль, худшее, что можно сделать — пойти на поводу у сомнений. В первые же рабочие дни вы узнаете, кто подтверждает опасения, а кто решил их опровергнуть. Так к чему портить отношения на этапе планирования?

Принцип третий. Общие правила оформления

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

Сразу договоритесь об основных моментах:

  1. Комментарии. Должны быть короткими и понятными, дополнять код, а не расшифровывать его.
  2. Стиль. В каждом языке есть свод правил по оформлению кода, но команда может очертить собственные основные принципы — относительно пространства имен, табуляций, формирования модулей.
  3. Настройки. Организационные моменты, касающиеся выбора общей среды разработки, настроек доступа, подключаемых библиотек и прочего.

Принцип четвертый. Карта вопросов

Когда новички вступают в командную разработку продукта, требующего более высокого уровня подготовки, у них возникает множество вопросов. Выход первый — задавать их напрямую более опытным коллегам. Способ почти идеальный, но далеко не всегда разъяснение бывает оперативным. Второй — искать решение самостоятельно, но помнить, что это может стать «бутылочным горлышком» проекта. И в этом случае надо позаботиться о «карте вопросов»: комментариях в коде или отдельном текстовом файле, адресованных проверяющему. Так все причастные смогут понять, где в проекте потенциальные проблемы.

Принцип пятый. Визуализация

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

Визуализировать можно не только алгоритм, но и схему кода. Это поможет не только окружающим, но и вам — задачи не будут скакать от строки к строке, а соберутся в блоки.

Принцип шестой. Перекрестный опрос

Когда код написан, надо его проверить. Заниматься этим самому необходимо, но 100% качества это не дает. Поэтому хорошо бы изначально понимать, кто за проверку чьего кода будет отвечать.

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

Выгоды здесь две:

  1. Меньше времени на адаптацию. Когда взаимодействие ограничено двумя людьми, вы не тратите часы на привыкание к чужому стилю, выяснение задач и способов решения. Изложенные выше принципы командной разработки минимизируют сложности индивидуального подхода, но не устраняют их совсем. Перекрестная проверка — еще один помощник.
  2. Больше времени для коммуникации. Когда два человека проверяют друг друга, они «на связи» и могут чаще задавать мелкие вопросы, которые в ином случае забылись бы. А успех от провала часто отделяет мелочь.

Принцип седьмой. Время на проверку

Хоть проверять код и необходимо, но нельзя затягивать эту работу. Следуйте правилу: проверка чужого кода не должна занимать более 10% от общей деятельности.  Это статистический барьер, который позволяет определить шаг проверок, контролировать выполнение правил и не отставать от общего графика из-за халтуры отдельных коллег.

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

коллективная разработкаорганизация разработкиразработка
Нашли ошибку в тексте? Напишите нам.
Спасибо,
что читаете наш блог!