Анти-паттерн

Пример активного применения анти-паттернов в проекте.

Анти-паттерн (от англ. anti-pattern; он же ловушка, англ. pitfall) — это то, как поступать не надо, но как всё равно все, всегда и повсюду поступают. Сколько ни предупреждают. Потому как дедлайны. Потому как бизнес. Потому как долбоёбы.

Термин пришел из информатики, из книги «Банда четырёх» Шаблоны проектирования, которая заложила примеры практики хорошего программирования. Авторы назвали эти хорошие методы «шаблонами (паттернами) проектирования», а антиподами им и являются, соответственно, «анти-паттерны». В принципе, анти-паттерны применимы не только в ИТ, но и в любой другой области человеческой деятельности. Более полный список анти-паттернов есть на Википедии.

Перед спискотой желательно сделать несколько ремарок.

Эхад. Крайне мало где говорится прямо, все более вскользь и между строк, но сами антипаттерны имеют ограниченные области своего определения. Точка. То, что для проекта пользовательской программы есть грех, страх, беда и яма, то для той же прошивки на платке — норма и оптимальный код. А равно как и для высоконагруженной серверной части на hi-end серверах. И наоборот. Где-то антипаттерны разных областей могут пересекаться, но таких примеров немного и они больше смещены из собственно кодирования и проектирования в сторону менеджмента. Удовый менеджмент может похоронить все, но, несмотря на это, почему-то по умолчанию виноваты всегда линейные программисты.

Штайм. Так же необходимо всегда делать поправку на здравый смысл — везде почему-то даётся максимально обтекаемое определение каждого антипаттерна. К примеру, является ли жёстким код на собираемом на туевой хуче систем фреймворке Qt, если в нем при выполнении априорно предположено существование стандартной папки окон «C:\Windows\System32» или переменной окружения %windir%? А если на нём же, но задействованы модули для поддержки работы с серверами СОМ+? Или является ли жёстким код, требующий систему не ниже Windows 10? Является ли мягким кодом код, у которого настройки хранятся в полноценном json? А если в виде списка вида «объект_браузера.поле.переменная = значение» во вполне выполняемом файле js-скрипта? А еслив виде полноценных скриптов с операторами и вычислениями на лиспе?

Шалош. Все эти «домашние» утилиты, локалхостовые скрипты и внутренний homebrew-софт внутри отдела/компании следует всегда выносить за скобки. А равно как и все эти быстрые и грязные proof-of-concept’ы и «набросал прототип на питоне». Ровно до того момента, как они выросли в нечто бОльшее, чем просто дёргалка трёх утилит в цикле по трубе с вызовом пары библиотечных функций из самописного бинарника на компе у админа. Для них антипаттернов не существует, как и они — для антипаттернов: обвинять скрипт, в том что в нем зашит статичный путь — все равно, что обвинять человека в том, что его домашняя майка-алкоголичка, в которой он сидит один дома — растянута и в пятнах.

Анти-паттерны программирования

