Original: artículo " Lo que aprendí como desarrollador de accidentes en el espacio ", de Andrei Sitnik, del blog de Evil Martians " Martian Chronicles "

Andrei Sitnik, autor de PostCSS y AutoPrefixer , hizo una selección de historias relacionadas con la exploración espacial por parte de la Unión Soviética. Aprenderá qué lecciones ha aprendido Andrei de ellos para crecer como desarrollador y participante en el movimiento de código abierto. Atraque fallido, entrada dramática a la atmósfera y una transición única a lo largo del carril entre naves espaciales: ¿qué tiene que ver todo esto con el desarrollo web moderno? ¡Lee sobre todo esto en una publicación!

La exploración espacial me interesó tanto como recuerdo. Las personas que me conocieron personalmente escucharon más sobre el espacio de lo que les gustaría. Antes de unirme a Evil Martians, administré la versión en ruso de Wikipedia, y uno de mis pasatiempos favoritos era editar artículos relacionados con el espacio. Fui a ver los lanzamientos en Baikonur y Cabo Cañaveral, y cuanto más aprendí sobre los esfuerzos de exploración espacial, más me influyó este conocimiento como desarrollador.

Aunque escribir programas no es tan difícil como construir cohetes (en su mayor parte), nosotros, los ingenieros de software, a menudo trabajamos en grandes equipos creando sistemas complejos. Y como exploradores del espacio, a veces perdemos la lucha contra la complejidad.

“Un inicio de emergencia nos brinda mucho más para conocer y mejorar el sistema que docenas de sistemas exitosos”

- Nikolai Pilyugin, académico, diseñador, especialista en el campo de los sistemas de control autónomo para complejos de cohetes y cohetes espaciales.

En cada programa espacial, ocurren errores, no todos son trágicos. En este artículo hablaré sobre ejemplos de la historia soviética y rusa de la exploración espacial, que son poco conocidos fuera de la comunidad entusiasta (estamos hablando de la comunidad occidental - aprox. Transl.). Estas historias terminaron bien.

Primera lección: nunca culpes a los usuarios *

* ... y hacer cambios a cada una de sus apelaciones.

A fines de la década de 1960, Estados Unidos y la URSS completaron el trabajo en una nueva generación de naves espaciales. Apolo y la Unión dieron un gran paso adelante después de los experimentos Mercury / Gemini y East / Sunrise. Las nuevas naves fueron diseñadas para funcionar no solo en órbitas cercanas a la Tierra, sino también para vuelos a la luna y de regreso.

En octubre de 1968, la URSS se recuperó del desastre de Soyuz-1 y estaba lista para hacer un nuevo intento: se planeó por primera vez realizar el atraque manual de dos barcos en órbita. Se suponía que la Soyuz-2 automática iría primero al espacio. Entonces Georgy Beregovoi en Soyuz-3 debía entrar en la misma órbita y atracar las naves.


El piloto de Soyuz-4, Soyuz-8 y Soyuz-10 Vladimir Shatalov demuestra el atraque de dos barcos.

El lanzamiento fue bien. Después de solo 1,5 horas, Soyuz-3 estaba a una distancia de atraque. La maniobra fue planeada para la "noche", a la sombra de la Tierra. Sin embargo, todos los intentos de acoplamiento manual terminaron sin éxito.

Y solo cuando ambas naves estaban en el lado del día, Beregovoi descubrió un error: Soyuz-2 se rotó 180 grados a lo largo del eje longitudinal.

Como en ese momento todos los suministros de combustible se habían agotado para los intentos de atraque, Beregovoi recibió la orden de completar la misión y regresar a la Tierra cuatro días después. Los periódicos calificaron el vuelo como exitoso, Beregovoy recibió el título de Héroe de la Unión Soviética y pronto fue promovido. Sin embargo, se aprendieron las lecciones correctas de esta historia, y se introdujeron nuevas reglas para todas las uniones posteriores:

• Atraca solo en el lado soleado.
  
• No planee atracar en un día con el lanzamiento, para que los pilotos tengan tiempo de aclimatarse en órbita.
  

Dock Soyuz-4 en la película "Cuatro en el espacio" .

Recuerde esta historia cuando inserte el conector USB Tipo A nuevamente en el lado equivocado.

No hay malos usuarios, hay una mala interfaz.

Es fácil culpar a los usuarios. Sin embargo, la gente siempre estará equivocada. Los desarrolladores no son la excepción. Como participante en el movimiento de código abierto, me di cuenta de que si culpas a los desarrolladores por los errores, todavía no ayudará a evitar errores en el futuro.

Al cerrar un problema sobre un problema en su repositorio de código abierto con una respuesta grosera de estilo RTFM (o, peor aún, ¡ninguna respuesta!), No se protegerá de la aparición del mismo problema. Recibirá los mismos mensajes una y otra vez.

