Багопедия: малый словарь жаргона программиста

Программные ошибки, или, говоря по-программистки, баги – это самая злободневная тема для любого программиста, занятого повседневной коммерческой разработкой софта. Неважно, пишите ли вы на PHP, Java/C# или, может даже, на новомодном Haskell... Баги – это то общее, что объединяет абсолютно всех: начинающих и профессионалов, сторонников-бессребреников OpenSource и работяг, делающих на программировании большие деньги. Это порой неподвластная уму и отладчику стихия, которая, безусловно, подлежит укрощению и, как любое другое явление природы, требует для этого соответствующей научной базы. Стройная и непротиворечивая классификация – краеугольный камень любой теории, начальный шаг к обузданию грозной стихии незнания. И, хотя в интернете есть много самых разных списков, пытающихся как-то по-своему классифицировать программные ошибки по их типам, – я попытался сегодня собрать всё их дивное разнообразие воедино в одном месте. Сразу предупреждаю: под катом вы не найдёте серьёзную систему классификации ошибок, подобную той, что многие изучали в университетах: мы сосредоточимся на живом фольклоре – тех определениях и явлениях (преимущественно англоязычных), с которыми повседневно встречаются обычные программисты, – даже если нам при этом и приходиться невольно улыбаться.

Разновидности ошибок