• Жёсткий код, от англ. hard code — про него ещё говорят «прибито гвоздями». Код настолько привязан к конкретной аппаратной конфигурации и/или системному окружению, что оторвать его для переноса в другое место можно только гвоздодёром. Справедливости ради стоит отметить, что этот подобный стиль разработки во многих случаях используется осознанно и оправданно.
  • Особо запущенный код может работать только на той машине, на которой написан и испытан, и не может на всех остальных — даже если там такая же операционная система, те же драйверы, интерпретаторы кода, и так далее, что и на исходной.
  • Собственно антипаттерном быть оно перестаёт, если:
    • это разработка под плату с очень ограниченными ресурсами. Если программа спекается с ядром RTОS на уровне исходного С’шного кода, становясь лишь его модулем, то не использовать исключающие перенос откомпилированного двоичного образа оптимизации под конкретную плату могут лишь имбецилы. И лишь открытые олигофрены будут за это катить бочку на программистов.
    • у клиента статичное, жёстко регламентированное людьми свыше окружение и оно кардинально меняться не планирует — у военных, например. Зачем тогда нужны повышающие вероятность ошибок и жрущие ресурсы слои прослоек и абстракций, если мы загодя знаем, что требуемый файл будет ВСЕГДА лежать в /var/mnt/komrade/ , а список устройств, которые вообще в принципе воткнут в систему известен заранее?
    • это писано под давно заброшенный разработчиком софт и гораздо проще сделать эталонный образ системы с vhdx/vdi, грузимый в виртуалке, чем, собственно подгонять работу под «средний компьютер по больнице». Что это может быть? Да много чего, на самом деле, но в основном это узко заточенный профессиональный и академический софт. Главное, что в нем полно уникальных фич, которые никому более не нужны и которые просто так за вечер силами студентов не перепишешь под стильно-модно-молодёжную современную систему. А потому нет вообще никакого смысла писать glue- и companion-код иначе.
• Мягкий код, от англ. soft code — почти то же, что мягкий стул, или, техническим языком, код, конфигурируемый настолько гибко (и запутано), что хочется, чтобы лучше уж это был hard code. Возникает вследствие выноса в файлы конфигурации программной логики, что в разумных количествах, к слову, бывает иногда оправданно.
  • Предельный случай мягкого кода — это когда файлы конфигурации сами по себе являются скриптами на том или ином языке — типа Lua или встроенных движков js/lisp.
• Магические константы — общий случай зашитых в программный код значений.
  • Магические числа, от англ. magic numbers — то, на чём нередко строится hard code. Всяческие константы в программе без пояснения их физического (или любого иного) смысла. Как правило, при изменении магического числа или его удалении код магически перестаёт работать вовсе. Типичные примеры — 17 и 54.
    • Впрочем иногда без них не обойтись: тот же быстрый обратный корень — альтернативные расчёты слишком уж медленные, причём требуют дорогих по тактам операций. Ну или работа с битовой маской aka упакованным массивом булевых флагов — куда как быстрее сделать что-то вроде x & 42 , чем в цикле перебирать каждый бит слова, допустим, состояния. В «обычном» коде это в принципе некритично, но для чего ниже уровнем — уже важно.
  • Магические строки, от англ. magic strings — как магические числа, но только это строки. Обычно это бывают пути к файлам, но в принципе может быть чем угодно: от ресурсных строк с алфавитом символов, до переводов. Иногда, но не всегда лечится помещением в ресурсы.
• Магическая кнопка, от англ. magic button — весь код написан в обработчике нажатия кнопки. Этим страдают на всех языках с графическим редактором гуя — C#, делфи, где по умолчанию используется написание программ с событийной моделью выполнения.
  • Так же нельзя не отметить его прямого предка — Магический main(), где, как ясно из названия, забито даже на достижения в области модульного программирования и весь код заботливо ютится в одной огромной main() экранов на 40.
• Гонки, англ. race condition, race hazard — начинаются тогда, когда программист попадает в чудный мир параллельного программирования с его нитями, потоками и семафорами.
  • А между гонками программист вволю танцует на граблях, на собственной шкуре изучая такие весёлости, как Блокировки: живые блокировки (livelock), мёртвые блокировки (deadlock), ресурсные голодания (см. «Проблема голодного философа»)