Como creador de PostCSS y Auto Prefixer, recibo muchos informes de problemas . Para no perder el tiempo a largo plazo, sigo la regla: cada problema debe conducir a un cambio en el código o la documentación .

Lo mejor es mejorar la experiencia del usuario, UX (desde el punto de vista de la biblioteca de código abierto, será una API) para que en el futuro sea imposible cometer el mismo error. En el peor de los casos, puede agregar una advertencia.

Por ejemplo, muchos usuarios de PostCSS se olvidan de la opción del analizador e intentan procesar archivos .less y .scss sin los analizadores correspondientes. En lugar de culpar a los usuarios, agregamos una pequeña advertencia:

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' } 

Segunda lección: por supuesto, informar al desarrollador sobre los problemas

Tres meses después del vuelo de Soyuz-2 y Soyuz-3, la URSS estaba lista para un nuevo intento de atraque manual, aún más ambicioso.

Se planeó lanzar dos naves espaciales tripuladas con una diferencia de un día: Soyuz-4 con un astronauta y Soyuz-5 con tres. Después de atracar, el ingeniero piloto y el ingeniero de investigación de Soyuz-5 debían atravesar el espacio abierto hacia Soyuz-4 y regresar a la Tierra. Es decir, despegaron en una nave, pasearon por el espacio y aterrizaron en otra nave.


Transición a través del espacio exterior de Soyuz-5 a Soyuz-4.

Boris Volynov , un piloto de Soyuz-5, debía permanecer solo y regresar a la Tierra un día después.

Esta vez el acoplamiento fue exitoso, Soyuz-4 completó su misión sin ningún problema. Y el 18 de enero de 1969, llegó el momento de regresar a casa y a Volynov. La unión consta de tres módulos desmontables, y solo uno, el central, fue diseñado para entrar en la atmósfera.


Esquema sindical. Fuente: NASA

Durante el regreso de Volynov, el módulo agregado de instrumentos no se separó normalmente. Era demasiado tarde para interrumpir el aterrizaje. La nave espacial entró en la atmósfera con una orientación incorrecta en el espacio: nariz delantera. El flujo entrante se oponía solo por una delgada escotilla de entrada, el escudo térmico estaba en la parte posterior, entre los módulos que no estaban divididos.

El sello alrededor de la escotilla comenzó a arder, la cápsula de aterrizaje comenzó a llenarse de humo tóxico. La gravedad y la atmósfera hicieron su trabajo; el indefenso Volynov estaba atado a una silla.


Imagen artística de la entrada a la atmósfera de la Unión-4.

Sin embargo, el calor que podría matar a Volynov lo salvó inesperadamente: los tanques de combustible del módulo del instrumento explotaron y, como resultado, se separaron. La cápsula de aterrizaje se volvió a la posición correcta, el escudo térmico hacia adelante.

Todo este tiempo, Volynov, confiado en que estaba viviendo los últimos minutos, grabó en voz alta todo lo que ve y oye.

Los problemas no terminaron ahí. Las eslingas de paracaídas se enredaron y los suaves motores de aterrizaje no funcionaron. La cápsula golpeó el suelo a gran velocidad lejos del área planificada. El herido Volynov tuvo que sobrevivir en el frío a -38 ° C hasta que los rescatistas lo alcanzaron.

El astronauta comentó en voz alta cada sonido y vibración, esperando que la grabadora de vuelo sobreviviera al accidente y los ingenieros pudieran escuchar las grabaciones y prevenir nuevos desastres.

¿Qué me enseñó esta historia digna de una adaptación cinematográfica de Hollywood?

Cada vez que encuentro un problema asociado con una biblioteca o herramienta de desarrollo, recuerdo a Boris Volynov. Si pudo informar problemas incluso al borde de la muerte, entonces definitivamente puedo tomar unos minutos para enviar un informe al desarrollador.

Incluso un informe simple puede ser una gran contribución al proyecto.

Debido al síndrome de impostor que impregna nuestra industria, con demasiada frecuencia nos encontramos culpables de los problemas que surgen. Algo se perdió en la documentación, o simplemente no era lo suficientemente inteligente. Pero no se olvide de la lección de la primera historia: no hay malos usuarios, solo hay una mala interfaz. Y no hay malos desarrolladores, solo hay malas herramientas de desarrollo.

Si cometió un error al usar el marco, entonces probablemente no sea el primero ni el último. Además, miró el producto desde una perspectiva que los desarrolladores no vieron, que ven el código todos los días. Una nueva mirada hace que sea más fácil notar problemas en la documentación y en la experiencia de desarrollo general.

