Мы что — опять не можем выкатить фичу в срок? Что значит баги? Почему ещë всë не пофиксили? За что вы вообще зарплату получаете?!

Менеджер продолжает ругаться, а вы с тоской вспоминаете момент, когда всë начиналось…

Год назад были грандиозные планы и вырисовывалась стройная архитектура проекта. Но с момента релиза разработка странным образом свернула не туда.

В попытках всë успеть качество кода постепенно покатилось под откос, несмотря на лучшие стремления и титанические усилия.

Где же была ошибка? Где мы просчитались?


Делюсь 5 рецептами, которые гарантированно повысят шансы на выживание кодовой базы вашего проекта.

Остальное лежит за пределами ответственности команды разработки, поэтому здесь не рассматривается.

Никакой теории на этот раз! Только практика.

1. Настройте в проекте CI/CD.

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

2. Настройте автоматизированные тесты, включите их в CI.

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

Если тесты не выполняются, они бесполезны. Поэтому они должны выполняться всегда — в CI самое подходящее место. Вам даже не нужно будет запускать их самому.

Деплой не должен выполняться, если не прошли тесты. Настройте такое условие.

3. Введите практику Code Review.

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

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

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

4. Используйте то, что знаете.

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

Сэкономите время на изучение нюансов и избежите подводных камней.

Новые технологии и практики это круто, но изучать их лучше отдельно на учебных проектах — без риска.

5. Выявите важные и проблемные места и сосредоточьтесь на них.

Не весь код одинаково важен. Но есть тот код, без которого бизнес не может работать.

Поэтому необходимо расставить приоритеты. Выделите 10% действительно важного кода, отрефакторите его и покройте тестами и получите 90% результата.

В первую очередь приведите в порядок код который приносит пользу клиенту.

Во вторую очередь — тот код, который часто ломается.

Всë остальное может и подождать.