Неявные признаки плохого кода

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

Если Вы нашли один из перечисленных ниже признаков в вашем проекте — это сигнал задуматься об improvement-ах!

Процесс

1. Сложный процесс разработки. Требуется выполнение множества действий, которые не улучшают код или вообще не относятся к коду, или требуется множество одобрений для того, чтобы сделать небольшой незапланированный фикс.
2. Менеджмент думает только о метриках.
3. Не удобная система трекинга задач.
4. Интегрируются фиксы в обход процесса, скрывается размер дельты или риски, чтобы хоть немного улучшить код. (Примечание. Если у вас такой случай, то вам ни в коем случае не стоит думать об «охоте на ведьм», а нужно думать о легализации таких улучшений).
5. Нет стандарта кодирования или его мало кто понимает.
6. Отсутствие инспекций кода. Отсутствие инспекций кода само по себе не так плохо, хуже когда они проводятся не правильно или не обосновано долго. Например, ожидание ~16 дней от какого-нибудь из инспекторов комментария «the change is fine» не может является нормой.
7. На инспекции кода уделяется время не дельте, а недостаткам «окружающего» кода.
8. Отсутствие how-to-шек по наиболее важным моментам процесса, с которыми обычно у всех новичков проблемы.
9. Менеджмент думает только об качественных отчётах от разработчиков по каждой задаче, а не об улучшении качества кода или решении оперативных технических проблем.
10. Непрофессиональный менеджмент или чересчур политизированное управление.

Configuration management

1. Система контроля версий объективно «тормозит» и не удобна. Чтобы заинтегрить фикс или взять последний код тратится больше ~15 минут.
2. Код строится дольше чем ~30 мин с нуля.
3. Важные CM-ные фиксы не заинтегрированы в инфраструктуру и таким образом, чтобы новичок начал работать на проекте ему приходиться вставать на одни и те же грабли, на которые уже вставали все участники команды.
4. Изменения кода в системе контроля версий синхронизируются дольше чем 5 секунд. Т.е. даже после успешного и правильного коммита, заинтересованные лица увидят ваши изменения через большой промежуток времени. (Примечание. В самом худшем случае через сутки.)
5. Разработчики не имеют право интегрировать изменения кода в main/trunk. У разработчиков нет ощущения коллективного владения кодом.
6. Нет политики именования и размещения файлов.
7. Невозможно отследить по какой задаче были сделаны изменения в определённой строке кода.
8. Внедрены средства автогенерации документации из кода, но ими никто не пользуется, не смотря на то, что часть системы уже задокументирована в коде. (Примечание. Разновидность «замусоренного» кода.)
9. Комментарии или revision history хранится в коде, а не в системе контроля версий.

Команда

1. Команда программистов на один компонент/библиотеку/подсистему больше 10-20 человек.
2. Код одного компонента/библиотеки пишется в двух или более офисах, городах, странах.
3. Команды не синхронизированы по знаниям системы. Имеется скрытый код, часть кода намеренно скрыта от одной из групп разработчиков.
4. Команда слишком не опытна или слишком мала. Например, один программист разрабатывает систему для многих заказчиков, при этом в компании не предполагается напарник или какая-либо подмена в случае чего.
5. Чтобы найти электронный адрес или IM эксперта нужно больше трёх кликов.

Требования и UI

1. Раздутые требования. Количество фич в продукте «зашкаливает». Спецификации по 600 стр. (Примечание. Пример из одного практически «умершего» проекта.)
2. Очень сложный UI. Для того, чтобы пользователь смог сделать что-то тривиальное необходимо пройти несколько форм, несколько раз ввести пароль, на каждой форме только по одному полю для ввода, неясные надписи и т.п.
3. Нет единого стиля в UI приложения или есть стиль, но ошибки дизайна видны не вооружённым глазом (плохое выравнивание, размеры не совсем совпадают и т.п.)
4. Некоторая часть фич уже отключена компиляционно или в конфигурационном файле, и вероятность обратного включения таких фич стремится к нулю, но почему-то требования к таким фичам, код и дизайн остаётся в mainline-е.

Архитектура

1. Отсутствие документов по архитектуре. Есть документы, но в них, по сути, только обрывки кода с короткими комментариями.
2. Время от времени кто-то из разработчиков говорит, что документация «отстой» или её не хватает.
3. Архитектура не ясна из кода и документов по дизайну (не смотря на то, что качество комментариев и документов по дизайну приемлемое). Требуются глубокие тренинги по архитектуре системы.
4. Большинство программистов в команде не чувствуют себя удовлетворёнными от работы и открыто «плюются» от работы с кодом.
5. Количество используемых технологий зашкаливает.
6. Необоснованно большой дистрибутив продукта для сравнительно небольшой функциональности.
7. Жутко низкая производительность системы, продолжающаяся несколько версий подряд, в сравнении с конкурентами.

Тестирование

1. Невозможно протестировать всю систему  с текущими ресурсами за два-три дня. (Примечание. Для некоторых систем эта оценка может варьироваться).
2. Отсутствие unit test-ов.
3. Слишком сложные unit test-ы — не ясно, что они проверяют.
4. Не стабильные unit test-ы или постоянные баги в unit test-ах.
5. Низкий или нулевой уровень автоматизации тестирования.
6. Тестеры пишут авто-тесты на каком-нибудь экзотическом малораспространённом языке программирования.

Кодирование

1. Невозможно предсказать последствия изменений в коде.
2. Для написания элементарной функциональности (например, отобразить окно об ошибке) требуется несколько часов.
3. Средняя complexity функций в коде очень большая.
4. Разработчики называют код «спагетти» (горизонтальные или вертикальные) или «обои».
5. (Если применимо) объективно не удобная среда разработки при существующих более функциональных и удобных IDE на рынке.
6. Отсутствие IDE в той области, где её использование давно является mainstream-ом.

Отладка

1. Сложная отладка, чтобы зафиксить относительно простую багу нужно потратить нескольких часов или больше.
2. Нет способов для отладки: нет логирования, нельзя использовать отладчик, код прошивается только один раз, USB слишком медленно работает для логирования и т.п.
3. Код прошивается больше ~5 мин. (Примечание. Актуально для встроенной разработки.)
4. Повсеместное использование printf/fprintf вместо нормального реюзабельного конфигурабельного логирования;
5. Если логирование только один возможный путь для отладки, отсутствие каких либо тулов (или планов по разработке тулов) для парсирования логов.
6. Нет тулов для профилирования кода.
7. Нет тулов для поиска memory leak-ов.
8. Нет тулов для анализа паник (crash).
9. Сложная отладка на целевой платформе, но код спортировать на Windows/Linux практически не возможно чтобы нормально отладиться. (Примечание. Применимо в основном для встроенной разработки.)
10. Никто никогда не думал о симуляторах, эмуляторах, HW отладчиках, чтобы облегчить отладку на  начальных этапах  вместо работы на не стабильном железе. (Примечание. Применимо в основном для встроенной разработки.)
11. Чтобы отладить панику (crash) необходимо долгое время скачивать вспомогательные тулы или файлы. (Примечание. Любой софт содержит баги и вероятность, что бага будет паникой не намного меньше…, разработчикам часто необходимо отлаживать паники.)

В будущих постах автор планирует раскрыть некоторые из признаков более детально.