¿Hizo un error tipográfico, recibió un mensaje de error incomprensible y, como resultado, pasó una hora depurando? Esta es una gran oportunidad para mejorar el mensaje de error con el nuevo problema o PR. ¿Buscas un camino por la biblioteca durante demasiado tiempo? Piense qué información en la documentación le ayudaría.

Tercera lección: automatización de confianza

Esta historia sucedió en 1997 con la ya desaparecida Estación Espacial Mir .

Hubo una diferencia importante entre los programas espaciales soviéticos y estadounidenses. En la URSS, los barcos fueron creados por las mismas personas que crearon los cohetes: hicieron un uso extensivo de la automatización y consideraron a los pilotos prácticamente una carga. Y en los Estados Unidos, las naves (en particular, el transbordador espacial) fueron creadas por personas que diseñaron aviones, y consideraron las computadoras solo como herramientas auxiliares para los pilotos.

Desde 1967, la URSS ha utilizado sistemas de acoplamiento totalmente automáticos: primero, Igloo, luego Course. Estos desarrollos hicieron posible construir la estación Mir a partir de módulos automáticos que actúan como naves espaciales independientes con sus propias computadoras, sistemas de energía y motores.


Módulos de la estación Mir.

Sin embargo, los sistemas de atraque soviéticos se fabricaron en Ucrania, y después del colapso de la URSS, Moscú y Kiev no acordaron los precios. Roscosmos, tratando de reducir su dependencia de componentes extraños, desarrolló una alternativa: TORU , que permitió al operador de la estación espacial controlar de forma remota la nave utilizando dos joysticks.

TORU probado con éxito en el espacio. En 1997, el barco Progress M-34 con carga para la estación atracó con éxito automáticamente en el mundo. Y luego, inesperadamente, hubo una instrucción para desacoplarlo y, en lugar de regresar a la Tierra, volver a acoplarlo a la estación manualmente para verificar nuevamente el sistema de acoplamiento.


Vasily Tsibliev controla el barco desde la estación Mir.

La tripulación intentó mantener el control del Progreso sobrecargado (transportaba el siguiente lote de desechos de la estación, que tuvo que ser devuelto a la Tierra), y fue difícil detectar a Mir en el video transmitido desde la nave. Cuando los astronautas finalmente vieron el barco que se acercaba por las ventanas, ya era demasiado tarde para reducir la velocidad. La nave dañó el panel solar del módulo Spectrum, que proporcionó el 40% de la electricidad de la estación, e hizo un agujero en el casco.

Los astronautas escucharon un silbato y se les taparon los oídos. La estación estaba perdiendo aire.

La tripulación tuvo que desconectar los cables provenientes del Spectrum, cerrar el módulo y dejarlo sin sellar. Y tres años después, la estación se inundó en el océano.

Como resultado, el curso no ha sido abandonado del sistema de acoplamiento; hoy se está fabricando en Rusia. El curso y TORU se utilizan en barcos rusos, TORU es un sistema de respaldo.

Hasta el día de hoy, las razones de la primera y hasta ahora la única colisión en el espacio no están del todo claras . El centro de masa del barco se movió debido a la sobrecarga, los astronautas estaban cansados ​​y mal poseídos por TOPU. La prueba en sí se organizó a toda prisa: en ese momento, un astronauta estadounidense estaba a bordo del mundo, y ni él ni la NASA sabían sobre la prueba hasta que la estación se despresurizó.


Daño al mundo después de una colisión con el Progress M-34 en 1997.

Esta historia me recordó el famoso script para instalar controladores para una tarjeta de video que destruyó los sistemas Linux . El desarrollador de la biblioteca agotado, que trabajaba de noche, se perdió solo una brecha:

  # 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 

La gente está equivocada. Prefiero la automatización. ¡Los autos deben sufrir!

Sigo la regla: si ve el mismo error dos veces en su código fuente, es mejor hacer una herramienta automatizada que pueda prevenir este error en el futuro.

Los linters de código fuente (como ESLint para JavaScript y Stylelint para CSS) encuentran muy bien errores que pueden costarle mucho tiempo y dinero. Pasará varias horas escribiendo su propio complemento de linter, pero a la larga dará sus frutos.

¿Quiere evitar errores tipográficos en la documentación? Prueba con yaspeller . ¿Desea organizar las propiedades en CSS en algún orden? Agregue stylelint-order a sus herramientas de desarrollo.

* * *

Espero que hayan disfrutado mis historias espaciales. Incluso si le parecían extravagantes, las lecciones aprendidas siguen siendo útiles para todos los desarrolladores de software.

La historia de la exploración espacial no solo es la inspiración para mis historias en conferencias y fiestas posteriores, sino que también sirve como fuente de las técnicas correctas. ¿Qué te recuerda mejor la necesidad de enviar un informe sobre el problema que una nave espacial en llamas?