Есть функция в коде, которую никто не смеет переписывать. Написал её программист лет двадцать назад, потом уволился, и теперь все боятся - вдруг что-то сломается. Смешно, да? А теперь представьте, что такая же ситуация в NASA, только ставки чуть выше - не упавший сайт, а космический корабль с людьми на борту. В агентстве действительно существует код, к которому программистам запрещено прикасаться. Причём речь не о какой-то древней системе на пенсии, а о работающем софте для космических миссий. Давайте разберёмся, что это за легендарный код и почему его не трогают уже десятилетия.
Legacy code - наследие прошлого
Термин legacy code звучит как что-то из музея, но на деле это просто старый код, который продолжает работать в действующих системах. В NASA таких систем полно, и некоторые из них пишутся на языках программирования, которые современные разработчики видели только в учебниках истории.
Взять тот же Shuttle program - программа космических шаттлов. Там использовался код на языке HAL/S, созданном специально для космической отрасли в 1970-х. Представьте: языку почти полвека, а его всё ещё нельзя было заменить, пока шаттлы летали.
Почему не переписать на что-то современное? А вот тут начинается самое интересное. Этот код тестировался годами, проверялся в реальных полётах, отлаживался после каждого инцидента. Он стабилен именно потому, что прошёл через огонь, воду и вакуум космоса.
Я читал интервью с программистом NASA, который говорил: «Мы знаем каждый баг в этой системе. Мы знаем, как она отреагирует в любой ситуации. Если переписать - получим новые баги, которых мы не знаем. А это может стоить жизней».
Код, написанный Маргарет Хэмилтон
Вот реальная история, которая меня поразила. Маргарет Хэмилтон - она написала программное обеспечение для Apollo 11, того самого полёта на Луну в 1969 году. Код был на ассемблере, каждая строчка проверялась вручную, потому что отладчиков и современных инструментов тогда не было.
Часть этого кода использовалась в последующих миссиях Apollo. И знаете что? Некоторые принципы и алгоритмы из того древнего софта до сих пор применяются в современных системах NASA. Не сам код построчно, конечно, но подходы к обработке критических ситуаций.
Хэмилтон придумала систему приоритетов задач, которая спасла миссию Apollo 11. Во время посадки компьютер перегрузился лишними вычислениями, начали сыпаться ошибки. Но благодаря её коду система отбросила второстепенные задачи и сосредоточилась на посадке. Это сработало.
Этот принцип - приоритезация критичных операций - вшит в космическое ПО до сих пор. Трогать его боятся, потому что он доказал свою надёжность в условиях, когда на кону были жизни людей.
«Лучший код - тот, который работает. А лучший космический код - тот, который работает и не убивает астронавтов».
Проблема замены: зачем чинить то, что не сломано
Программисты любят переписывать код. Это факт. Видим старую функцию - руки чешутся её оптимизировать, сделать элегантнее, быстрее. Но в критических системах это опасная игра.
В NASA есть правило: если система работает стабильно, не трогай её без крайней необходимости. Даже если код выглядит как макароны, даже если его писали во времена динозавров. Потому что каждое изменение - это риск.
Был случай с Mars Rover в 1999 году. Программисты обновили софт, чтобы исправить мелкий баг. В результате новая версия вызвала цепочку ошибок, и марсоход потерял связь с Землёй. Миссия стоимостью $125 миллионов провалилась.
После этого подход NASA стал ещё консервативнее. Теперь любое изменение кода проходит десятки проверок, симуляций, тестов. А старый проверенный код оставляют в покое, даже если он написан на языке, который уже никто не преподаёт в университетах.
Где именно прячется неприкасаемый код
Конкретная система, о которой часто говорят - это софт для International Space Station (МКС). Там работают программы, написанные ещё в 1990-х, когда станцию только строили.
Часть критичных модулей для жизнеобеспечения, навигации, стыковки написана на Ada - языке, который сейчас почти не используется нигде, кроме военной и космической отрасли. Почему Ada? Потому что он создавался специально для надёжных систем, где ошибка стоит слишком дорого.
Эти модули обновляются крайне редко и очень осторожно. Если находят критичный баг - пишут патч, который обходит проблему, но не переписывают систему целиком.
Что это значит для обычных программистов
Может показаться, что это проблема только NASA и космической отрасли. Но на самом деле legacy code - головная боль большинства крупных компаний.
Банки крутятся на системах 1980-х годов. Сотовые операторы используют биллинг-системы, написанные тридцать лет назад. Большие корпорации тащат за собой код, который никто не понимает полностью, но все боятся трогать.
Я сам сталкивался с таким на проектах. Приходишь в компанию, тебе показывают кодовую базу и говорят: «Вот эта часть работает, но мы не знаем как. Предыдущий разработчик уволился пять лет назад. Ты можешь добавить новые фичи, но эту часть не трогай».
Что делать в такой ситуации? Есть несколько стратегий:
Постепенная замена. Пишешь новый код рядом, переносишь функционал по частям, тестируешь каждый шаг. Долго, но безопасно.
Обратная разработка. Изучаешь старый код, пишешь документацию, разбираешься во всех нюансах. Только потом трогаешь.
Изоляция. Оборачиваешь старый код в новый интерфейс. Старая система работает как чёрный ящик, а вокруг неё строишь современную архитектуру.
В NASA применяют все три подхода, но очень медленно и осторожно. Потому что цена ошибки слишком высока.
История с неприкасаемым кодом в NASA - это напоминание о том, что в технологиях «новое» не всегда значит «лучше». Иногда старый, проверенный временем код надёжнее любой современной разработки.
Я не призываю писать плохо и не документировать, надеясь, что код будет жить вечно. Но есть урок: критичные системы требуют уважения к тому, что уже работает. Переписывать ради переписывания - плохая идея.
В следующий раз, когда захотите выбросить старый код и написать всё с нуля «по-современному», подумайте: а вдруг вы пишете софт для NASA? Ваш код может пережить вас и работать десятилетиями. Так напишите его так, чтобы будущие программисты не боялись к нему прикасаться, а понимали, что вы делали и почему.
📖 Читайте также:
→ Одна строка кода взорвала ракету за $7 млрд: катастрофа Ariane-5
→ Баг с годом 2038, который до сих пор пугает инженеров
→ Загадочные файлы UNIX-серверов 90-х: что они скрывают и зачем были созданы