Нет ничего более постоянного, чем временное решение. Любой айтишник хоть раз лепил костыль на скорую руку — потом перепишем, потом сделаем нормально. Но «потом» обычно не наступает, и в итоге времянка живёт в продакшене годами, переживает релизы и смену команд, а иногда становится частью продукта. У индустрии полно баек о том, как костыли превращались в легенды. В этой статье собрал самые интересные случаи из истории ИТ. Приглашаю под кат. 

Windows 9 и старый код

Начнём с легенды из мира больших корпораций. Почему так и не появилось Windows 9? Одна из самых популярных версий объясняет это костылями в старом коде. 

В 90-е многие приложения определяли версию ОС предельно примитивно: искали в строке «9» и считали, что перед ними Windows 95 или 98. Если бы Microsoft выпустила «Windows 9», такие программы легко приняли бы её за Windows 95/98, и последствия предсказать было бы сложно.

Microsoft всегда трепетно относилась к обратной совместимости, поэтому версия про «костыльный» код звучала правдоподобно. Официально в компании объясняли пропуск «девятки» маркетингом и желанием подчеркнуть разрыв поколений. Но факты подтверждали миф: в открытых репозиториях реально находили куски кода на Java, где проверка шла именно по названию ОС, а не по номеру версии.

То есть такие костыли действительно существовали. Ирония в том, что из-за них у нас нет Windows 9, а «десятка» стала новой точкой отсчёта для всей планеты.

Фантомная дата в Excel

Другой из классических примеров «вечного костыля» — история с високосным 1900 годом в Microsoft Excel. Если ввести в таблицу дату 29 февраля 1900-го, программа примет её как корректную, хотя в календаре такого дня никогда не существовало (если что, 1900-й год не был високосным).

И это не случайный баг, а вполне осознанное решение разработчиков. Дело в совместимости с легендарным табличным процессором Lotus 1-2-3. Когда-то его создатели решили считать 1900-й високосным, чтобы не усложнять расчёт дат. Microsoft, создавая Excel, пошла на хитрость — скопировала логику Lotus вместе с ошибками. Так Excel стал считать 1900 год високосным, чтобы пользователи без проблем импортировали таблицы из Lotus, даже если даты там изначально были неправильными.

Разумеется, со временем костыль обернулся проблемами. Формально в Excel появилось смещение. Microsoft знает об этом и прямо говорит, что исправлять баг слишком дорого. Любая попытка «починить» приведёт к тому, что миллионы старых файлов окажутся сдвинутыми на один день, формулы перестанут работать, а совместимость разрушится.

В итоге компания оставила всё как есть. Пострадала только одна функция — вычисление дня недели для дат до 1 марта 1900 года. Но такие экзотические значения почти никто не использует, поэтому аномалия живёт, а фантомный 29 февраля 1900-го превратился в мем. 

Тестерский чит, ставший традицией

↑↑↓↓←→←→ B A — узнаёте? Это Konami Code, пожалуй, самый известный чит-код в истории. И начался он как обычный костыль для тестеров.

В 1986 году разработчик Кадзухиса Хасимото портировал аркадную Gradius на NES и понял, что проходить игру во время отладки невозможно — слишком сложно. Чтобы упростить жизнь, он добавил секретную комбинацию, которая сразу выдавала все бонусы. Обычно такие тулы удаляли перед релизом, но в этот раз код в игре остался — то ли по забывчивости, то ли из осторожности.

Игроки быстро нашли комбинацию. Но настоящую славу Konami Code получил годом позже в Contra — заветная последовательность давала 30 жизней. Геймеры были в восторге, а Konami сделала код своей фишкой и начала встраивать его в другие игры. Уже осознанно, как пасхалку.

Так простой костыль для разработчика превратился в культурный феномен. Сегодня Konami Code встречается не только в играх, но и на сайтах, вроде Google.

Космический костыль для памяти

В 2014 году инженерам NASA пришлось изобретать настоящий костыль, чтобы продлить жизнь марсохода Opportunity. По плану он должен был работать 90 дней, но к тому моменту бороздил Марс уже одиннадцатый год. Научная аппаратура оставалась в строю, а вот компьютер начал «забывать».

Флэш-память ровера из семи банков постепенно деградировала — один из них стал выдавать ошибки. Opportunity пытался записать данные, перезагружался и переходил в безопасный режим. Каждый раз это означало потерю времени и иногда целого дня научных данных. Бывало, что сбой приходился на выходные или праздники, когда команда на Земле не дежурила, тогда ровер простаивал по несколько суток.