• Ненужная сложность, от англ. accidental complexity — делать сложно то, что можно сделать просто. Как правило, бывает тогда, когда программисту хочется побыстрее применить всё, что он изучил (и во-о-он ту новую библиотеку для обмена данными по протоколу XXX); менеджеру хочется, чтобы в описании проекта было больше баззвордов (с Ыскусственным Ынтеллектом GPT на Веб 3.0 IoT Electron и подключением по usb квантовой автоминетилки клиенту). А ещё хочется заполучить по результатам проекта сразу много новых строчек в резюме. Если эти желания побеждают доводы рассудка, то в проекте появляется accidental complexity. Также см. статьи Индусский код и KISS.
• Спагетти (рус. солянка) из кода, от англ. code spaghetti — это тот самый код, который вам однажды дают сопровождать и после пяти минут причёсывания вставших дыбом волос просмотра которого вы молча закрываете редактор и открываете броузер на удохантере.ру в поисках вакансии в более другой фирме, где не практикуют такого жестокого обращения с программистами. Характеризуется тем, что в одном куске кода описывается куча перемешанных до полного непонимания сущностей, которые по-хорошему необходимо разделять. Например, HTML теги в PHP коде вместо выноса всей вёрстки в шаблоны.
• Катамари — внедрение новых возможностей исключительно в виде внешних костылей и подпорок вместо периодического пересмотра базового функционала. В итоге со временем код превращается в тугой комок какого-то нечто, в чём даже сами разработчики отказываются ковыряться. В итоге получаем следующую порцию костылей и подпорок. Может применяться как в отдельно взятом фрагменте кода, так и глобально во всём проекте.
• Божественный Объект, от англ. God Object — небольшая часть кода, где сконцентрировано всё. Буквально всё. Возможно, там даже прячется немаленьких размеров галактика. Весь прочий код программы — исключительно декорация вокруг Божественного Объекта.
  • Конкретно этот случай подробно иллюстрирует границы применимости ООП в зависимости от размеров программной системы: для небольших систем вся иерархия так или иначе вырождается в божественный объект (тот, в методах которого лежит основная обработка).
• Детонатор, от англ. detonator — очень распространён, но редко обнаруживаем. Наглядный пример: использование в вычислениях с датами поля из двух цифр. Бомба заложена, и детонатор рано или поздно сработает. Очень любим как аргумент против байтоложества.
• Исторический вклад, от англ. stake — паттерн имеет место в программе, написанной сотрудником, который впоследствии получил продвижение по службе. Несмотря на изобилие ошибок в программе, вклад этого сотрудника слишком велик, чтобы позволить кому-либо начать переписывать код, поскольку он является апофеозом технических достижений этого товарища.
  • В ту же степь и Так сложилось исторически — что-то раньше было сделано криво, с костылями и хаками по вполне объективной причине внешнего характера, но до сих пор тя-я-я-янется из релиза в релиз по соображениям совместимости с легаси — а переписывать, вынося всё в отдельную сущность слишком трудоёмко и дорого — или по классическим соображениям «кабы чего не вышло». Даже если сама объективная причина уже давно канула в лету и её пользуют полтора старика. Даже если этот код по результатам телеметрии вообще не запускают как минимум мажорный релиз, а то и два как. Даже если выкинуть этот код, то получится ускорить все на порядок, попутно резко упростив всем жизнь.
• Павлик Морозов aka Public Морозов (сугубо русская идиома, нет английского эквивалента) — класс, который по запросу выдаёт доступ ко всем, даже приватным, свойствам класса-родителя. Не столько плохо само по себе, сколько означает, что в коде что-то не так. Если это не внутренний класс, созданный для runtime-диагностики родительского, по тем или иным причинам требуемой, и сбора данных времени выполнения — это очень плохо, тому, что поломано одно из основных, основополагающих свойств объектов — ИНКАПСУЛЯЦИИ — как неких чёрных ящиков для всех, кроме самого объекта.
• Спасти рядового Райана, от англ. Private Ryan — а тут наоборот, паттерн, в котором доступ к полю получить в принципе можно, но для этого надо снаряжать экспедицию, сопряженную со множеством опасностей, привлекая такие механизмы, как рефлексию.
• Как называется ситуация, когда программист пользуется неограниченным доступом к нейросети, дабы она решала задания — и хотя знает язык достаточно, что бы решать мелкие ошибки и синтаксические ошибки (например — когда ИИ забывает проставить табуляцию), сам писать не может. В лучшем случае, такой программист только учится, и в будущем собирается стать полноценным программистом; а в совсем уж абсурдных случаях, «программист» с нейронкой и вовсе неуч, не знающий языка программирования даже на уровне «Hello World» — или даже просто языка, на котором написан код (Т.Е. английского даже на базовом уровне).

