БлогNot. Public Морозов и другие: антипаттерны в программировании

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 [12801 просмотр]


теги: программирование ошибка список софт english

К этой статье пока нет комментариев, Ваш будет первым