Исследования космоса интересовали меня, сколько я себя помню. Люди, знавшие меня лично, слышали рассказов о космосе больше, чем им хотелось бы. Я администрировал русскоязычную версию Википедии, и одним из моих любимых увлечений была редактура связанных с космосом статей. Я лично наблюдал за запусками на Байконуре и мысе Канаверал, и чем больше я узнавал об усилиях по покорению космоса, тем сильнее эти знания влияли на меня как на разработчика.
Хотя писать программы не так сложно, как строить ракеты (по большей части), но всё же мы, программные инженеры, часто работаем в больших командах, создающих сложные системы. И как исследователи космоса, иногда мы проигрываем борьбу со сложностью.
Один неудачный запуск рассказывает нам о системах и управлении ими больше, чем десять беспроблемных запусков.
— Николай Пилюгин, академик, конструктор, специалист в области систем автономного управления ракетными и ракетно-космическими комплексами.
В каждой космической программе случаются ошибки, не все из них трагические. В этой статье я расскажу о примерах из советской и российской истории освоения космоса, которые мало известны вне сообщества энтузиастов. Некоторые истори законичились хорошо.
Первый урок: никогда не обвиняй пользователей*
* …и вноси изменения по каждой проблеме.
В конце 1960-х США и СССР завершили работу над новым поколением космических кораблей. Apollo и Союз стали большим шагом вперёд после экспериментальных Mercury/Gemini и Восток/Восход. Новые корабли были спроектированы для работы не только на околоземных орбитах, но и для полётов на Луну и обратно.
В октябре 1968-го СССР оправился от катастрофы Союза-1 и был готов сделать новую попытку: планировалось впервые выполнить на орбите ручную стыковку двух кораблей. Автоматический Союз-2 должен был отправиться в космос первым. Затем Георгий Береговой на Союзе-3 должен был выйти на ту же орбиту и состыковать корабли.
Десятый космонавт Владимир Шаталов демонстрирует стыковку Союза-4 и Союза-8.
Запуск прошёл хорошо. Всего через 1,5 часа Союз-3 оказался на расстоянии стыковки. Манёвр был запланирован на «ночное» время, в тени Земли. Однако все попытки ручной стыковки закончились безуспешно.
И только когда оба корабля оказались на дневной стороне, Береговой обнаружил ошибку: Союз-2 был повёрнут вдоль продольной оси на 180 градусов.
Поскольку к тому времени все запасы топлива были израсходованы на попытки стыковки, Береговому приказали завершить миссию и вернуться через четыре дня на Землю. Газеты назвали полёт успешным, Береговому присвоили звание Героя Советского Союза и вскоре повысили. Однако из этой истории были извлечены правильные уроки, и для всех последующих стыковок были введены новые правила:
- Стыковаться только на солнечной стороне.
- Не планировать стыковку в один день с запуском, чтобы пилоты успели скорректировать орбиту.
Стыковка Союза-4 в фильме «Четверо в космосе».
Вспоминайте об этой истории, когда будете в очередной раз вставлять штекер USB Type-A не той стороной.
Нет плохих пользователей — есть плохой пользовательский опыт.
Легко обвинять пользователей. Однако люди всегда будут ошибаться. Разработчики не исключение. Как участник opensource-движения, я понял, что если винить разработчиков за ошибки, то это всё равно не поможет предотвратить ошибки в будущем.
Закрывая issue о проблеме в своём opensource-репозитории грубым ответом в стиле RTFM (или, того хуже, вообще без ответа!), вы не защитите себя от появления такой же issue. Вы будете раз за разом получать одни и те же сообщения.
Как создатель PostCSS и Autoprefixer, я получаю много сообщений о проблемах. Чтобы в долгосрочной перспективе не тратить время зря, я следую правилу: каждая проблема должна приводить к изменению кода или документации.
Лучше всего улучшать пользовательский опыт, UX (с точки зрения opensource-библиотеки это будет API), чтобы в будущем невозможно было совершить ту же ошибку. На худой конец можете добавить предупреждение.
К примеру, многие пользователи PostCSS забывают об опции парсинга и пытаются обрабатывать файлы .less и .scss без соответствующих парсеров. Вместо того, чтобы обвинять пользователей, мы добавили маленькое предупреждение:
if (error.name === 'CssSyntaxError' && opts.from.endsWith(‘.scss’)) {
error.message += 'nYou tried to parse SCSS with ' +
'the standard CSS parser; ' +
'try again with the postcss-scss parser'
}
Второй урок: во что бы то ни стало сообщайте о проблемах
Через три месяца после полёта Союза-2 и Союза-3 СССР был готов к новой попытке ручной стыковки, ещё более амбициозной.
Планировалось с разницей в один день запустить два пилотируемых корабля: Союз-4 с одним космонавтом и Союз-5 с тремя. После стыковки инженер-пилот и инженер-исследователь из Союза-5 должны были через открытый космос перейти в Союз-4 и вернуться на Землю. То есть взлетели в одном корабле, прогулялись в космосе, приземлились на другом корабле.
Переход через открытый космос Союза-5 в Союз-4.
Борис Волынов, пилот Союза-5, должен был остаться один и вернуться на Землю день спустя.
В этот раз стыковка прошла успешно, Союз-4 без проблем завершил свою миссию. И 18 января 1969-го пришла пора вернуться домой и Волынову. Союз состоит из трёх отделяемых модулей, и лишь один, центральный, был предназначен для входа обратно в атмосферу.
Схема Союза.
В ходе возвращения Волынова приборно-агрегатный модуль не отделился штатно. Было уже слишком поздно прерывать посадку. Космический корабль вошёл в атмосферу с неправильной ориентацией в пространстве: носом вперёд. Набегающему потоку противостоял лишь тонкий входной люк, тепловой щит был сзади, между не разделившимися модулями.
Уплотнение вокруг люка начало гореть, посадочная капсула начала заполняться ядовитым дымом. Гравитация и атмосфера выполняли свою работу, беззащитный Волынов был пристёгнут в кресле.
Художественное изображение входа в атмосферу Союза-4.
Однако жар, который мог убить Волынова, неожиданно спас его: взорвались топливные баки приборного модуля, и в результате тот отделился. Посадочная капсула повернулась в правильное положение, тепловым щитом вперёд.
Всё это время Волынов, уверенный, что доживает последние минуты, описывал вслух всё, что видит и слышит.
На этом проблемы не закончились. Парашютные стропы запутались, а двигатели мягкой посадки не сработали. Капсула с высокой скоростью ударилась о землю далеко от запланированного района. Раненому Волынову пришлось выживать на морозе в −38 °C, пока до него не добрались спасатели.
Космонавт громко комментировал каждый звук и вибрацию, надеясь, что бортовой самописец переживёт крушение и инженеры смогут прослушать записи и предотвратить новые катастрофы.
Чему меня научила эта история, достойная голливудской экранизации?
Каждый раз, сталкиваясь с проблемой, связанной с библиотекой или инструментом для разработки, я вспоминаю Бориса Волынова. Если он смог сообщать о проблемах даже на пороге смерти, то я точно смогу выделить несколько минут, чтобы отправить отчёт на Github.
Даже простой отчёт может оказать большую помощь.
Из-за синдрома самозванца, пронизывающего нашу отрасль, мы слишком часто считаем себя виноватыми в возникающих проблемах. Что-то упустили в документации, или просто не были достаточно умны. Но не забывайте об уроке из первой истории: нет плохих пользователей, есть только плохой пользовательский опыт. И нет плохих разработчиков, есть только плохой опыт разработки.
Если вы сделали в каком-то фреймворке ошибку, то вы, вероятно, не первый и не последний. К тому же вы посмотрели на продукт с такой перспективы, которую упустили разработчики, которые видят код каждый день. Свежий взгляд позволяет легче замечать проблемы в документации и общем опыте разработки.
Вы сделали опечатку, получилось непонятное сообщение об ошибке и в результате вы потратили час на отладку? Это прекрасная возможность улучшить сообщение об ошибке с помощью нового отчёта или PR. Слишком долго ищете способ обойти библиотеку? Подумайте, какая информация в документации помогла бы вам.
Третий урок: доверяйте автоматизации
Эта история произошла в 1997 суже не существующей космической станцией Мир.
Между советской и американской космической программой было одно важное различие. В СССР корабли создавали те же люди, которые создавали ракеты: они широко использовали автоматику и считали пилотов практически обузой. А в США корабли (в частности, Space Shuttle) создавали люди, которые проектировали самолёты, и они считали компьютеры лишь вспомогательными инструментами для пилотов.
СССР с 1967-го использовал полностью автоматические системы стыковки: сначала Иглу, затем Курс. Эти разработки позволили построить станцию Мир из автоматических модулей, которые действуют как независимые космические аппараты с собственными компьютерами, энергосистемами и двигателями.
Модули станции Мир.
Однако советские стыковочные системы производились на Украине, и после распада СССР Москва и Киев не договорились о ценах. Роскосмос, стараясь уменьшить зависимость от иностранных комплектующих, разработал альтернативу — ТОРУ, которая позволяла оператору на космической станции удалённо управлять кораблём с помощью двух джойстиков.
ТОРУ успешно испытали в космосе. В 1997-м корабль Прогресс М-34 с грузами для станции успешно автоматически пристыковался к Миру. И тут неожиданно последовало указание отстыковать его, и вместо возвращения на Землю заново пристыковать к станции вручную, чтобы опять проверить систему стыковки.
Василий Циблиев управляет кораблём с борта станции Мир.
Экипаж пытался сохранить управление перегруженным Прогрессом (он нёс очередную партию отходов со станции, который нужно было вернуть на Землю), а на передаваемом с корабля видео трудно было обнаружить Мир. Когда космонавты наконец увидели в иллюминаторы приближающийся корабль, тормозить было уже поздно. Корабль повредил солнечную панель модуля Спектр, которая обеспечивала 40 % электроэнергии станции, и проделал дыру в корпусе.
Космонавты услышали свист и у них заложило уши. Станция теряла воздух.
Экипажу пришлось отключить кабели, идущие со Спектра, закрыть и покинуть разгерметизированный модуль. А три года спустя станция была затоплена в океане.
В результате от стыковочной системы Курс так и не отказались, сегодня она производится в России. Курс и ТОРУ используются на российских кораблях, ТОРУ является запасной системой.
По сей день не совсем ясны причины первого и пока единственного столкновения в космосе. Центр массы корабля был смещён из-за перегрузки, космонавты были утомлены и плохо владели ТОРУ. Само испытание было организовано в спешке: в тот момент на борту Мира находился американский астронавт, и ни он, ни НАСА не знали об испытании, пока станция не оказалась разгерметизирована.
Повреждения Мира после столкновения с Прогрессом M-34 в 1997-м.
Эта история напомнила мне знаменитый скрипт установки драйверов для видеокарты, который уничтожал Linux-системы. Измученный разработчик библиотеки, работавший ночью, пропустил всего один пробел:
# GIANT BUG... causing /usr to be deleted... so sorry....
- rm -rf /usr /lib/nvidia-current/xorg/xorg
+ rm -rf /usr/lib/nvidia-current/xorg/xorg
<i>Люди ошибаются. Лучше применяйте автоматизацию. Пусть работают роботы!
Я следую правилу: если дважды видишь в своём исходном коде одну же ошибку, то лучше сделать автоматизированный инструмент, который сможет предотвратить эту ошибку в будущем.
Линтеры исходного кода (вроде ESLint для JavaScript и Stylelint для CSS) очень хорошо находят ошибки, которые могут стоить вам много времени и денег. Вы потратите несколько часов на написание своего плагина для линтеров, но в долгосрочной перспективе это окупится.
Хотите избегать опечаток в документации? Попробуйте yaspeller. Хотите навести порядок в CSS-файлах? Добавьте в зависимости среды разработки stylelint-order.
* * *
Надеюсь, вам понравились мои космические истории. Даже если они показались вам надуманными, извлечённые уроки остаются полезными для всех разработчиков ПО.
История освоения космоса не только даёт мне темы для разговоров с друзьями, но и служит источником правильных методик. Что лучше напомнит о необходимости отправить отчёт о проблеме, чем горящий космический корабль?
Автор: Макс
