Существует огромное количество антипаттернов – подходов к решению класса часто встречающихся проблем, являющихся неэффективными, рискованными или непродуктивными. Может сложиться впечатление, что антипаттернов больше, чем паттернов. Глобально их можно разделить на 3 группы:
- Антипаттерны проектирования.
- Антипаттерны разработки.
- Антипаттерны управления.
Эти антипаттерны связаны с архитектурными проблемами. Как правило, к ними приводят ошибки проектирования, неверные решения принятые в процессе работы над архитектурой проекта. Глобально наличие антипаттернов проектирования выражается в запутанной структуре и нарушенной взаимосвязи между компонентами программы.
- Golden Hammer – применение одного решения (чаще всего какого-либо одного шаблона проектирования) для всех задач. В перспективе приводит к осложнению поддержки и добавления нового функционала. Возможное решение – тщательное продумывание и взвешенный выбор архитектурных решений.
- Большой ком грязи – как бесструктурный набор компонентов и связей между ними. Усложняет понимание и развитие проекта. Возможное решение – анализ и последующий рефакторинг.
- Полтергейст — класс, не несущий пользы, который используется для вызова методов другого класса или просто добавляет ненужный слой абстракции.
- Interface bloat — слишком сильно "раздутый" интерфейс, то есть определяющий слишком много функций, имплементация которых превращается в отдельную проблему. Приводит к неповоротливости системы, трудностями в сопровождении. Решение – избегание сложных интерфейсов.
Эти антипаттерны связаны с решениями, которые принимают разработчики при реализации конкретного функционала.
- Copy-Paste программирование – копирование кода из одного файла/проекта в другой. В долгосрочной перспективе ухудшает качество и усложняет поддержку кода. В качестве решения можно провести рефакторинг и вынести подобный код в отдельные модули/библиотеки.
- Спагетти-код – слабо структурированная и плохо спроектированная система, запутанная и очень сложная для понимания. Проявляется в виде реализации метода или функции, содержащей огромный блок кода. Усложняет переиспользование и поддержку кода. Оптимальное решение – рефакторинг и разделение на отдельные компоненты.
- Магическое число – использование в коде хард-кода чисел, значение которых неочевидно. Затрудняет понимание кода. Возможное решение – рефакторинг и внедрение практик Code Review для недопущения подобных проблем.
- Хард-код — фиксация в коде различных данных об окружении. Потенциальная проблема — код будет работать только в окружении, в котором ведется разработка. Оптимальное решение — полный запрет на хард-код в рамках разработки проекта и внедрение практики Code Review для дополнительного контроля.
- Софт-код — оборотная сторона хард-кода — вынесение всех возможных настроек во внешнюю конфигурацию, усложняющее настройку и развертывание проекта. Возможное решение — соблюдение принципов KISS, YAGNI.
- Boat anchor — сохранение неиспользуемых частей кода, оставшихся после оптимизации или рефакторинга. Затрудняет понимание исходного кода проекта. Решение – удаление неиспользуемого кода при рефакторинге или вынесение в отдельные архивные ветки.
- Изобретение велосипеда – реализация собственного решения для задачи с нуля, для которой уже существуют решения хорошие отлаженные инструменты. Приводит к потере эффективности конечного продукта. Оптимальное решение – использование проверенных временем инструментов.
- Lava flow — сохранение низкокачественного кода по причине того, что его удаление слишком дорого или будет иметь непредсказуемые последствия. Замедляет развитие проекта, затрудняет рефакторинг. Решение — внедрение практики Code Review и тщательное проектирование перед разработкой.
- Аналитический паралич – неоправданно большие затраты на анализ и проектирование. Часто приводит к закрытию проекта до начала его реализации. Возможное решение – декомпозиция итераций по проектированию и анализу.
- Раздутый улучшизм (Creeping featurism) - добавление новых улучшений в ущерб суммарному качеству программы.
- Раздутый элегантизм (Creeping elegance) - непропорциональное улучшение красивости кода в ущерб функциональности и качеству системы.
- Неуёмная преданность (Escalation of commitment) - продолжение реализации решения после того, как доказана его ошибочность.
- Я тебе это говорил (I told you so) - игнорирование мнения профессионала.
- Управление основанное на числах (Management by numbers) - излишнее внимание к численным показателям, имеющим не очень важное значение.
- Единственный знающий человек (Single head of knowledge, SHOK) - важными сведениями или навыками обладает один человек в проекте, уход которого негативно сказывается на проекте.
Помимо общих антипаттернов управления программными продуктами, open source решения имеют определенные особенности, например, модели управления:
- BDFL: (Benevolent dictator for life) - “пожизненный доброжелательный диктатор”. При такой структуре один человек (обычно первоначальный автор проекта) имеет право окончательного голоса при принятии всех основных решений по проекту.
- Меритократия - при меритократии активным участникам проекта (тем, кто демонстрирует “заслуги”) отводится формальная роль в принятии решений. У каждой модели есть свои преимущества и компромиссы.
- Либеральный вклад - согласно модели либерального вклада, наиболее влиятельными признаются люди, которые делают больше всего работы, но это основано на текущей работе, а не на историческом вкладе.
У каждой модели есть свои преимущества и компромиссы, однако отсутствие четко определенной модели управления рано или поздно начнет негативно сказываться на проекте.
Фиксация модели позволяет потенциальным контрибьюторам понять, как им стоит взаимодействовать с проектом, чего от них ожидают и какова гарантия того, что их вклад будет всегда им доступен. В дополнение к этому, модель описывает процесс контроля качества, который поможет пользователям увериться в жизнеспособности проекта. Разработка и внедрение с чёткой и лаконичной модели управления — один из важнейших шагов, которые проект может предпринять на пути к устойчивому развитию через открытую разработку.