Анти-паттерны системного администрирования

Специально для сисадминов есть свои антипаттерны, в которые они попадают вне зависимости от своей специализации.

• Ад зависимостей, от англ. dependency hell — для юниксовых сисадминов. Прямо проистекает из того факта, что строители юниксовых дистрибутивов (в первую очередь линупсов) однажды возгордились и решили возвести Вавилонскую башню упорядочить весь линуксовый софт, так, чтобы одна программа в дистрибутиве не мешала другой. Последствия этой попытки пользователи порой ощущают в виде «циклических зависимостей» и прочих дорожек в dependency hell.
• Ад DLL, от англ. DLL hell — персонально для сисадминов Windows. Проблема является частным случаем ада зависимостей, применительно к формату библиотек (DLL) в Windows, особенно в старых версиях этой системы.

Впрочем, в современном мире, первые два антипаттерна тихо, но верно уходят на свалку истории, заменяясь вариантами ниже

• Контейнеровоз — софт, за исключением базовой системы, используется исключительно впихнутый в контейнер — виртуальное, отделённое на уровне файловой системы и каких-нибудь namespaces, хранилище, где кроме самой программы есть всё-всё-всё из её зависимостей — библиотеки, другой связанный вспомогательный софт. Управляется это все благолепие каким-нибудь менеджером контейнеров, типа docker. Философия контейнеров такова: наружу из него торчит только некий сервис — то, что программа делает — а все остальное скрыто от системы, от админа и от остальных программ в других контейнерах. Иногда контейнеры можно подружить друг с другом через общие ресурсы, но по большей части программа внутри контейнера считает, что в системе она одна. Это по большей части прерогатива линуксоидов, которые решили таким образом презреть dependency hell. В результате имеем у контейнеровоза: дикий оверхед по объёму приложений на диске, дикое использование ресурсов очередными прослойками между прослойками, кучи проблем с безопасностью из-за устаревших версий библиотек в контейнерах, а так же из-за того что в само скрытое от системы, админа и остальных программ содержимое контейнера легко запрятать компьютерные вирусы.
• Виртуальный владыка — а это уже для всех: на каждый чих создаётся виртуальная машина. И если классические варианты типа виртуалка-контроллер домена или виртуальный сервер терминалов ещё куда ни шло, то у владык буквально на каждую задачу спаунится виртуалка с программой внутри, благо программы для этого есть. Ещё больший оверхед, гипервизор усирается с натуги, воя кулерами, но зато все по науке, как в «больших» облаках.

А вот что вечно, так это классические грабли админов.

• Классическое, можно сказать хрестоматийное, посконное — Работает — не трожь. Постепенно, с течением времени админство превращается в лютые шаманства над поциентами, но админ не сдаётся — нет преграды идиотам, и вновь ещё один слой костылей нарастает на системе для решения казалось бы банальных задач, уже решённых из коробки в более новых версиях. И неважно на самом деле, ОС или программ — адепт культа «не трожь» будет одинаково ревностно отгонять любые решения вроде «купить новое» или «обновить», ведь…
  • В серверном варианте это ещё терпимо: мало где на сервере прямо таки необходимо гнаться за последними циферками и та же 1С как работала на XP 2003 м сервере, так и будет работать на сервере 2016 м. Имеет это смысл только ради совсем уж критичных фич и поддержки относительно нового оборудования. В любом случае служебка на имя директора творит чудеса и вот, после живительных педуль, наш адепт сквозь зубы пошёл ставить новую версию безотносительно того, что он сам об этом думает.
  • А вот на ПК уже юзерских оно показывает зубки особенно ярко, особенно, если дирекция — патологические жмоты, всегда картинно удивляющиеся «а как же так, работать не можете? Но ведь включается же!».
  • Запущенный случай: в Deutche Bahn нужны спецы по MS-DOS и Windows 3.11, она же стоит в бортовых компах Ласточек (это версия Siemens Desiro для России). Поговаривают, что действующие информационные системы пиндосских банков ещё древнее.
    • И это, между прочим, Германия — промышленный и экономический центр Евросоюза. Представьте, что стоит в учреждениях менее богатых стран НАТО — вроде какой-нибудь Польши или Румынии.

