Елена Булыгина предлагает Вам запомнить сайт «Ленусик»
Даже на онлайн-курсах по базовому программированию студенты объединяются в группы, чтобы в дальнейшем взяться за разработку крутых приложений. Один человек может придумать хорошую идею, заложить качественный фундамент. Но реализация, нацеленная на миллионы пользователей — задача для команды.
Сервисы Git, SVN, Mercurial упрощают коллективную разработку, но не заменяют основных правил эффективного взаимодействия. Именно о них и пойдет речь.
Принцип первый. Разделение по интересам
Главный вопрос — как делить области ответственности? Личный интерес здесь имеет первостепенное значение. Без желания каждого члена коллектива выложиться на максимум невозможно получить на финише успешный проект. Поэтому в основе разделения должен быть не опыт и не слепой жребий, а инициатива участников, которые хотят отвечать за конкретный участок работы.
Распределить все обязанности только по такому признаку не получится. Есть спецы без предпочтений — они бы с радостью взялись и за полноценную разработку. Или на одну область будут претендовать несколько человек, а на другую — ни одного. Тогда в ход идет второй принцип.
Принцип второй. Разделение по опыту
Идеальная команда должна состоять из профессионалов разных направлений и быть сплавом энтузиазма и опыта. Нужны те, кто бесконечно генерирует идеи и фичи, не задумываясь о сложности реализации. Не обойтись и без тех, кто все упрощает и движется к цели поэтапно. Есть еще третья группа — наблюдатели. Они прохладно относятся к проекту, но имеют опыт и готовы ответственно все исполнить. Именно в таком приоритетном порядке разработчики должны выбирать задачи. Окончательное решение лучше оставить за второй группой — их мнение имеет наибольший вес.
А вот личностные характеристики должны отойти на второй план. Если человек с резюме «халтурщика» горит идеей реализовать модуль, худшее, что можно сделать — пойти на поводу у сомнений. В первые же рабочие дни вы узнаете, кто подтверждает опасения, а кто решил их опровергнуть. Так к чему портить отношения на этапе планирования?
Принцип третий. Общие правила оформления
Когда роли в проекте распределены, самое время позаботиться об однообразном оформлении кода. Каждый член команды должен помнить, что его программу могут рассматривать и дорабатывать коллеги, а значит код должен быть понятным и удобным для чтения.
Сразу договоритесь об основных моментах:
- Комментарии. Должны быть короткими и понятными, дополнять код, а не расшифровывать его.
- Стиль. В каждом языке есть свод правил по оформлению кода, но команда может очертить собственные основные принципы — относительно пространства имен, табуляций, формирования модулей.
- Настройки. Организационные моменты, касающиеся выбора общей среды разработки, настроек доступа, подключаемых библиотек и прочего.
Принцип четвертый. Карта вопросов
Когда новички вступают в командную разработку продукта, требующего более высокого уровня подготовки, у них возникает множество вопросов. Выход первый — задавать их напрямую более опытным коллегам. Способ почти идеальный, но далеко не всегда разъяснение бывает оперативным. Второй — искать решение самостоятельно, но помнить, что это может стать «бутылочным горлышком» проекта. И в этом случае надо позаботиться о «карте вопросов»: комментариях в коде или отдельном текстовом файле, адресованных проверяющему. Так все причастные смогут понять, где в проекте потенциальные проблемы.
Принцип пятый. Визуализация
В крупных компаниях не возникает вопросов, зачем визуализировать работу, но в маленьких коллективах лень берет свое. А между тем небольшая презентация, пусть даже в виде блок-схемы, покажет коллективу полноту и качество вашей работы, а проверяющему сэкономит время.
Визуализировать можно не только алгоритм, но и схему кода. Это поможет не только окружающим, но и вам — задачи не будут скакать от строки к строке, а соберутся в блоки.
Принцип шестой. Перекрестный опрос
Когда код написан, надо его проверить. Заниматься этим самому необходимо, но 100% качества это не дает. Поэтому хорошо бы изначально понимать, кто за проверку чьего кода будет отвечать.
В идеале этим должны заниматься наиболее опытные и внимательные участники коллектива. Они же — самые занятые. Поэтому чтобы отфильтровать основные ошибки, лучше выбрать стратегию перекрестной проверки. Это когда два разработчика инспектируют код друг друга.
Выгоды здесь две:
- Меньше времени на адаптацию. Когда взаимодействие ограничено двумя людьми, вы не тратите часы на привыкание к чужому стилю, выяснение задач и способов решения. Изложенные выше принципы командной разработки минимизируют сложности индивидуального подхода, но не устраняют их совсем. Перекрестная проверка — еще один помощник.
- Больше времени для коммуникации. Когда два человека проверяют друг друга, они «на связи» и могут чаще задавать мелкие вопросы, которые в ином случае забылись бы. А успех от провала часто отделяет мелочь.
Принцип седьмой. Время на проверку
Хоть проверять код и необходимо, но нельзя затягивать эту работу. Следуйте правилу: проверка чужого кода не должна занимать более 10% от общей деятельности. Это статистический барьер, который позволяет определить шаг проверок, контролировать выполнение правил и не отставать от общего графика из-за халтуры отдельных коллег.
Собрать команду разработчиков, которые хотят поучаствовать в создании большого проекта, несложно. Куда тяжелее заставить всех двигаться в одном направлении, идти на взаимные уступки. Но имея под рукой этот свод принципов, вы точно найдете ответы на два вечных вопроса: «кто виноват?» и «что делать?».
Комментарии