День 2531. #ЗаметкиНаПолях
Технический Долг — Миф, Созданный Плохими Менеджерами. Продолжение
Начало
Продолжение

Неприятная правда: иногда дело действительно в плохой работе
Будем честны: иногда код действительно просто плохой, и это не вина руководства. Иногда вы нанимаете разработчика, который:
- Не понимает язык или фреймворк, который использует;
- Копирует ответы ИИ, не понимая их;
- Пишет кучу вложенных if;
- Создает «божественные» классы, потому что «проще хранить всё в одном месте»;
- Отказывается учиться или развиваться, потому что «я всегда так делал»…
А иногда ваш процесс проверки кода настолько несовершенен, что всё это попадает в прод.

Формальные ревью кода
Вы знаете, как это бывает. Кто-то открывает пул-реквест в 16:45 в пятницу. Там 847 строк изменений в 23 файлах. Рецензент бегло просматривает код, не видит очевидных ошибок и нажимает «Одобрить» и уходит на выходные.
Или ещё хуже, есть сеньор, который агрессивно воспринимает критику, и все боятся давать реальную обратную связь, т.к. когда-то кто-то предложил ему рефакторинг, и получил эссе на 2000 слов о том, почему он не прав, а затем три недели пассивно-агрессивной переписки.

У команды нет стандартов
Некоторые команды действительно не имеют стандартов кодирования, руководства по стилю, архитектурных принципов или согласованных шаблонов. Каждый просто делает то, что ему кажется правильным в данный момент.
Один пишет функциональный код с неизменяемыми структурами данных. Другой - ООП с сильным наследованием. Третий просто хочет выпустить продукт и ему на всё пофиг. Результат? Кодовая база Франкенштейна, где каждый модуль кажется написанным другой компанией.

Джун без присмотра
Встречается чаще, чем нам хотелось бы признать: вы нанимаете джуна, даёте ему задачу, и… никто не проверяет, как он справляется. Он две недели мучается, в конце концов, методом проб и ошибок добивается работоспособности и выпускает продукт. Продукт (в принципе) работает, поэтому запускается в прод.
Шесть месяцев спустя кому-то приходится модифицировать этот код, и – внезапно - всё держится на честном слове и молитвах. Никаких тестов или обработки ошибок, переменные temp1, temp2, бизнес-логика смешана с UI-кодом и запросами к БД.
Это технический долг или вина руководства? Руководство не обеспечило наставничество и контроль. Но и инженер мог попросить о помощи, посмотреть на существующий код на предмет шаблонов и т.п.

Тут и начинаются сложности. Потому что даже когда код действительно плох из-за инженерных ошибок, формулировка «технический долг» всё равно неверна, т.к. отнесение этого к «долгу» всё равно:
- Представляет это как преднамеренный компромисс (чего не было);
- Подразумевает, что долг нужно «вернуть» (это нужно исправить);
- Маскирует первопричину (проблемы с наймом, обучением, проверкой кода или стандартами).
Если вы наняли кого-то недостаточно хорошего, это проблема с наймом. Если код-ревью не выявляют проблемы - проблема с процессом. Если у команды нет стандартов - проблема с руководством. Если джуны выпускают неподдерживаемый код - проблема с наставничеством.

Ничто из этого не является «долгом». Это организационные сбои, которые проявляются как проблемы с качеством кода. И даже эти неудачи часто сводятся к решениям руководства. Кто-то решил:
- Нанять дешёвых разработчиков вместо лучших;
- Пропустить техническую часть собеседования, потому что кандидат «казался умным»;
- Не выделить время старших инженеров на проверку кода и наставничество;
- Не инвестировать в установление командных стандартов или архитектурных принципов;
- Приоритет отдавать баллам истории, а не качеству кода.
Мы постоянно возвращаемся к проблемам с руководством.

Окончание следует…

Источник: https://dev.to/adamthedeveloper/technical-debt-is-a-myth-created-by-bad-managers-2l3k