Организационные анти-паттерны

Есть такое искусство — «пасти котов», или, скучно выражаясь, управление программистами. Рисование всяких там диаграммок Ганта и прочей псевдонаучной лабуды, которую потом все дружно игнорируют. Этим занимаются менеджеры. Не секрет, что в менеджеры уходят те, кто в ИТ пришёл к своему финишу, постарел и отупел, чтобы писать код и ваять вечное, а может быть, и вовсе кроме ворда и аутлука ничем не пользовался и потому подался сразу в управдомы управлять людьми. Поэтому антипаттерны в этой области просто-таки цветут пышным цветом. Дополнительную дезорганизацию в организацию разработки порой привносят сами разработчики, помогая менеджерам во внедрении анти-паттернов.

• Управление грибами, от англ. mushroom management — метод управления подчиненными по принципу: вы все муравьи, а я муравейник! Английский лозунг грибного менеджера — «we keep them in the dark and feed them a steady diet of manure» (Richard Henderson). Менеджер всячески окучивает грибы убеждает подчинённых в том, что кроме их непосредственных заданий, им не надо ничего знать, а утруждать мозги думами о проекте в целом — исключительно манагерский удел. Для внедрения данного метода следует разбить проект на несобираемые кусочки паззла, чтобы никто не понимал, что из них можно собрать вообще и затем выдавать каждому эти кусочки в достаточных количествах, чтобы грибы перманентно были заняты работой и не отвлекались на раздумья «а на уя вообще мы делаем именно так?». Как правило, грибной менеджмент приводит к полностью провальным финалам, поскольку менеджер сам забывает (либо изначально не понимает), к чему и зачем идёт проект. Что любопытно, грибной менеджмент практикуют не только менеджеры, но и отдельные программисты, очутившись на ролях старших в проекте. Как правило, это индикатор неквалифицированных программистов, боящихся раскрывать коллегам те немногие знания, которыми они обладают — чтобы не обнаружилось, насколько эти знания малы. Та же причина справедлива и для менеджеров.
  • Впрочем, для проектов, где требуется секретность выше стандартной ДСП иногда антипаттерн с успехом применяется. Но тут нужна недюжинная аккуратность и люди, которые чётко осознают что должно получиться и крепко держат в голове всю картину целиком.
• Чайка-менеджер, от англ. seagull management или corporate seagull — распространённый подкласс менеджеров, действующих в следующей последовательности: прилетел, поорал и улетел, оставив за собой кучки проектного дерьма, которые потом, матерясь, подчищают подчинённые. По поведению напоминают морских ворон чаек, парящих гордо между тучами и морем и прилетающих на берег с целью быстро пожрать и попутно опорожнить кишечники, за что они (менеджеры) и переняли данное наименование. Самый бестолковый для проектной деятельности тип, но начальство их любит, так как корпоративные чайки умеют громко хлопать крыльями заявлять о себе, выдавая копеечную деятельность за великие свершения. Живучи, их сложно поймать на ошибках, так как ошибок они не совершают (поскольку, как известно, для этого нужно хоть что-то делать).
• Отсутствующий менеджер, от англ. Absentee manager — более запущенный случай менеджера-чайки. Этот кадр даже не прилетает поорать и погадить, его просто всегда нет на месте, и почти всегда по уважительной причине. В итоге подчинённые остаются вариться в собственном соку без всякой поддержки.
  • Обычно, если умудриться силком затащить их на место, первоочередной задачей ставит уехать назад заниматься своими делами, а потому действует «на отвали» и ищет уважительную причину убраться как можно скорее и не появляться вновь, укатываясь в анти-паттерны, весьма вероятно что действовать он будет как «чайка», но ещё дурнее и поспешнее. Затаскивание отсутствующего менеджера на место может принести больше вреда, чем пользы, так как он обычно плохо умеет заниматься своими обязанностями, не знает о происходящем в проекте, будет зол от того что его «насильно» поставили на место и вступит в конфликт с неофициальным лидером проекта, назначенным в его отсутсвие.