Гейзенбаг (Heisenbug) – сложно детектируемый тип ошибки, периодически исчезающий и меняющий свои свойства при каждой попытке обнаружения или отладки. Достаточно близок по своему значению к отечественному термину «плавающая ошибка». Название взято из квантовой механики и является игрой слов от известного и основополагающего в соответствующем разделе физики «принципа неопределённости Гейзенберга», который на бытовом уровне понимается как изменение наблюдаемого объекта в результате самого факта наблюдения. В силу своей изначальной природы «гейзенбаги» очень сложно поддаются локализации и осмыслению, поскольку они проявляются в зависимости от случайных флюктуаций и воспроизводятся крайне нестабильно. Борбаг (Bohrbug) – самый распространенный тип программной ошибки, которая, в противоположность Гейзенбагу, не исчезает и не меняет своих свойств. Иначе говоря, это «ошибка обыкновенная», которая воспроизводится стабильно и регулярно и существование которой абсолютно очевидно для всех участников процесса создания и эксплуатации программы, что в свою очередь, делает её исправление чаще всего тривиальным. Мандельбаг (Mandelbug) – редкая программная ошибка, чьё поведение кажется полностью хаотичным (в силу чрезвычайной сложности). Природа этой ошибки, как правило, настолько сложна, что в этом случае часто применяют устойчивую программистскую идиому: «проще переписать всё заново и с нуля, чем пытаться разобраться, как оно работает». Некоторые программы представляют из себя один сплошной мандельбаг, при этом чисто эмпирически установлено, что создатели подобных программ имеют смуглый цвет лица и радикально черные волосы. Название происходит от имени Бенуа Мандельброта, основоположника фрактальной геометрии, который обладал необычным математическим даром, в результате которого имел обыкновение писать свои научные сочинения столь сложным языком (пропуская все промежуточные выводы, для него слишком очевидные), что для осмысления его рекурсивного (фрактального) метода понадобились совокупные усилия всего научного сообщества. Шрёдинбаг (Schroedinbug) – критическая ошибка с налётом мистичности, которая может долго никак не проявлять себя, однако внезапно возникает, если кто-то наткнётся на неё в исходном коде этой программы и осознает, что система вообще не могла работать при наличии настолько серьёзной ошибки. После этого программа внезапно перестаёт работать вообще, до тех пор пока обнаруженная ошибка не будет исправлена. Несмотря на кажущуюся потусторонность этой ошибки, она ещё как встречается в реальной жизни, например, вот её практический пример. Как правило, Шрёдинбаг – это результат code review самого опытного программиста на фирме в конце длинной трудовой недели, который в пятницу вечером, хорошо подумав над программой своего младшего коллеги, приходит к однозначному мнению, что «этого не может быть просто потому, что этого не может быть». Слово «Шрёдинбаг» происходит от мысленного эксперимента с котом Шрёдингера. Бозебаг – чрезвычайно большое скопление ошибок в определенном участке кода, так называемый «блошиный остров». В силу концентрации всего деструктивного, что только есть, на этом сравнительно маленьком, как правило, критичном для всей программы участке, часто напоминает «ковровую бомбардировку» по своим последствиям при её ликвидации. Хороший бозебаг всегда написан таким образом, что должен изначально ставить в тупик программиста при попытке понять правильный порядок его исправления. Дзенбаг – абсолютно не влияющая ни на что, но реально существующая ошибка, по своей идее созвучна известной фразе: «Видишь суслика? – Нет. – А он есть!». Метабаг – грамматическая или орфографическая ошибка (или просто неудачная формулировка) в комментарии к сложной части кода, как-то искажающая саму логику описываемого кода, уводящая своей ложной трактовкой в сторону от того, что делает программа на самом деле, создавая этим ненужный драматизм в понимании этого кода буквально на пустом месте. Фомбаг (Phase of the Moon bug) строго периодический баг, имеющий четкую корреляцию по времени своего проявления и активизирующийся при исполнении программы только в это время (например: только по утрам, только 13-го числа, и так далее). Альфабаг (particle bug) – баг, который произошел лишь единожды, а разбор ситуации утверждает, что это следствие отказа или глюка аппаратных средств (здесь чаще всего в силу мистичности часто сваливают всё на влияние потока альфа-частиц или повышенное электромагнитное/солнечное излучение в этот день). Фермабаг – часто встречаемый тип ошибки, сложно доказуемый или нереальный с точки зрения автора программы, проявляющийся, как правило, исключительно на машинах заказчика. Чем дальше территориально находится заказчик от создателя программы и чем более сложные условия для удалённой отладки и диагностики такого случая – тем больше вероятность его проявления. Уфобаг (UFO bug) – это тип популярной псевдоошибки, относительно которой – даже если ранее было установлено, что она не существует и является следствием непонимания покупателем заложенной функциональности (это не баг, это фича!) – покупатели дружно продолжают настойчиво сообщать, несмотря на все ваши старания победить возникшую эпидемию непонимания. Как правило, причины такого поведения лежат уже в области UI или провала в предсказании психологии поведения типичного пользователя программы. Цепочная ошибка (Counterbug) – как правило, очень неочевидная ошибка, которая может наблюдаться исключительно при помощи уже «посвященного в ошибку» человека. И только после личного лицезрения ошибки во время его демонстрации вы обретаете способность сами «её видеть» и указать на неё следующему очевидцу (counter++). Ключевое свойство ошибки: её описание не поддаётся сообщению ни в виде письменного баг-репорта, ни после подробного изложения по телефону – только личная демонстрация позволяет «увидеть и прикоснуться к сему таинству». Лох-нессовский баг, или Bigfoot-баг, – это просто невероятная ошибка, которую видел только один человек, доверять которому, как правило, можно (нужно) безоговорочно (например, твой босс или топ-менеджер крупного клиента). Возможно, кто-то из них даже выложил скриншот, доказывающий её существование. Эта ошибка больше никогда никем не воспроизводилась и никак не проявлялась, само её описание кажется фантастическим даже для вас, автора программы, но с тех самых пор вы постоянно размышляете, что же это могло такое быть?

Другие распространенные термины

