Public Морозов и другие: антипаттерны в программировании
Что мы знаем о классификации приёмов "как-не-надо-делать" или анти-паттернов в программировании? Обычно приходит на ум только знаменитый Паблик Морозов:
Антипаттерн Паблик Морозов. Класс-потомок, созданный в соответствии с этим антипаттерном, выдает по запросу все данные класса-предка, независимо от степени их сокрытия./* a.h */ class A { private: int papini_dengi; };/* main.cpp */ #include <iostream> #define private public /**/ #define protected public /**/ #include "a.h" #undef private /**/ #undef protected /**/ int main() { A *a = new A(); std::cout << a->papini_dengi; /*А papini_dengi-то были приватным свойством :) */ system("pause>nul"); return 0; }
На самом деле, таковых можно насчитать гораздо больше, В сущности, вот в этом волшебном списке из англоязычной "Вики" уже всё есть. Но я немного расширю задачу и приведу как поведенческо-организационные анти-шаблоны, так и более-менее "чисто софтовые" термины. Ниже расположен алфавитный список некоторых из них, с добавлениями от себя :)
- Abstraction inversion (Инверсия абстракции): реализованные функции системы, нужные пользователям, не представлены, что вынуждает их реализовывать эти функции заново с помощью функций более высокого уровня
- Action at a distance (Дальнодействие): Неожиданное взаимодействие между далёкими частями системы.
- Analysis paralysis (Аналитик-паралитик): Неоправданное внимание и затраты времени/ресурсов на стадию анализа
- Big ball of mud (Большой комок грязи), Yo-yo problem (Проблема йо-йо), Spaghetti code (Спагетти-код), Индусский код: Структура системы отсутствует или не поддаётся пониманию
- Bystander effect (Эффект наблюдателя): сама постановка задачи неверна, но те, кто это знают, молчат, потому что имеющимися силами всё равно не справимся
- Call super (Позови папочку): Для реализации функциональности методу класса-потомка требуется в обязательном порядке вызывать те же методы класса-предка
- Cargo cult programming (культ Мохнатого Гуру): Использование решений и методик без понимания причин
- Cash cow (Денежная корова): Продукт прибылен и успешен, новые версии делаются через одного место и просто для галочки, как у Мелкософта
- Circular dependency (Кольцо дружбы): взаимосвязь между двумя или более модулями, которые прямо или косвенно зависят друг от друга для правильной работы (взаимно рекурсивны)
- Coding by exception (Клопомор): Добавление нового кода для поддержки каждого специального распознанной ошибки
- Continuous obsolescence (Вечно старый): мы вынуждены только и адаптировать программу к новым версиям чего-то там, тратя на это непомерно много времени
- Copy and paste programming (копипаста) - Копирование или небольшая модификация существующего кода вместо создания общих решений
- Database-as-IPC (база вместо данных): Использование базы данных для обмена сообщениями между процессами там, где можно использовать более легковесные способы
- Death march (Марш смерти): Все знают, что проект обречён, кроме начальника, узнающего об этом последним. Также обычно связано с бесплатной сверхурочной работой для достижения заведомо невозможного результата
- Design by committee (Комитет по разработке): Делали многие, а видение у каждого своё. Результат - отсутствие даже намёка на целостность в продукте
- DLL Hell (библиотечный ад) - Проблемы с совместно используемыми библиотеками
- Error hiding (Концы в воду): Перехват сообщения об ошибке до того, как она показывается пользователю, в следствие чего пользователь не получает сообщения об ошибке или получает бессмысленное сообщение
- Escalation of commitment (Эскалация обязательств): Неспособность отказаться от решения даже тогда, когда его ошибочность доказана
- Feature creep (Футурит): "улучшения, приводящие к чрезмерному усложнению системы в ущерб качеству
- Finnish profanity (Финская матерщина): не знаю, почему не русская... имеется в виду агрессивный, хамский стиль управления
- God object (Блоб): Концентрация слишком большого количества функций в одном классе
- Gold plating (Мартышкин труд): проект давно не приносит прибыли, но работа над ним продолжается; основной отечественный метод работы
- Groupthink (Политбюро): Никто не хочет выдвигать идеи, противоречащие комфортному консенсусу
- Hard coding (Хард-код): встраивания входных или конфигурационных данных непосредственно в исходный код программы или другого исполняемого объекта или фиксированное форматирование данных вместо того, чтобы получать эти данные из внешних источников
- Inner-platform effect (Раздувание платформы): неоправданное усложение системы, попытка излишней универсальности
- Input kludge (Затычка ввода): Отсутствие коректной обработки возможного неверного ввода. Классическое переполнение буфера, например, сюда же
- Knight in shining armor (Рыцарь в сверкающих доспехах): появляется, когда всё сломали и пытается всё починить, не объясняя, как и почему он это сделает
- Lava flow (потоки говн): Сохранение нежелательного (лишнего, низкокачественного) кода по причине того, что его удаление слишком дорого или будет иметь непредсказуемые последствия
- Loop-switch sequence (циклы-переключатели): Кодирование последовательности шагов с помощью цикла и оператора выбора
- Magic number (Волшебное число): константы в коде без пояснений, зачем они
- Magic pushbutton (Волшебная кнопка): Написание бизнес-логики в коде пользовательского интерфейса (например в обработчике события нажатия на кнопку)
- Moral hazard ("Эффективный менеджмент"): Тот, кто принимает решения, не отвечает за их последствия
- Mushroom management (Грибной менеджмент): менеджеры держат тех, кто работает, в темноте и кормят навозом, иначе говоря, сотрудники не имеют достаточно достоверной информации, чтобы произвести нечто осмысленное
- Object orgy (Паблик Морозов): Предоставление неоправданного доступа к внутренним свойствам объекта
- Poltergeist (Полтер Гейтс): Объекты, чьё единственное предназначение — передавать информацию другим объектам.
- Race condition (Гонка событий): Ошибка в определении последовательности различных порядков событий
- Reinventing the wheel (Изобретение велосипеда) - Разработка собственного решения вместо применения существующего
- Scope creep (Уползание горизонта): рамки проекта неограниченно растут
- Single head of knowledge (Единственный знающий человек): жизненный цикл разработки контролирует, по сути, один человек
- Smoke and mirrors (Потёмкинская деревня): Ну, это второй основной отечественный метод работы, тут пояснять нечего
- Softcoding (Мелкомягкий кодинг): другая крайность по отношению к хард-коду, приводящая к тому, что настраивается всё, что угодно, но при этом конфигурирование системы само по себе превращается в программирование
- Software bloat (Пузырящийся софт): каждая новая версия жрёт всё больше ресурсов без явной выгоды для потребителя
- Stovepipe (Дымоход): Информация цикрулирует преимущественно вверх-вниз, но не по горизонтали между смежными подразделениями. Мало что столь же малоэффективно, и не только при разработке софта
- Tester Driven Development (Ошибкоуправляемая разработка): Новые требования к продукту определяются отчетами об ошибках или результатами тестов, а не, например, значением или стоимостью функции
- Vendor lock-in (Блокировка клиента): система слишком зависит от внешней компоненты
26.06.2017, 15:37 [13513 просмотров]