• Разработка комитетом, от англ. design by commitee — аналог пословицы «у семи нянек дитя без глазу» применительно к ИТ. Раздувается в гигантские нежизнеспособные стандарты и спецификации с over 9000 уровней абстракции, которые потом всё равно никто не реализует. Если же это смогут реализовать (или всерьез попытаться), то невероятно криво, «лишь бы формально соответствовало требованиям», и с огромным количеством всевозможных анти-паттернов разных видов и типов, что в свою очередь может привести к лавине анти-паттернов вытекающих из других анти-паттернов. Примеры — модель OSI и CORBA.
• Аналитики-паралитики, от англ. analysis paralysis — проект застревает на стадии анализа задачи, в бесконечных спорах «как делать лучше». В результате получается вообще никак.
• Рыцарь на белом коне (РНБК), от англ. Knight in shining armor (KISA) — непогрешимая личность, с ЧСВ, равным как минимум квадрату собственной технической квалификации. Появляется на сцене в кризисный момент и начинает чинить всё подряд, как правило — чинит успешно, только без сообщений о том, какие изменения он сделал, и почему. Так что при очередном обновлении системы ничего не подозревающим сисадмином старые ошибки возвращаются на свои места, что даёт повод РНБК заявлять о тупости и некомпетентности окружающих, что ещё более увеличивает его ауру непогрешимости.
• Аврал!, от англ. Tempest Method — применяется не ранее, чем за несколько дней до сдачи проекта. При этом пограммисты начинают в срочном порядке генерировать код без комментариев и содержащий в себе связки бомб с детонаторами.
• Охота на ведьм, от англ. witch hunt — попытки отыскать козла отпущения после успешного внедрения анти-паттернов выше, но поскольку проблем это не решает, результатом будет являться отстрел всё новых и новых козлов отпущения. В финале игры должен оставаться только один — Duncan McLeod менеджер на белом коне, с подтверждениями некомпетентности предыдущей команды и уверениями руководства фирмы в том, что новая команда под его руководством достигнет небывалых проектных успехов.
• Когда есть только молоток, от англ. All you have is a hammer, также One-trick pony — ситуация, когда кто-то (например, менеджер) использует абсолютно одинаковый подход ко всем сотрудникам и задачам, начисто игнорируя то, что все люди вообще-то разные, ровно как и задачи. И это ещё объяснимо, если он только это и умеет, зато настолько хорошо, что «перетягивать одеяло на себя» проще, и зачастую эффективнее, чем действовать по-другому — но такая манера действий часто может быть результатом простой лени или глупости.
• Я — начальник, ты — дурак, в английском языке используется термин Cage match negotiator — линия поведения менеджера при любых переговорах с подчинёнными как в известном анекдоте: Пункт 1 — шеф всегда прав; Пункт 2 — если шеф не прав, смотри пункт 1.
• Не-виноватая-я, англ. absolver — паттерн встречается в коде, написанном бывшими сотрудниками компании. В таком коде — по честно-клятвенным заверениям ныне работающих — заключено столько старых проблем, что теперешние сотрудники могут легко перевести стрелки со своего говнокода, утверждая, что именно вклад бывшего коллеги — причина всех возникающих ошибок. Также известен под именем Это-Не-Моя-Правка.
• Злоупотребление модными словечками, от англ. Buzzword mania — постоянное внедрение новых модных фич в готовую продукцию и тех.процесс без особого понимания, зачем они нужны. Модно же, и в теории магически решит все проблемы! Хрестоматийный пример — внедрение тайм-менеджера в команду из одного-двух человек, которые кроме вверенного им проекта ничем не занимаются, в итоге получается как в известном пошлом анекдоте: как сношали, так и сношают, только бюрократии заметно прибавилось.