Условия Йоды (Yoda Conditions) Одна из самых обсуждаемых и распространенных ошибок, название которой пародирует известного киношного персонажа Йоду (который, говоря, постоянно переставляет слова местами). Итак, в нашем случае запись if(constant == variable) вместо if(variable == constant) равноценна тому, как если сказать: «Если голубое – это небо». Refucktoring Некоторые пишут это как Refuctoring, но я отношусь к тем, кто предпочитает именовать этот бесполезный навык именно Refucktoring. Итак, это всем хорошо знакомый рефакторинг ¬– но наоборот, когда, исходя из самых лучших побуждений, некто берёт изначально хороший код, и после внесения в него «улучшающих» этот код исправлений впредь работа с ним делается невозможной ни для кого, кроме автора данных улучшений. В связи с этим на Руси говорят: «заставь дурака богу молиться, он и лоб себе расшибёт». Как правило, refucktoring является результатом чтения большого количества умных книг, смысл которых не был понят до конца, то есть следствием так называемого "Cargo cult programming. Unicorny Прилагательное для описания некоей киллер-фичи, которой уделяется очень много внимания и надежд, несмотря на то, что она находится пока в стадии планирования и её возможность реализации ещё недостаточно изучена в контексте всей программы. Как правило, наличие Unicorny-фич потенциально приводит к возникновению Vaporware-продукта. Fear Driven Development Разработка, инициированная и простимулированная животным страхом. Как пример, это когда руководство в отместку увольняет кого-то, урезает ресурсы и зарплаты, постоянно орёт «пшёл вон отсюда!», при этом искренне надеясь, что люди после этого сразу начнут работать лучше. Применяется не только на уровне программирования, но и на уровне построения общественно-социальных систем, особенное широкое применение этот подход нашёл в военной сфере. Hope Driven Development Разработка, полностью движимая и управляемая призрачной надеждой на чудо. Иначе говоря, это разработка в длительном (иногда – бесконечном) неспланированном цикле с надеждой, что в заключении всё как-то само образуется и наконец-то заработает в релизе. Debt-Driven Development Разработка, в которой в силу некоторых причин (лень, наивность, нехватка времени и так далее) исправление всех выявляемых ошибок и сложностей постоянно откладывается «на потом». DDD – это методология, на основе которой создаётся конечный продукт с максимально смещённой к дедлайну фазой фиксинга ошибок в надежде прибить их потом и сразу всех одним махом (не отвлекаясь на такую ерунду в процессе основной фазы разработки). Ping Pong Development Методология, которая позволяет здорово сэкономить на тестировщиках. Все продукты тестируются непосредственно в рабочей среде и на конечных заказчиках, здесь программа поставляется максимально оперативно в стандартном виде «как есть». Заодно это позволяет сделать разработчиков ближе непосредственно к людям, работающим на их программе, что часто бывает очень даже полезным для первых. Гидра-код, гидробаг (Hydra Code/Bug) Это витиеватый код, который никак не удается исправить. Как и у мифической Гидры, каждый фикс такого бага порождает два новых бага ещё страшнее предыдущих. По всем приметам, Гидра традиционно возникает, как правило, на пороге окончания самого главного и ответственного дедлайна. Любой ответственный человек, который всерьёз берётся за исправление гидробага и готов биться с ним до конца, как правило, попадает в жернова race condition, откуда коллеги если и вытаскивают его живым, то отправляют сразу прямиком на оплачиваемый больничный. Bicrement Все знакомы с инкрементом? Добавить 2 к переменной за один шаг – это и есть «двойной» (би-) инкремент. Босс-билд Создание специальных кастомных сборок для больших боссов – людей, мнение которых, с одной стороны, просто невозможно игнорировать, но с другой – очевидно, что такие программы невозможно использовать большинству простых смертных. Это попытка применения стратегии win-win, которая приводит к появлению дополнительной ветви разработки и цели компиляции. Hooker Code Это проблемный код, который напрямую ответственен за зависания вашего приложения намертво. Здесь удачная игра слов, так как “a hooker” также может значить «проститутка». Ввиду этого к подобному коду особенно нетолерантно относится старшее, в большинстве своем до ужаса пуританское поколение разработчиков. Вот типичная иллюстрация того, как звучит применение этого выражения в подходящей ситуации: – Почему у нас лежит сайт? – Вероятно, там еще остался этот проститутский код. Дженга-код Это такой дизайн кода, когда при его малейшем изменении всё приложение рушится, а его логика работы становится бессмысленной. Как правило, это изначально неудачное жесткое завязывание логики приложения на какую-то отдельную его часть на этапе проектирования, что делает общую ситуацию похожей на популярную игру «дженга». Такая система может сохранять равновесие и даже работать, но малейшее неудачное движение (правка) и… море раздражения и разочарования. Фальстарт (False Start) Это когда с пылу-жару, на пике энтузиазма кидаешься в работу, и, уже накодивши большой кусок программы, вдруг осознаешь, что это не будет работать в контексте данной конкретной системы (или есть гораздо более эффективный способ реализации этой идеи). Мораль здесь такова: всегда сначала лучше как следует подумать, перед тем как закатывать рукава и приступать непосредственно к работе. Фальстарт особенно плачевен, когда это касается создания дизайна (каркаса) системы, так как при обнаружении системных противоречий уже на поздней фазе проектирования системы такое приложение неизбежно подлежит полному переписыванию. Египетские скобки Это распространенный стиль расстановки фигурных скобок, как показано на кусочке кода внизу: if (a == b) {    print("hello"); } Если посмотреть на рисунок ниже и на эти скобки, то становится очевидным данное им название. Вообще, такой стиль описания был описан ещё в знаменитой книге Кернигана и Ричи «Язык программирования С», поэтому египетский стиль также известен для многих как K&R. Также, насколько я понимаю, «египетские скобки» являются стандартом для Java. Синдром красивых бантиков Маньячное и неудержимое желание разработчика вычистить свой код до блеска, когда он раз за разом рефакторит его, не в силах остановиться. И даже тогда, когда уже кажется, что этот идеал найден, такой разработчик всё равно увидит в нём место, где можно добавить хотя бы один лишний пробел, чтобы всё казалось ровнее и красивее. Как правило, это носитель идей перфекционизма и нарциссизма, который активно ищет, как обрести вечное совершенство через программирование. Как минимум, он страдает низкой эффективностью своей работы, как максимум – в своём бесконечном поиске идеала склонен создавать проблемы себе и другим на абсолютно пустом месте. Common Law Feature Это ошибка в системе, которая существует уже настолько давно, что все давно приспособились к ней. Теперь невозможно исправить её, чтобы не сломать весь функционал других систем, намертво завязанных на неё. Это тот самый случай, когда почтенный возраст и известность бага приводят к тому, что он заслуженно и неизбежно получает титул «фичи». Ошибка 101: реализация, несовместимая с реальностью (Reality 101 Failure) Это точная реализация функциональности программы, заданной в спецификации, которая сразу после её внедрения, в силу каких-то причин, становится абсурдной или невостребованной. Как правило, это следствие недостаточного понимания условий постановщиком задачи либо следствие неких форс-мажорных обстоятельств, произошедших уже после релиза программы. Соответственно, подверженная ошибке 101, подобная фича (или вся программа) остаётся навсегда бессмысленной и неиспользуемой. Shotgun debugging Стратегия отладки или поиска ошибки в программе, когда исправления вносятся наугад (исходя из самых смутных догадок или подчас иррациональных гипотез), в надежде, что это будет тот самый «случайный, но меткий выстрел». Данный вид пассивной отладки часто применяется сильно уставшим программистом в конце рабочего дня, и эта стратегия является полным аналогом кнопки «Мне повезет» в поиске Google. Впрочем, чаще всего подобные подсознательные индукционные правки программы приводят к ещё более плачевным последствиям, и прекрасно зная это, программист чаще всего уповает на магическую кнопку Undo. Smug Report Это баг-репорт, предоставляемый разработчику «продвинутым» пользователем, который считает, что он сам понимает суть проблемы или устройства системы (как правило, содержащий уже готовые решения и поучения, как не следует делать впредь). Как правило, степень самоуверенности обратно пропорциональна корректности описываемых причин проблемы. Swiss Army Code, SAC Тип кода (стиль кодирования), который содержит такое количество функциональности на все мыслимые или даже немыслимые случаи жизни, что при желании достичь абсолютной универсальности этот код становится тяжелым, неповоротливым, а его многочисленные частные решения перестают решать свою проблему достаточно качественно. Кодирование в стиле швейцарского ножа – это проблема нарушения гармоничного баланса между количественными показателями фич и их качественными характеристиками, что в итоге приводит к появлению просто монстроидальных классов или библиотек.

Заключение

Конечно, огромное количество ходовых выражений осталось за бортом этого короткого словарика. Всем желающим продолжить погружение в неформальный жаргон программистов предлагаю самостоятельно потоптать приведенный забор ссылок (1, 2, 3, 4, 5, 6), из которых было отобрано и прокомментировано самое интересное (на мой субъективный взгляд), но при этом далеко не все поместилось в формат одной небольшой статьи. Если у кого-то есть свои, не упомянутые здесь, устойчивые и удачные профессионально-жаргонные выражения, – просьба приводить их со своим описанием в комментариях.

Место солидарности беларусского ИТ-комьюнити

Далучайся!