Как построить работу над кодом

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

Чтобы всем было удобно его писать, обсуждать и рефакторить — без распухшего бэклога и лица девопса.

Мне кажется, что если спросить 10 случайных разработчиков о том, как у них в командах устроена работа над кодом, то в 9 случаев ответ будет «Ну, как придётся. Как привыкли!».

Это удивительно для отрасли, в которой есть настоящий культ менеджерских практик: по ним пишут книги, проводят конференции, им учат. Но редко когда учат практикам хорошей работы над кодом! В крайнем случае в команде найдется опытный лид или человек с хорошим системным мышлением, который при этом готов и помочь коллегам стать лучше.

Напомню вам базовые правила, с которых нужно начинать работу в этом направлении. Побуду вашим системным лидом на полчаса, так сказать!

Задайте стандарты

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

Если мы говорим о JS, то пример отлично оформленного и исчерпывающего стандарта можно подсмотреть у Google. Также неплохо разработан стандарт у Airbnb.

Доступные всем стандарты облегчают выявление проблем с качеством кода — и очень помогают во время код-ревью.

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

Любите код-ревью

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

Многие инженерные команды используют принцип DoD (Definition of Done) — такой контрольный список выполненного перед тем, как код можно отдавать в продакшен.

Например:

  • Пройдены юнит-тесты

  • Пройдены интеграционные тесты

  • Все некритичные ишью внесены в техдолг.

  • Критичная бизнес-логика задокументирована в комментариях.

  • Код соответствует стандартам команды

Вот несколько инструментов, которые помогут в ревью:

  • Husky для нативных гит-хуков. Husky можно дополнить ESLint и Prettier — для поддержания кода по красоте и по стилю.

  • Snyk Code — для статического анализа кода, чтобы найти различные типы ошибок. 

Если у вас в команде нет регулярного код-ревью, то вам будет очень трудно писать масштабируемый, эффективный и поддерживаемый код.

Спринтуйте долг 

Наша задача — не давать технологу разрастаться.

Советую выделить примерно 20% ресурсов в каждом спринте на исправление технического долга. Кроме того, регулярно проводите спринт, посвященный устранению технического долга — целиком.

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

Расставляйте приоритеты

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

К примеру, в JIRA нельзя связать проблемы пользователей с кодом и эффективно работать с техническим долгом. Можно подключить внешний трекер, например Stepsize — он позволяет управлять проблемами прямо из среды разработки. 

Следите за метриками

В некоторых командах принято следить за метриками качества кода. Есть даже целая академическая статья о том, как они устроены.

Например, полезно считать число комментов на 1000 строк кода — это даст общее представление о сложности. Если последовательно следить за метрикой, то можно увидеть изменение сложности, что бывает полезно для техлида или техдира.

Также есть понятие связности кода (Code Cohesion). Этой метрикой измеряют насколько хорошо структурирована и организована кодовая база. Это неудивительно, ведь высокоорганизованную кодовую базу легче понимать, поддерживать и улучшать.

И бонус-трек

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

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

Источник: https://habr.com/ru/articles/793220/


Интересные статьи

Интересные статьи

Блокчейн — децентрализованная база данных, хранящая информацию о всех операциях в виде цепи блоков. Особенностью сети является то, что записи находятся не на одном сервере, а на сотнях, из-за чего нез...
В любой автоматизированной системе есть вероятность того, что операция закончится ошибкой. Многие ошибки обрабатываются автоматически, но, в случае с телефонией, вероятность отказа по независящим обст...
В Альфа-Банке мы уже больше 5 лет ведём документацию рядом с кодом. Но она используется не для всех проектных документов. Дело в том, что документация у нас делится по слоям: фронт, миддл и бэкенд. Ес...
Привет, Хабр!Меня зовут Николай, и я тестировщик («Привет, Николай!»,- кричат участники собрания анонимных тестировщиков). Как и многие другие обитатели Хабра состою в нескольких тематических чатах и...
Одна из вещей, которая связывает людей с работой их мечты — это резюме. Множество эйчаров смотрят на разные резюме каждый день. Если вы просмотрите хотя бы 10-40 резюме, то поймете, почему рекрутеры л...