Антихитрозадость

Как говорил рядовой программист Э. Дейкстра: «Компетентный программист полностью осознает строго ограниченные возможности своего черепа, поэтому подходит к задачам программирования со всей возможной скромностью».

Заблуждения по поводу потенциала мозга руководителя или программиста являются перманентным источником антипаттернов.

• Раскрытие потенциала технологии на 110 %. Быстрое развитие платформ, средств разработки и их зарастание возможностями туманит мозги рядовому кодеру, который предполагает, что если он не будет писать код с десятью операторами на строку, использовать все возможные варианты генераторов, шаблонов, тегов, тонкие нюансы работы интерпретатора и низкосистемные хаки, то коллеги сочтут его полным junior'ом. Но, как правило, все получается ровно таки наоборот и каждая хитрозадость в коде с лихвой аукается при дальнейшей поддержке продукта, не говоря про то, что бедные разработчики платформ, сред и библиотек кучу фич включают просто для галочки, уделяя им соответствующее внимание. При этом простых и понятных дедушкиных подходов, которые не обязательно означают квадратно-гнездовой подход, обычно с лихвой хватает для решения подавляющего большинства задач.
• Манипулирование сроками. Любому эффективному руководителю рано или поздно приходит в голову мысль, а не стоит ли назвать разработчикам срок в 3,14 раз меньше оценочного, чтобы пошевеливались, хотя, если инвестиции затуманили его мозг, то в 3,14 раза больше, чтобы в этот раз ну точно успеть к дедлайну. Мысль о том, что все будет относительно хорошо, только если план работ соотносится с оценкой объёма работ, считается слишком банальной и не достойной настоящего гуру руководства. Как следствие — множество проектов заканчивается феерически.
• Экономия. Так как заказчик часто желает получить золотой замок за ведро пожухлого говна, то встаёт вопрос об экономии. Истинная хитрозадость диктует, что вместо того, чтобы сократить слой позолоты в два раза (обрезать фичи и требования), лучше сократить проектирование, прототипирование, внутренние конвенции, тесты, автотесты, команду разработчиков и прочие вещи, которые все равно не получается делать по-человечески. Разумеется, ответ на ключевой вопрос очевиден, так как на заводе для производства денатурата никак не удастся изготовить бочонок шотландского виски, что все вроде как головой понимают, но в душе все равно хотят.
• Раскрытие кадрового потенциала на 110 %. В голову среднестатистического эффективного проджект-менеджера никак не укладывается, что программиста, написавшего в день десять строк, вполне можно назвать нормально поработавшим, а сто годных, отлаженных и протестированных строк — поработавшим отменно. Это приводит его к мысли, что в качестве программиста можно посадить секретаршу, так как у неё скорость набора выше, но так как секретарша отказывается, менеджерская логика подсказывает, что пора нагнетать панику, бегать со страпоном и всячески стимулировать процесс, дабы поиметь отдачу на 110 %. В результате проект дохнет под собственным технологическом долгом (неудачные решения, неправильные оценки и тупо баги), не успев толком начаться. Правда, сам менеджер, как правило, двигает кони в первых рядах, а команда разработчиков, поправив резюме, на следующий же день переползает в какие-то другие конторы в надежде на лучшее.

Гиперссылки

• Большой неиллюстрированный каталог анти-паттернов (англ.)
• Проломы проектно-дизориентированного проектирования