Что такое “культура разработки?” Само слово культура очень многогранное. В рамках статьи мы поговорим не столько про процесс написания кода, сколько про грамотную работу со вспомогательными инструментами в стремлении сделать итоговый продукт максимально качественным. Мнением на эту тему поделился Александр Шестаков, который рассказал, почему так важна личная заинтересованность каждого сотрудника и какой путь уже проделан компанией в этом направлении.
Документ, описывающий систему квалификаций разработчиков нашей компании, был опубликован довольно давно. Один из пунктов оценки, по которому возникало наибольшее количество вопросов – SDLC. Мы сформулировали его таким образом, чтобы он включал и методологии, применяемые в разработке ПО, и разнообразные утилиты, и инструменты и многое другое.
Как расшифровывается этот пункт? Software Development Life Cycle – жизненный цикл разработки программного обеспечения. Это масштабное понятие, в которое входят и работа с системой управления задачами (issue-трекером), и методология разработки с описанным процессом (к примеру, Git-flow или Github-flow), работа с pull-реквестами, использование Continuous Integration и Continuous Delivery, наличие специальных DevOps-процессов и другое. Мы отразили данный пункт в системе квалификаций, потому что считаем: знание различных практик и методологий, а также умение их применять или даже внедрять непосредственно коррелирует с квалификацией инженера.
Процесс разработки ПО состоит из многих этапов, каждый из которых отнюдь не прост, пусть даже представителям других профессий так и не кажется: “Сиди себе в наушниках, да на кнопочки нажимай…”. Но времена полевых воинов-одиночек прошли – без командной работы кашу из agile-а уже не сварить. Труд команды инженеров требует организации, общение команды с заказчиком само себя не зафасилитирует, да и менеджеру данные для составления отчетов по работникам нужны 😉 Так что не будем лезть в дебри, остановимся на основном – создании программного кода. Речь пойдет о “всеми любимых” pull request-ах, комментариях к коду и других аспектах взаимодействия разработчиков в команде.
Вот какие практики мы рекомендуем использовать на всех проектах – Code Review, непрерывная интеграция (CI), разработка через pull-request-ы (при использовании feature branches). Следование этим методикам позволяет сделать процесс разработки прозрачным, предсказуемым и расширяемым.
Основные проблемы с code review, встречающиеся на проектах, такие:
Процесс code review не внедрен совсем 😉 Не часто, но все же встречается ситуация, когда разработка ведется в одной ветке source control-а (как делали во времена SVN-а). Проведению code review такая модель не очень помогает – изолировать commit-ы по определенной feature или bug-у не удобно, да и организовать схему с требованием approve-ов сложно.
Code review проводит только технический лидер либо обсуждение происходит устно, с глазу на глаз. Причины и оправдания могут быть совершенно разные, однако такой способ проведения code review нельзя назвать эффективным. Code review нужен не только, да и не столько для обеспечения качества кода, но для обучения менее опытных специалистов, обсуждения возможных решений, к тому же это отличный способ обеспечить shared code responsibility.
Процесс review вырождается в проставление approve-ов. История из практики: менеджер был уверен, что в части code review на проекте все отлично, и пообещал клиенту развернутый отчет. На первый взгляд, все было не так и плохо – около 2-х комментариев с замечаниями по коду в cреднем приходилось на каждый из 3 тысяч pull-ов. Но вот на второй взгляд… – комментарии присутствовали лишь в 20 pull request-ах, в остальных – просто approve, approve, approve. Пользы от такого процесса – никакой.
Как выстроить процесс “правильно”? Каждый разработчик работает над своей задачей отдельно от остальных, в feature branch-е (при необходимости синхронизируясь с upstream-ом). По окончании (или в процессе) работы – публикует ее в виде pull request-а. Именно он, автор, следит за тем, чтобы изменения достигли главной ветки, код был доставлен на боевое окружение и правильно работал. Ответственность лежит именно на авторе, а не инженере по качеству или интеграторе. Оправдания в стиле “я все сделал, это они не просмотрели пул” выглядят неуместно. Творение разработчика не достигло финальной стадии? Значит, он не приложил всех необходимых усилий.
Все системы CI без труда можно “подружить” с нашим Bitbucket-ом. Желательно, чтобы в каждый момент времени (на каждом commit-е, ну или хотя-бы на каждом pull request-е) участники проекта видели – завершена ли сборка успешно. Проходят ли все тесты, выявил успешно ли linter поправил форматирование, собрался ли docker образ и т.д. Если нет, то, наверное, неразумно тратить время остальных разработчиков на то, чтобы просматривать код. Но отмечу, что соглашения на конкретных проектах могут отличатся от описанного подхода. Главное, чтобы эти соглашения были 😉
Если в pull request-ах встречается много комментариев по форматированию кода (грамматические ошибки, пробел перед запятой, после слова и другие элементарные вещи) – значит, написавший их потратил свое время зря! Видимо, техлид или технический координатор поленился и не внедрил систему автоматической проверки, которая исправляет такого рода замечания и экономит время команды.
Кроме того, Bitbucket можно довольно гибко настраивать. Обратитесь за помощью к техническому координатору проекта, чтобы сконфигурировать запрет на push в ветки мимо pull request-ов, настроить связку с Jira (не пропустит commit-ы без указания ссылки на задачу), указать reviewer-ов по умолчанию и еще много полезных штук.
Работаете на проекте один, у коллег нет экспертизы в вашей технологии/языке или он(а) письменно “скромничает”? Обратитесь к менеджеру – он обязательно поможет найти reviewer-а “со стороны”. Каждому пригодится дополнительная пара глаз для review. Кстати, Андрей Свиридов сделал отличный доклад о том, насколько важен процесс code review, рекомендую к просмотру.
Хочется пожелать всем отличной и спокойной работы. Не ругайтесь в комментариях и в pull request-ах, не коммитьте туда пароли – и вообще, избавляйтесь от чувства беспокойства 😉. Психологи отмечают, что нервная работа грозит профессиональным выгоранием. А правильно поставленный рабочий процесс – залог того, что разработчики не будут холиварить по мелочам.