Почему квалификация разработчика не гарантирует качество кода

Вот, какая загадка, что под яйцами гладко — вроде бы, нанимаете крутых разработчиков, активно продвигаете позицию, что всё надо делать грамотно, по уму, по современным стандартам, а получаются нестабильные продукты с плохоподдерживаемым кодом. Почему?

Если одной строчкой, то потому что сформирована плохая среда. Давайте разбираться подробно.

Почему виновата среда

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

Разраб может знать, как правильно разрабатывать. Но если у него каждый день:

• Постановки задач в чате, минуя таск-трекер.
• Нет никакого CI/CD, разраб выкатывает на прод со своего компа по FTP.
• На предложение устроить мозговой штурм по архитектуре, он всегда получает ответ, что некогда.
• Концепции архитектуры нет вообще, каждый кодит как хочет.

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

Дедлайны как образ жизни

Почитайте мою статью о нужности дедлайнов, пожалуйста.

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

Но дело в том, что ускорение не происходит от давления. Ускорение происходит от стабильности. Когда команду не дёргают, у неё сформированные процессы, которые не меняются каждые несколько дней, когда у неё спокойная обстановка.

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

Зачем думать, если всё равно откатим?

Проблема возникает, когда члены команды очень чётко осознают, что стараться нет смысла.

• Документация не актуализируется и ей не пользуются. И зачем её писать?
• Зачем писать чисто, если потом всё переписывают?
• Зачем юнит-тесты, если фича важна «вчера»?

Они могут делать качественно, но сформированная вами, менеджментом, среда, напрочь убивает мотивацию. Поэтому они переключатся в режим i do my job. Просто запилить, получить зарплату, а что будет дальше — неважно.

«Сделай быстро» — почти всегда = «сделай плохо»

Очень часто, что в стартапах, что в корпорация, звучит: «Быстро делаем MVP, потом выбрасываем и кодим нормально». Но проблема в том, что не выбрасывают, а возводят на гнилом фундаменте многоэтажное здание.

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

Как сделать «по уму» возможным

Совершенно бесполезно искать особо крутого сеньора, который придёт и порядок наведёт. Надо создавать среду.

• Нормализуйте процессы.
• Дайте стабильность.
• Привлекаете инженеров — слушайте их на полном серьёзе.
• Не жертвуйте качеством в пользу скорости.

И очень важно — если кто-то проявляет инициативу, цените это и всячески поощряйте. Даже если времени нет. Ничего страшного, если релиз задержится на пару недель, зато сделаете нормальный продукт, который можно развивать и поддерживать.

Резюме

Когда не делают по уму, часто виноваты не люди, а среда. Создавайте среду, на то вы и менеджер или тимлид.