Источник: Видео-доклад

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

Mistakes must be forgivable, not enough code - not

А как же качество написанного?

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

A good programmer will produce fault-free code, while bad programmer will produce code that fault-ridden.

Егор же считает, что это мнение неверное.

Есть также мнение насчет и багов в системе. В некоторых книгах баги сравнивают с бомбами замедленного действия. Такое сравнение Егор также считает неверным, потому что оно порождает так называемое Fear Driven Development - разработчики начинают “бояться” допустить ошибку в коде. Этот термин считается негативным, потому что если разработчик боится сделать изменения, то он будет писать как можно меньше кода, а это негативно скажется на скорости разработки продукта в целом.

Fear makes you a worse programmer (c) Julia Evans

К чему ведет страх разработчика:

  • Застоявшиеся ветки - ветки, в которых разработчик долго коммитит изменения и которые в итоге будут переписаны вследствие изменений в мастер-ветке, сделанных после создания застоявшийся ветки.
  • Технический долг. Боимся рефакторить, боимся вносить архитектурные изменения, отсюда и накопление технического долга.
  • Скука. Скучно разрабатывать, если нет возможности экспериментировать в коде. Разработчиков постоянно ругают за сломанный продакшн, за баги в коде, и разработчики перестают экспериментировать в проекте. Хорошие разработчики уходят из таких команд
  • Стресс. Страх не отпускает после 6 часов, в итоге этот стресс сидит в голове вечером, ночью и утром.

Чтобы улучшить качество кода и устранить негативные последствия выше, нужно менять не людей, а процессы:

Fix the Process, not people

Нужно делать так процессы, чтобы почти любой разработчик мог экспериментировать без боязни сломать систему. Нужно построить blame-free среду для разработчиков, чтобы никто не боялся обвинений.

Рекомендации по улучшению кода

1. Reject it!

Стройте процесс пайплайна таким образом, чтобы написанный код встречал на своем пути до продакшна как можно больше препятствий. Нельзя “экономить” силы, вложенные в создание этих самых препятствий. Если код дает хотя бы намек на “некачественность” свою - пайплайн должен его отбросить. Процессы должны быть автоматизированы.

Какие инструменты нам тут полезны. CI/CD, rultor.com

2. Quality Wall

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

На этом этапе контроллируются классы, методы, переменные и т.д. На этом этапе невозможно обнаружить функциональные ошибки. Что нам поможет для построения Quality Wall:

  • Checkstyle tools
  • PMD
  • FindBugs (for Java)
  • Unittests
  • JaCoCo (Coverage controll)
  • Mutation coverage
  • Anti-duplicate check
  • Code-review.

Иными словами, если у нас написан код не по стилю, либо покрытие кода тестами сократилось, то разработчик просто не сможет залить свой код в основную ветку (develop). А тимлид, в свою очередь, сможет “отпустить” на некоторое время проект спокойно, потому что он настроил процессы так, что качество кода проекта не будет падать заметно.

Код-ревью также является одним из пунктов Quality Wall. Причем Егор советует делать ревью в два этапа: сначала peer-review коллегой, а затем ревью от архитектора проекта.

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

3. Testers, not approvers

Многие проекты смотрят на QA-команду как на аппруверов кода, которые и выносят вердикт, что код готов к деплою на продакшн. Егор с этим тоже не согласен. Тестеры должны работать параллельно с разработчиками и ломают систему и репорят баги проектному менеджеру и/или деливери-менеджеру. А уже деливери-менеджер решает на основе имеющихся багов релиза, релизим ли мы продукт или нет.

4. Crash fast

Егор говорит о конечных пользователей как о тестерах нашего продукта. Он поддерживает идею Crash fast - программа при получении некорректных данных должна не только крашиться, но и предоставить конечному юзеру наиболее удобный из всех возможных способов отправить баг-репорт. Тут речь не о показе стэк-трейса, конечно же, но об этом Егор и сам говорит - способа пока нет, и его еще нужно придумать.

5. Encourage bugs

Нужно построить атмосферу в команде разработки так, чтобы и девелоперы, и архитекторы, и тестеры, и вообще любой член команды хотел репортить баги, и чем этих багов больше, тем лучше. Репорт ошибки должен быть позитивным, и каждый должен хотеть сделать это. Тогда и уйдет Fear Driven Development.

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

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

6. Educate Money People

Мы должны убедить заказчика проекта, что все эти проверки и процессы важны для дальнейшего качества. Обычно заказчики соглашаются с этим, однако, по словам Егора, они не могут согласиться с тезисом, что “много багов = хорошо”. Они в это не верят и сомневаются в подходе. Крайне сложно убедить money-people в том, что если вчера было 100 багов, а сегодня уже 200, то это очень хорошо, а не плохо. Что если код упал в продакшене, то виноват не автор кода, а пайплайн и система контроля качества. Егор считает, что…

It’s impossible

А так как это невозможно, то Егор предлагает просто не сообщать им об этом. Это внутренняя кухня разработки, и заказчику не стоит об этом знать. Им стоит сообщать о высокоуровневых багах, число которых должно сокращаться при правильно построенных процессах.