Программные ошибки, или, говоря по-программистки, баги — это самая злободневная тема для любого программиста, занятого повседневной коммерческой разработкой софта. Неважно, пишите ли вы на PHP, Java/C# или, может даже, на новомодном Haskell... Баги — это то общее, что объединяет абсолютно всех: пэхэпешников и джавистов, начинающих и профессионалов, сторонников-бессребреников OpenSource и работяг, делающих на программировании большие деньги. Это порой неподвластная уму и отладчику стихия, которая, безусловно, подлежит укрощению и, как любое другое явление природы, требует для этого соответствующей научной базы. Стройная и непротиворечивая классификация — краеугольный камень любой теории, начальный шаг к обузданию грозной стихии глюков.
И, хотя в интернете есть много самых разных списков, пытающихся как-то по-своему классифицировать программные ошибки по их типам, — я попытался сегодня собрать всё их дивное разнообразие воедино в одном месте.
Сразу предупреждаю: под катом вы не найдёте серьёзную систему классификации ошибок, подобную той, что многие изучали в университетах: мы сосредоточимся на живом фольклоре — тех определениях и явлениях (преимущественно англоязычных), с которыми повседневно встречаются обычные программисты, — даже если нам при этом и приходиться невольно улыбаться.
Название взято из квантовой механики и является игрой слов от известного и основополагающего в соответствующем разделе физики «принципа неопределённости Гейзенберга», который на бытовом уровне понимается как изменение наблюдаемого объекта в результате самого факта наблюдения. В силу своей изначальной природы «гейзенбаги» очень сложно поддаются локализации и осмыслению, поскольку они проявляются в зависимости от случайных флюктуаций и воспроизводятся крайне нестабильно.
Название происходит от имени Бенуа Мандельброта, основоположника фрактальной геометрии, который обладал необычным математическим даром, в результате которого имел обыкновение писать свои научные сочинения столь сложным языком (пропуская все промежуточные выводы, для него слишком очевидные), что для осмысления его рекурсивного (фрактального) метода понадобились совокупные усилия всего научного сообщества.
Как правило, Шрёдинбаг — это результат code review самого опытного программиста на фирме в конце длинной трудовой недели, который в пятницу вечером, хорошо подумав над программой своего младшего коллеги, приходит к однозначному мнению, что «этого не может быть просто потому, что этого не может быть». Слово «Шрёдинбаг» происходит от мысленного эксперимента с котом Шрёдингера.
«Видишь суслика? — Нет. — А он есть!».
counter++
).Одна из самых обсуждаемых и распространенных ошибок, название которой пародирует известного киношного персонажа Йоду (который, говоря, постоянно переставляет слова местами). Итак, в нашем случае запись if(constant == variable)
вместо if(variable == constant)
равноценна тому, как если сказать: «Если голубое — это небо».
Некоторые пишут это как Refuctoring, но я отношусь к тем, кто предпочитает именовать этот бесполезный навык именно Refucktoring.
Итак, это всем хорошо знакомый рефакторинг — но наоборот, когда, исходя из самых лучших побуждений, некто берёт изначально хороший код, и после внесения в него «улучшающих» этот код исправлений впредь работа с ним делается невозможной ни для кого, кроме автора данных улучшений. В связи с этим на Руси говорят: «заставь дурака богу молиться, он и лоб себе расшибёт». Как правило, refucktoring является результатом чтения большого количества умных книг, смысл которых не был понят до конца, то есть следствием так называемого «Cargo cult programming.
Прилагательное для описания некоей киллер-фичи, которой уделяется очень много внимания и надежд, несмотря на то, что она находится пока в стадии планирования и её возможность реализации ещё недостаточно изучена в контексте всей программы. Как правило, наличие Unicorny-фич потенциально приводит к возникновению Vaporware-продукта.
Разработка, инициированная и простимулированная животным страхом. Как пример, это когда руководство в отместку увольняет кого-то, урезает ресурсы и зарплаты, постоянно орёт «пшёл вон отсюда!», при этом искренне надеясь, что люди после этого сразу начнут работать лучше. Применяется не только на уровне программирования, но и на уровне построения общественно-социальных систем, особенное широкое применение этот подход нашёл в военной сфере.
Разработка, полностью движимая и управляемая призрачной надеждой на чудо. Иначе говоря, это разработка в длительном (иногда — бесконечном) неспланированном цикле с надеждой, что в заключении всё как-то само образуется и наконец-то заработает в релизе.
Разработка, в которой в силу некоторых причин (лень, наивность, нехватка времени и так далее) исправление всех выявляемых ошибок и сложностей постоянно откладывается «на потом». DDD — это методология, на основе которой создаётся конечный продукт с максимально смещённой к дедлайну фазой фиксинга ошибок в надежде прибить их потом и сразу всех одним махом (не отвлекаясь на такую ерунду в процессе основной фазы разработки).
Методология, которая позволяет здорово сэкономить на тестировщиках. Все продукты тестируются непосредственно в рабочей среде и на конечных заказчиках, здесь программа поставляется максимально оперативно в стандартном виде «как есть». Заодно это позволяет сделать разработчиков ближе непосредственно к людям, работающим на их программе, что часто бывает очень даже полезным для первых.
Это витиеватый код, который никак не удается исправить. Как и у мифической Гидры, каждый фикс такого бага порождает два новых бага ещё страшнее предыдущих. По всем приметам, Гидра традиционно возникает, как правило, на пороге окончания самого главного и ответственного дедлайна. Любой ответственный человек, который всерьёз берётся за исправление гидробага и готов биться с ним до конца, как правило, попадает в жернова race condition, откуда коллеги если и вытаскивают его живым, то отправляют сразу прямиком на оплачиваемый больничный.
Все знакомы с инкрементом? Добавить 2 к переменной за один шаг — это и есть «двойной» (би-) инкремент.
Создание специальных кастомных сборок для больших боссов — людей, мнение которых, с одной стороны, просто невозможно игнорировать, но с другой — очевидно, что такие программы невозможно использовать большинству простых смертных. Это попытка применения стратегии win-win, которая приводит к появлению дополнительной ветви разработки и цели компиляции.
Это проблемный код, который напрямую ответственен за зависания вашего приложения намертво. Здесь удачная игра слов, так как «a hooker» также может значить «проститутка». Ввиду этого к подобному коду особенно нетолерантно относится старшее, в большинстве своем до ужаса пуританское поколение разработчиков.
Вот типичная иллюстрация того, как звучит применение этого выражения в подходящей ситуации:
— Почему у нас лежит сайт?
— Вероятно, там еще остался этот проститутский код.
Это такой дизайн кода, когда при его малейшем изменении всё приложение рушится, а его логика работы становится бессмысленной. Как правило, это изначально неудачное жесткое завязывание логики приложения на какую-то отдельную его часть на этапе проектирования, что делает общую ситуацию похожей на популярную игру «дженга». Такая система может сохранять равновесие и даже работать, но малейшее неудачное движение (правка) и... море раздражения и разочарования.
Это когда с пылу-жару, на пике энтузиазма кидаешься в работу, и, уже накодивши большой кусок программы, вдруг осознаешь, что это не будет работать в контексте данной конкретной системы (или есть гораздо более эффективный способ реализации этой идеи). Мораль здесь такова: всегда сначала лучше как следует подумать, перед тем как закатывать рукава и приступать непосредственно к работе.
Фальстарт особенно плачевен, когда это касается создания дизайна (каркаса) системы, так как при обнаружении системных противоречий уже на поздней фазе проектирования системы такое приложение неизбежно подлежит полному переписыванию.
Это распространенный стиль расстановки фигурных скобок, как показано на кусочке кода внизу:
if (a == b) { print(«hello»); }
Если посмотреть на рисунок ниже и на эти скобки, то становится очевидным данное им название. Вообще, такой стиль описания был описан ещё в знаменитой книге Кернигана и Ричи «Язык программирования С», поэтому египетский стиль также известен для многих как K&R. Также, насколько я понимаю, «египетские скобки» являются стандартом для Java.
Маньячное и неудержимое желание разработчика вычистить свой код до блеска, когда он раз за разом рефакторит его, не в силах остановиться. И даже тогда, когда уже кажется, что этот идеал найден, такой разработчик всё равно увидит в нём место, где можно добавить хотя бы один лишний пробел, чтобы всё казалось ровнее и красивее.
Как правило, это носитель идей перфекционизма и нарциссизма, который активно ищет, как обрести вечное совершенство через программирование. Как минимум, он страдает низкой эффективностью своей работы, как максимум — в своём бесконечном поиске идеала склонен создавать проблемы себе и другим на абсолютно пустом месте.
Это ошибка в системе, которая существует уже настолько давно, что все давно приспособились к ней. Теперь невозможно исправить её, чтобы не сломать весь функционал других систем, намертво завязанных на неё. Это тот самый случай, когда почтенный возраст и известность бага приводят к тому, что он заслуженно и неизбежно получает титул «фичи».
Это точная реализация функциональности программы, заданной в спецификации, которая сразу после её внедрения, в силу каких-то причин, становится абсурдной или невостребованной. Как правило, это следствие недостаточного понимания условий постановщиком задачи либо следствие неких форс-мажорных обстоятельств, произошедших уже после релиза программы. Соответственно, подверженная ошибке 101, подобная фича (или вся программа) остаётся навсегда бессмысленной и неиспользуемой.
Стратегия отладки или поиска ошибки в программе, когда исправления вносятся наугад (исходя из самых смутных догадок или подчас иррациональных гипотез), в надежде, что это будет тот самый «случайный, но меткий выстрел». Данный вид пассивной отладки часто применяется сильно уставшим программистом в конце рабочего дня, и эта стратегия является полным аналогом кнопки «Мне повезет» в поиске Google.
Впрочем, чаще всего подобные подсознательные индукционные правки программы приводят к ещё более плачевным последствиям, и прекрасно зная это, программист чаще всего уповает на магическую кнопку Undo.
Это баг-репорт, предоставляемый разработчику «продвинутым» пользователем, который считает, что он сам понимает суть проблемы или устройства системы (как правило, содержащий уже готовые решения и поучения, как не следует делать впредь). Как правило, степень самоуверенности обратно пропорциональна корректности описываемых причин проблемы.
Тип кода (стиль кодирования), который содержит такое количество функциональности на все мыслимые или даже немыслимые случаи жизни, что при желании достичь абсолютной универсальности этот код становится тяжелым, неповоротливым, а его многочисленные частные решения перестают решать свою проблему достаточно качественно.
Кодирование в стиле швейцарского ножа — это неизбежная проблема нарушения гармоничного баланса между количественными показателями фич и их качественными характеристиками, что в итоге приводит к появлению просто монстроидальных классов или библиотек.
Конечно, огромное количество ходовых выражений осталось за бортом этого короткого словарика. Всем желающим продолжить погружение в неформальный жаргон программистов предлагаю самостоятельно потоптать приведенный забор ссылок (1, 2, 3, 4, 5, 6), из которых было отобрано и прокомментировано самое интересное (на мой субъективный взгляд), но при этом далеко не все поместилось в формат одной небольшой статьи.
Если у кого-то есть свои, не упомянутые здесь, устойчивые и удачные профессионально-жаргонные выражения, — просьба приводить их со своим описанием в комментариях.
3 комментария
"Условия Йоды (Yoda Conditions)
Одна из самых обсуждаемых и распространенных ошибок, ..." в каком это месте они являются ошибкой?
Условия Йоды является ошибкой с точки зрения общепринятых норм программирования, так же как и является ошибкой бездумные названия функций. Но вот почему стиль Кернигана и Ричи попал в категорию ошибок меня действительно удивляет, это достаточно популярный стиль программирования, позволяет экономить строки для лучшей читаемости кода, т.к. на экране умещается больше кода, а значит его можно охватить за один проход глазами.
как то не очень на сленг похоже