Поменять микросхему на Марсе невозможно, зато можно обмануть софт. Сначала инженеры перевели ровер в режим без флэш-памяти: всё писалось только в оперативку и срочно передавалось на Землю до наступления марсианской ночи. 

После NASA пошло дальше. В прошивку внесли изменения так, чтобы компьютер просто «забыл» про сбойный банк памяти. Opportunity стал считать, что у него шесть банков вместо семи, и больше не пытался писать в проблемный участок. Команда отправила патч на Марс, ровер переразметил флэш — и проблема исчезла.

Костыль оказался идеальным: Opportunity продолжил сохранять данные уже на шести банках и проработал ещё несколько лет, вплоть до 2018 года. 

Специальный код для SimCity

Когда Microsoft готовила Windows 95, под Windows 3.x накопились тысячи программ, и пользователи не простили бы, если бы любимые приложения вдруг перестали запускаться.

Самый известный костыль той эпохи — история с SimCity. Культовая игра для Windows 3.x имела баг: при старте она случайно читала память, которую только что сама освободила. На старой архитектуре это не мешало, так как система держала память чуть дольше, и игра работала. Но в Windows 95 менеджер памяти стал 32-битным и вёл себя иначе. В бета-версиях новая ОС просто роняла SimCity.

Исправить игру было невозможно — код уже устарел, да и нельзя требовать от пользователей покупать «правильную» версию. Тогда в Microsoft пошли на радикальное решение — прямо в ядро Windows 95 встроили проверку. Если запускалась SimCity, система переключала менеджер памяти в особый режим и задерживала освобождение памяти, чтобы игра не падала.

Для пользователей это выглядело магией. На деле же внутри ОС прятался костыль, написанный ради одного конкретного приложения.

SimCity была не единственной. В Windows 9x и NT подобных хаков набралось немало. Microsoft действительно была одержима обратной совместимостью и тратила ресурсы на то, чтобы старый софт жил дальше. 

Глобальный замок на 30 лет

Один из самых известных «вечных костылей» в разработке — это GIL в Python. Global Interpreter Lock появился в начале 90-х как простой способ добавить многопоточность. Для того времени это был разумный компромисс. Python управлял памятью через подсчёт ссылок, а синхронизировать каждую операцию было бы слишком сложно. Да и язык в основном использовался в однопоточных задачах, про многоядерные процессоры мало кто думал.

Но годы прошли, компьютеры обзавелись десятками ядер, а GIL остался. Он стал «узким горлышком» для многопоточных приложений, но убрать его оказалось почти невозможно. Слишком много кода и библиотек завязано на эту особенность.

Сообщество спорило об этом десятилетиями. Появлялись патчи, форки вроде PyPy или GIL-less Python, но официальный интерпретатор оставался однопоточным. Лишь в 2023 году PEP 703 предложил собрать Python без глобальной блокировки. И всё же в 2025-м стандартный Python всё ещё живёт с GIL.

Жить в костылях или исправлять?

Даже самые крупные компании не застрахованы от костылей. Иногда именно грязный хак спасает проект или, наоборот, становится частью продукта. Его боятся тронуть, и времянка превращается в норму.

С железом у админов таких историй хватает. Кто-то подвешивал диски на кабелях в серверах, потому что не хватало места, кто-то крепил SSD на липучку или просто вставлял его в картонную коробку. Другие «чудеса инженерной мысли» описал тут

В софте всё то же самое. Вместо поиска утечки памяти или настоящей причины зависания некоторые ставили ночной ребут и даже Docker «лечили» перезагрузкой. Кто-то умудрялся автоматизировать развёртывание VDS на VMware, где не поддерживалась AlmaLinux через смену названия на CentOS. А другие вовсе «убирали» ограничения совместимости с помощью эмулятора для ретро-игр. 

Жить в костылях или чинить — универсального ответа нет. Иногда временное решение спасает сроки и годами честно держит прод. Но все знают, что любой хак однажды напомнит о себе.

А какие костыли встречались у вас? Делитесь историями в комментариях.

© 2025 ООО «МТ ФИНАНС»

Комментарии (0)


  1. VBKesha
    17.09.2025 10:56

    Игроки быстро нашли комбинацию.

    Как они это сделали? Дизасемблировали картридж? Или методом тыка? Или его нечаянно слили для какой нибудь книги секретов?


    1. SrvTrantor Автор
      17.09.2025 10:56

      К сожалению, неизвестно. Может, методом тыка, так как в 8-битках всегда искали пасхалки, а может, какой-нибудь тестировщик знал про него и слил