Оригинал: статья «What I learned as a developer from accidents in space», Андрея Ситника, из блога Evil Martians «Martian Chronicles»
Андрей Ситник, автор PostCSS и Автопрефиксера, сделал подборку историй, связанных с освоением космоса Советским Союзом. Вы узнаете, какие уроки из них извлёк Андрей, чтобы вырасти как разработчик и участник опенсорс-движения. Неудачная стыковка, драматический вход в атмосферу и уникальный переход вдоль поручня между космическими кораблями — какое отношение всё это имеет к современной веб-разработке? Обо все этом читайте в посте!
Исследования космоса интересовали меня, сколько я себя помню. Люди, знавшие меня лично, слышали рассказов о космосе больше, чем им хотелось бы. До того, как присоединиться к Evil Martians, я администрировал русскоязычную версию Википедии, и одним из моих любимых увлечений была редактура связанных с космосом статей. Я ездил наблюдать за запусками на Байконуре и мысе Канаверал, и чем больше я узнавал об усилиях по покорению космоса, тем сильнее эти знания влияли на меня как на разработчика.
Хотя писать программы не так сложно, как строить ракеты (по большей части), но всё же мы, программные инженеры, часто работаем в больших командах, создающих сложные системы. И как исследователи космоса, иногда мы проигрываем борьбу со сложностью.
«Один аварийный пуск дает нам для познания и улучшения системы гораздо больше, чем десяток благополучных»
— Николай Пилюгин, академик, конструктор, специалист в области систем автономного управления ракетными и ракетно-космическими комплексами.
В каждой космической программе случаются ошибки, не все из них трагические. В этой статье я расскажу о примерах из советской и российской истории освоения космоса, которые мало известны вне сообщества энтузиастов (речь идёт про западное сообщество — прим. перев.). Эти истории закончились хорошо.
Первый урок: никогда не обвиняй пользователей*
* …и вноси изменения на каждое их обращение.
В конце 1960-х США и СССР завершили работу над новым поколением космических кораблей. Apollo и Союз стали большим шагом вперёд после экспериментальных Mercury/Gemini и Восток/Восход. Новые корабли были спроектированы для работы не только на околоземных орбитах, но и для полётов на Луну и обратно.
В октябре 1968-го СССР оправился от катастрофы Союза-1 и был готов сделать новую попытку: планировалось впервые выполнить на орбите ручную стыковку двух кораблей. Автоматический Союз-2 должен был отправиться в космос первым. Затем Георгий Береговой на Союзе-3 должен был выйти на ту же орбиту и состыковать корабли.
Пилот Союза-4, Союза-8 и Союза-10 Владимир Шаталов демонстрирует стыковку двух кораблей.
Запуск прошёл хорошо. Всего через 1,5 часа Союз-3 оказался на расстоянии стыковки. Манёвр был запланирован на «ночное» время, в тени Земли. Однако все попытки ручной стыковки закончились безуспешно.
И только когда оба корабля оказались на дневной стороне, Береговой обнаружил ошибку: Союз-2 был повёрнут вдоль продольной оси на 180 градусов.
Поскольку к тому времени все запасы топлива были израсходованы на попытки стыковки, Береговому приказали завершить миссию и вернуться через четыре дня на Землю. Газеты назвали полёт успешным, Береговому присвоили звание Героя Советского Союза и вскоре повысили. Однако из этой истории были извлечены правильные уроки, и для всех последующих стыковок были введены новые правила:
- Стыковаться только на солнечной стороне.
- Не планировать стыковку в один день с запуском, чтобы пилоты успели аклиматизироваться на орбите.
Стыковка Союза-4 в фильме «Четверо в космосе».
Вспоминайте об этой истории, когда будете в очередной раз вставлять штекер USB Type-A не той стороной.
Нет плохих пользователей — есть плохой интерфейс.
Легко обвинять пользователей. Однако люди всегда будут ошибаться. Разработчики не исключение. Как участник опенсорс-движения, я понял, что если винить разработчиков за ошибки, то это всё равно не поможет предотвратить ошибки в будущем.
Закрывая issue о проблеме в своём opensource-репозитории грубым ответом в стиле RTFM (или, того хуже, вообще без ответа!), вы не защитите себя от появления такой же issue. Вы будете раз за разом получать одни и те же сообщения.
Как создатель PostCSS и Автопрефиксера, я получаю много сообщений о проблемах. Чтобы в долгосрочной перспективе не тратить время зря, я следую правилу: каждая проблема должна приводить к изменению кода или документации.
Лучше всего улучшать пользовательский опыт, UX (с точки зрения opensource-библиотеки это будет API), чтобы в будущем невозможно было совершить ту же ошибку. На худой конец можете добавить предупреждение.
К примеру, многие пользователи PostCSS забывают об опции parser и пытаются обрабатывать файлы .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-го пришла пора вернуться домой и Волынову. Союз состоит из трёх отделяемых модулей, и лишь один, центральный, был предназначен для входа обратно в атмосферу.
Схема Союза. Источник: NASA
В ходе возвращения Волынова приборно-агрегатный модуль не отделился штатно. Было уже слишком поздно прерывать посадку. Космический корабль вошёл в атмосферу с неправильной ориентацией в пространстве: носом вперёд. Набегающему потоку противостоял лишь тонкий входной люк, тепловой щит был сзади, между не разделившимися модулями.
Уплотнение вокруг люка начало гореть, посадочная капсула начала заполняться ядовитым дымом. Гравитация и атмосфера выполняли свою работу, беззащитный Волынов был пристёгнут в кресле.
Художественное изображение входа в атмосферу Союза-4.
Однако жар, который мог убить Волынова, неожиданно спас его: взорвались топливные баки приборного модуля, и в результате тот отделился. Посадочная капсула повернулась в правильное положение, теплозащитным экраном вперёд.
Всё это время Волынов, уверенный, что доживает последние минуты, записал вслух всё, что видит и слышит.
На этом проблемы не закончились. Парашютные стропы запутались, а двигатели мягкой посадки не сработали. Капсула с высокой скоростью ударилась о землю далеко от запланированного района. Раненому Волынову пришлось выживать на морозе в −38 °C, пока до него не добрались спасатели.
Космонавт громко комментировал каждый звук и вибрацию, надеясь, что бортовой самописец переживёт крушение и инженеры смогут прослушать записи и предотвратить новые катастрофы.
Чему меня научила эта история, достойная голливудской экранизации?
Каждый раз, сталкиваясь с проблемой, связанной с библиотекой или инструментом для разработки, я вспоминаю Бориса Волынова. Если он смог сообщать о проблемах даже на пороге смерти, то я точно смогу выделить несколько минут, чтобы отправить отчёт разработчику.
Даже простой отчёт может быть большим вкладом в проект.
Из-за синдрома самозванца, пронизывающего нашу отрасль, мы слишком часто считаем себя виноватыми в возникающих проблемах. Что-то упустили в документации, или просто не были достаточно умны. Но не забывайте об уроке из первой истории: нет плохих пользователей, есть только плохой интерфейс. И нет плохих разработчиков, есть только плохие инструменты разработки.
Если при использовании фреймворка вы сделали ошибку, то вы, вероятно, не первый и не последний. К тому же вы посмотрели на продукт с такой перспективы, которую упустили разработчики, которые видят код каждый день. Свежий взгляд позволяет легче замечать проблемы в документации и общем опыте разработки.
Вы сделали опечатку, получилось непонятное сообщение об ошибке и в результате вы потратили час на отладку? Это прекрасная возможность улучшить сообщение об ошибке с помощью нового issue или 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
Люди ошибаются. Предпочитайте автоматизацию. Машины должны страдать!
Я следую правилу: если дважды видишь в своём исходном коде одну и ту же ошибку, то лучше сделать автоматизированный инструмент, который сможет предотвратить эту ошибку в будущем.
Линтеры исходного кода (вроде ESLint для JavaScript и Stylelint для CSS) очень хорошо находят ошибки, которые могут стоить вам много времени и денег. Вы потратите несколько часов на написание своего плагина для линтеров, но в долгосрочной перспективе это окупится.
Хотите избегать опечаток в документации? Попробуйте yaspeller. Хотите организовать свойства в CSS в каком-то порядке? Добавьте в инструменты разработки stylelint-order.
* * *
Надеюсь, вам понравились мои космические истории. Даже если они показались вам притянутыми за уши, извлечённые уроки остаются полезными для всех разработчиков ПО.
История освоения космоса не только вдохновение для моих рассказов на конференциях и афте-пати, но и служит источником правильных методик. Что лучше напомнит о необходимости отправить отчёт о проблеме, чем горящий космический корабль?
