Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Чтобы всем было удобно его писать, обсуждать и рефакторить — без распухшего бэклога и лица девопса.
Мне кажется, что если спросить 10 случайных разработчиков о том, как у них в командах устроена работа над кодом, то в 9 случаев ответ будет «Ну, как придётся. Как привыкли!».
Это удивительно для отрасли, в которой есть настоящий культ менеджерских практик: по ним пишут книги, проводят конференции, им учат. Но редко когда учат практикам хорошей работы над кодом! В крайнем случае в команде найдется опытный лид или человек с хорошим системным мышлением, который при этом готов и помочь коллегам стать лучше.
Напомню вам базовые правила, с которых нужно начинать работу в этом направлении. Побуду вашим системным лидом на полчаса, так сказать!
Задайте стандарты
Стандарты работы над кодом и принципы его оформления должны быть легко доступны для каждого участника команды. Полезно провести небольшой семинарчик внутри и разобрать, какие стандарты бывают.
Если мы говорим о JS, то пример отлично оформленного и исчерпывающего стандарта можно подсмотреть у Google. Также неплохо разработан стандарт у Airbnb.
Доступные всем стандарты облегчают выявление проблем с качеством кода — и очень помогают во время код-ревью.
Но не переусердствуйте с руководствами! Достаточно установить строгие правила именования, интервалов и отступов, чтобы улучшить читабельность. Не нужно регулировать каждую строчку кода. Всегда и везде больше правил — это меньше скорости в разработке.
Любите код-ревью
Код-ревью — это не только способ исправить ошибки и сделать код лучше, это еще и возможность получить знания о разных областях вашей кодовой базы. И способ пополнять и улучшать стандарты, само собой.
Многие инженерные команды используют принцип DoD (Definition of Done) — такой контрольный список выполненного перед тем, как код можно отдавать в продакшен.
Например:
Пройдены юнит-тесты
Пройдены интеграционные тесты
Все некритичные ишью внесены в техдолг.
Критичная бизнес-логика задокументирована в комментариях.
Код соответствует стандартам команды
Вот несколько инструментов, которые помогут в ревью:
Husky для нативных гит-хуков. Husky можно дополнить ESLint и Prettier — для поддержания кода по красоте и по стилю.
Snyk Code — для статического анализа кода, чтобы найти различные типы ошибок.
Если у вас в команде нет регулярного код-ревью, то вам будет очень трудно писать масштабируемый, эффективный и поддерживаемый код.
Спринтуйте долг
Наша задача — не давать технологу разрастаться.
Советую выделить примерно 20% ресурсов в каждом спринте на исправление технического долга. Кроме того, регулярно проводите спринт, посвященный устранению технического долга — целиком.
Ну а вообще есть разные стратегии работы с техдолгом, это достойно отдельной статьи. К примеру, есть стратегия «контролируемой расширяемости» за счёт низкоприоритетных ишью.
Расставляйте приоритеты
В компаниях часто сегментируют ошибки и обращения пользователей по приоритетам, чтобы в первую очередь чинить самое важное. Но с кодом это сделать сложнее.
К примеру, в JIRA нельзя связать проблемы пользователей с кодом и эффективно работать с техническим долгом. Можно подключить внешний трекер, например Stepsize — он позволяет управлять проблемами прямо из среды разработки.
Следите за метриками
В некоторых командах принято следить за метриками качества кода. Есть даже целая академическая статья о том, как они устроены.
Например, полезно считать число комментов на 1000 строк кода — это даст общее представление о сложности. Если последовательно следить за метрикой, то можно увидеть изменение сложности, что бывает полезно для техлида или техдира.
Также есть понятие связности кода (Code Cohesion). Этой метрикой измеряют насколько хорошо структурирована и организована кодовая база. Это неудивительно, ведь высокоорганизованную кодовую базу легче понимать, поддерживать и улучшать.
И бонус-трек
По моему опыту, ничто не улучшает код лучше постоянного внутреннего обсуждения, такого коллективного код-ревью. Я советую проводить их не реже 1 раза в месяц. В некоторых командах это называют «прожаркой».
Попросите каждого собрать по несколько примеров (хорошего и плохого), соберитесь в неформальной обстановке, можно с пивом и пиццей (лучше без ананасов). Описанные стандарты, дружественная атмосфера и терпимость к ошибкам — это лучшее, что вы сможете сделать для кода, коллег и компании.
