Ниже список неявных признаков плохого кода, который в контексте данного поста стоит воспринимать как эмпирические знания автора.
Если Вы нашли один из перечисленных ниже признаков в вашем проекте — это сигнал задуматься об improvement-ах!
Процесс
- Сложный процесс разработки. Требуется выполнение множества действий, которые не улучшают код или вообще не относятся к коду, или требуется множество одобрений для того, чтобы сделать небольшой незапланированный фикс.
- Менеджмент думает только о метриках.
- Не удобная система трекинга задач.
- Интегрируются фиксы в обход процесса, скрывается размер дельты или риски, чтобы хоть немного улучшить код. (Примечание. Если у вас такой случай, то вам ни в коем случае не стоит думать об «охоте на ведьм», а нужно думать о легализации таких улучшений).
- Нет стандарта кодирования или его мало кто понимает.
- Отсутствие инспекций кода. Отсутствие инспекций кода само по себе не так плохо, хуже когда они проводятся не правильно или не обосновано долго. Например, ожидание ~16 дней от какого-нибудь из инспекторов комментария «the change is fine» не может является нормой.
- На инспекции кода уделяется время не дельте, а недостаткам «окружающего» кода.
- Отсутствие how-to-шек по наиболее важным моментам процесса, с которыми обычно у всех новичков проблемы.
- Менеджмент думает только об качественных отчётах от разработчиков по каждой задаче, а не об улучшении качества кода или решении оперативных технических проблем.
- Непрофессиональный менеджмент или чересчур политизированное управление.
Configuration management
- Система контроля версий объективно «тормозит» и не удобна. Чтобы заинтегрить фикс или взять последний код тратится больше ~15 минут.
- Код строится дольше чем ~30 мин с нуля.
- Важные CM-ные фиксы не заинтегрированы в инфраструктуру и таким образом, чтобы новичок начал работать на проекте ему приходиться вставать на одни и те же грабли, на которые уже вставали все участники команды.
- Изменения кода в системе контроля версий синхронизируются дольше чем 5 секунд. Т.е. даже после успешного и правильного коммита, заинтересованные лица увидят ваши изменения через большой промежуток времени. (Примечание. В самом худшем случае через сутки.)
- Разработчики не имеют право интегрировать изменения кода в main/trunk. У разработчиков нет ощущения коллективного владения кодом.
- Нет политики именования и размещения файлов.
- Невозможно отследить по какой задаче были сделаны изменения в определённой строке кода.
- Внедрены средства автогенерации документации из кода, но ими никто не пользуется, не смотря на то, что часть системы уже задокументирована в коде. (Примечание. Разновидность «замусоренного» кода.)
- Комментарии или revision history хранится в коде, а не в системе контроля версий.
Команда
- Команда программистов на один компонент/библиотеку/подсистему больше 10-20 человек.
- Код одного компонента/библиотеки пишется в двух или более офисах, городах, странах.
- Команды не синхронизированы по знаниям системы. Имеется скрытый код, часть кода намеренно скрыта от одной из групп разработчиков.
- Команда слишком не опытна или слишком мала. Например, один программист разрабатывает систему для многих заказчиков, при этом в компании не предполагается напарник или какая-либо подмена в случае чего.
- Чтобы найти электронный адрес или IM эксперта нужно больше трёх кликов.
Требования и UI
- Раздутые требования. Количество фич в продукте «зашкаливает». Спецификации по 600 стр. (Примечание. Пример из одного практически «умершего» проекта.)
- Очень сложный UI. Для того, чтобы пользователь смог сделать что-то тривиальное необходимо пройти несколько форм, несколько раз ввести пароль, на каждой форме только по одному полю для ввода, неясные надписи и т.п.
- Нет единого стиля в UI приложения или есть стиль, но ошибки дизайна видны не вооружённым глазом (плохое выравнивание, размеры не совсем совпадают и т.п.)
- Некоторая часть фич уже отключена компиляционно или в конфигурационном файле, и вероятность обратного включения таких фич стремится к нулю, но почему-то требования к таким фичам, код и дизайн остаётся в mainline-е.
Архитектура
- Отсутствие документов по архитектуре. Есть документы, но в них, по сути, только обрывки кода с короткими комментариями.
- Время от времени кто-то из разработчиков говорит, что документация «отстой» или её не хватает.
- Архитектура не ясна из кода и документов по дизайну (не смотря на то, что качество комментариев и документов по дизайну приемлемое). Требуются глубокие тренинги по архитектуре системы.
- Большинство программистов в команде не чувствуют себя удовлетворёнными от работы и открыто «плюются» от работы с кодом.
- Количество используемых технологий зашкаливает.
- Необоснованно большой дистрибутив продукта для сравнительно небольшой функциональности.
- Жутко низкая производительность системы, продолжающаяся несколько версий подряд, в сравнении с конкурентами.
Тестирование
- Невозможно протестировать всю систему с текущими ресурсами за два-три дня. (Примечание. Для некоторых систем эта оценка может варьироваться).
- Отсутствие unit test-ов.
- Слишком сложные unit test-ы — не ясно, что они проверяют.
- Не стабильные unit test-ы или постоянные баги в unit test-ах.
- Низкий или нулевой уровень автоматизации тестирования.
- Тестеры пишут авто-тесты на каком-нибудь экзотическом малораспространённом языке программирования.
Кодирование
- Невозможно предсказать последствия изменений в коде.
- Для написания элементарной функциональности (например, отобразить окно об ошибке) требуется несколько часов.
- Средняя complexity функций в коде очень большая.
- Разработчики называют код «спагетти» (горизонтальные или вертикальные) или «обои».
- (Если применимо) объективно не удобная среда разработки при существующих более функциональных и удобных IDE на рынке.
- Отсутствие IDE в той области, где её использование давно является mainstream-ом.
Отладка
- Сложная отладка, чтобы зафиксить относительно простую багу нужно потратить нескольких часов или больше.
- Нет способов для отладки: нет логирования, нельзя использовать отладчик, код прошивается только один раз, USB слишком медленно работает для логирования и т.п.
- Код прошивается больше ~5 мин. (Примечание. Актуально для встроенной разработки.)
- Повсеместное использование printf/fprintf вместо нормального реюзабельного конфигурабельного логирования;
- Если логирование только один возможный путь для отладки, отсутствие каких либо тулов (или планов по разработке тулов) для парсирования логов.
- Нет тулов для профилирования кода.
- Нет тулов для поиска memory leak-ов.
- Нет тулов для анализа паник (crash).
- Сложная отладка на целевой платформе, но код спортировать на Windows/Linux практически не возможно чтобы нормально отладиться. (Примечание. Применимо в основном для встроенной разработки.)
- Никто никогда не думал о симуляторах, эмуляторах, HW отладчиках, чтобы облегчить отладку на начальных этапах вместо работы на не стабильном железе. (Примечание. Применимо в основном для встроенной разработки.)
- Чтобы отладить панику (crash) необходимо долгое время скачивать вспомогательные тулы или файлы. (Примечание. Любой софт содержит баги и вероятность, что бага будет паникой не намного меньше…, разработчикам часто необходимо отлаживать паники.)
В будущих постах автор планирует раскрыть некоторые из признаков более детально.
читать первоисточники тут http://ru.wikipedia.org/wiki/%D0%90%D0%BD%D1%82%D0%B8%D0%BF%D0%B0%D1%82%D1%82%D0%B5%D1%80%D0%BD
или тут http://en.wikipedia.org/wiki/Anti-pattern
Мой материал оригинален и не основан на материалах по указанной ссылке. Это можно увидеть, посмотрев, что большинство признаков уникальны, хотя и есть некоторые не намеренные пересечения. О существовании анти-паттернов я знал, но вещи, о которых я пишу являются моим личным опытом («…в контексте данного поста стоит воспринимать как эмпирические знания автора.»), а не перепечаткой каких-либо тем из каких-либо источников.
а… ну да.
я видимо где-то пропустил уникальность и оригинальность.
извини, буду внимательней.
Алексей, материал хороший :)
А где внедрение и поддержка?