Original: article " Ce que j'ai appris en tant que développeur des accidents dans l'espace ", par Andrei Sitnik, du blog Evil Martians " Martian Chronicles "

Andrei Sitnik, auteur de PostCSS et de l'AutoPrefixer , a fait une sélection d'histoires liées à l'exploration spatiale par l'Union soviétique. Vous apprendrez quelles leçons Andrei en a tirées afin de grandir en tant que développeur et participant au mouvement open-source. Amarrage infructueux, entrée spectaculaire dans l'atmosphère et transition unique le long du rail entre les vaisseaux spatiaux - qu'est-ce que tout cela a à voir avec le développement web moderne? Lisez tout cela dans un article!

L'exploration spatiale m'a autant intéressé que je me souviens. Les gens qui me connaissaient personnellement ont entendu parler de l'espace plus qu'ils ne le souhaiteraient. Avant de rejoindre les Evil Martians, j'ai administré la version russe de Wikipédia, et l'un de mes passe-temps préférés était l'édition d'articles liés à l'espace. Je suis allé voir les lancements à Baïkonour et à Cap Canaveral, et plus j'en apprenais sur les efforts d'exploration spatiale, plus cette connaissance m'influençait en tant que développeur.

Bien que l'écriture de programmes ne soit pas aussi difficile que la construction de fusées (pour la plupart), nous, les ingénieurs logiciels, travaillons souvent en grandes équipes pour créer des systèmes complexes. Et en tant qu'explorateurs de l'espace, nous perdons parfois la lutte contre la complexité.

«Un démarrage d'urgence nous donne beaucoup plus à connaître et à améliorer le système que des dizaines de réussites»

- Nikolai Pilyugin, académicien, designer, spécialiste dans le domaine des systèmes de contrôle autonomes pour les complexes fusée et fusée spatiale.

Dans chaque programme spatial, des erreurs se produisent, elles ne sont pas toutes tragiques. Dans cet article, je parlerai d'exemples de l'histoire soviétique et russe de l'exploration spatiale, qui sont peu connus en dehors de la communauté des passionnés (nous parlons de la communauté occidentale - environ trad.). Ces histoires se sont bien terminées.

Première leçon: ne blâmez jamais les utilisateurs *

* ... et apportez des modifications à chacun de leurs appels.

À la fin des années 1960, les États-Unis et l'URSS ont achevé les travaux sur une nouvelle génération d'engins spatiaux. Apollo et l'Union ont été un grand pas en avant après l'expérimentation Mercury / Gemini et East / Sunrise. Les nouveaux navires ont été conçus pour fonctionner non seulement sur des orbites proches de la Terre, mais aussi pour des vols vers la lune et vers l'arrière.

En octobre 1968, l'URSS se remit de la catastrophe de Soyouz-1 et était prête à faire une nouvelle tentative: il était prévu pour la première fois d'accoster manuellement deux navires en orbite. Le Soyouz-2 automatique devait d'abord entrer dans l'espace. Ensuite, Georgy Beregovoi à Soyouz-3 devait entrer dans la même orbite et amarrer les navires.


Le pilote de Soyouz-4, Soyouz-8 et Soyouz-10 Vladimir Shatalov démontre l'accostage de deux navires.

Le lancement s'est bien passé. Après seulement une heure et demie, Soyouz-3 était à une distance d'amarrage. La manœuvre était prévue pour la nuit, à l'ombre de la Terre. Cependant, toutes les tentatives d'arrimage manuel ont échoué.

Et ce n'est que lorsque les deux navires étaient du côté jour que Beregovoi a découvert une erreur: Soyouz-2 a été tourné de 180 degrés le long de l'axe longitudinal.

Comme à ce moment-là, tous les approvisionnements en carburant avaient été utilisés pour des tentatives d'amarrage, Beregovoi a reçu l'ordre de terminer la mission et de retourner sur Terre quatre jours plus tard. Les journaux ont qualifié le vol de réussi, Beregovoy a reçu le titre de héros de l'Union soviétique et a rapidement été promu. Cependant, les bonnes leçons ont été tirées de cette histoire et de nouvelles règles ont été introduites pour toutes les jointures suivantes:

• Dock seulement sur le côté ensoleillé.
  
• Ne prévoyez pas d'accoster en une journée avec le lancement, afin que les pilotes aient le temps de s'acclimater en orbite.
  

Dock Soyuz-4 dans le film "Four in Space" .

Rappelez-vous cette histoire lorsque vous insérez à nouveau la fiche USB Type-A du mauvais côté.

Il n'y a pas de mauvais utilisateurs - il y a une mauvaise interface.

Il est facile de blâmer les utilisateurs. Cependant, les gens auront toujours tort. Les développeurs ne font pas exception. En tant que participant au mouvement open source, j'ai réalisé que si blâmer les développeurs pour des erreurs, cela ne contribuerait toujours pas à prévenir les erreurs à l'avenir.

En fermant un problème concernant un problème dans votre référentiel opensource avec une réponse grossière de style RTFM (ou, pire, aucune réponse du tout!), Vous ne vous protégerez pas de l'apparition du même problème. Vous recevrez les mêmes messages encore et encore.

En tant que créateur de PostCSS et Auto Prefixer, je reçois beaucoup de rapports de problèmes . Afin de ne pas perdre de temps sur le long terme, je respecte la règle: chaque problème doit entraîner un changement de code ou de documentation .

Il est préférable d'améliorer l'expérience utilisateur, UX (du point de vue de la bibliothèque open source, ce sera une API) de sorte qu'à l'avenir, il serait impossible de faire la même erreur. Au pire, vous pouvez ajouter un avertissement.

Par exemple, de nombreux utilisateurs de PostCSS oublient l'option d'analyse et essaient de traiter les fichiers .less et .scss sans les analyseurs correspondants. Au lieu de blâmer les utilisateurs, nous avons ajouté un petit avertissement:

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

Deuxième leçon: par tous les moyens, informez le développeur des problèmes

Trois mois après le vol de Soyouz-2 et Soyouz-3, l'URSS était prête pour une nouvelle tentative d'accostage manuel, encore plus ambitieuse.

Il était prévu de lancer deux vaisseaux spatiaux habités avec une différence d'un jour: Soyuz-4 avec un astronaute et Soyuz-5 avec trois. Après l'accostage, l'ingénieur pilote et ingénieur de recherche de Soyouz-5 étaient censés traverser un espace ouvert vers Soyouz-4 et retourner sur Terre. Autrement dit, ils ont décollé dans un navire, se sont promenés dans l'espace, ont atterri sur un autre navire.


Transition à travers l'espace extra-atmosphérique de Soyouz-5 vers Soyouz-4.

Boris Volynov , un pilote de Soyouz-5, devait rester seul et retourner sur Terre un jour plus tard.

Cette fois, l'amarrage a réussi, Soyouz-4 a terminé sa mission sans aucun problème. Et le 18 janvier 1969, il était temps de rentrer chez eux et à Volynov. L'union se compose de trois modules détachables et un seul, le central, a été conçu pour pénétrer dans l'atmosphère.


Régime de l'Union. Source: NASA

Lors du retour de Volynov, le module agrégat d'instruments ne s'est pas séparé normalement. Il était trop tard pour interrompre l'atterrissage. Le vaisseau spatial est entré dans l'atmosphère avec une orientation incorrecte dans l'espace: nez avant. Le flux entrant n'était opposé que par une mince trappe d'entrée, le bouclier thermique était à l'arrière, entre les modules qui n'étaient pas divisés.

Le sceau autour de la trappe a commencé à brûler, la capsule d'atterrissage a commencé à se remplir de fumée toxique. La gravité et l'atmosphère ont fait leur travail; le Volynov sans défense était attaché sur une chaise.


Image artistique de l'entrée dans l'atmosphère de l'Union-4.

Cependant, la chaleur qui pourrait tuer Volynov l'a sauvé de manière inattendue: les réservoirs de carburant du module d'instruments ont explosé, et en conséquence, ils se sont séparés. La capsule d'atterrissage s'est tournée dans la bonne position, l'écran thermique vers l'avant.

Pendant tout ce temps, Volynov, confiant qu'il vivait les dernières minutes, a enregistré à haute voix tout ce qu'il voit et entend.

Les problèmes ne s'arrêtent pas là. Les élingues de parachute se sont emmêlées et les moteurs d'atterrissage en douceur n'ont pas fonctionné. La capsule a touché le sol à grande vitesse, loin de la zone prévue. Le blessé Volynov a dû survivre dans le froid à -38 ° C jusqu'à ce que les sauveteurs l'atteignent.

L'astronaute a commenté haut et fort chaque bruit et vibration, espérant que l'enregistreur de vol survivrait à l'accident et que les ingénieurs seraient en mesure d'écouter les enregistrements et d'éviter de nouvelles catastrophes.

Que m'a appris cette histoire digne d'une adaptation cinématographique hollywoodienne?

Chaque fois que je rencontre un problème associé à une bibliothèque ou à un outil de développement, je me souviens de Boris Volynov. S'il a été en mesure de signaler des problèmes, même sur le point de mourir, je peux certainement prendre quelques minutes pour envoyer un rapport au développeur.

Même un simple rapport peut être une grande contribution au projet.

En raison du syndrome d'imposteur qui imprègne notre industrie, nous nous trouvons trop souvent coupables des problèmes qui se posent. Quelque chose était manquant dans la documentation, ou n'était tout simplement pas assez intelligent. Mais n'oubliez pas la leçon de la première histoire: il n'y a pas de mauvais utilisateurs, il n'y a qu'une mauvaise interface. Et il n'y a pas de mauvais développeurs, il n'y a que de mauvais outils de développement.

Si vous avez fait une erreur lors de l'utilisation du framework, vous n'êtes probablement pas le premier ni le dernier. De plus, vous avez regardé le produit dans une perspective qui manquait aux développeurs qui voient le code tous les jours. Un nouveau look facilite la détection des problèmes dans la documentation et l'expérience de développement générale.

Vous avez fait une faute de frappe, reçu un message d'erreur incompréhensible et par conséquent, vous avez passé une heure à déboguer? C'est une excellente occasion d'améliorer le message d'erreur avec le nouveau problème ou le PR. Vous cherchez trop longtemps la bibliothèque? Réfléchissez aux informations de la documentation qui pourraient vous aider.

Troisième leçon: automatisation de la confiance

Cette histoire s'est produite en 1997 avec la station spatiale Mir aujourd'hui disparue.

Il y avait une différence importante entre les programmes spatiaux soviétiques et américains. En URSS, les navires ont été créés par les mêmes personnes qui ont créé les fusées: ils ont largement utilisé l'automatisation et considéraient les pilotes comme un fardeau. Aux États-Unis, les navires (en particulier la navette spatiale) ont été créés par des personnes qui ont conçu des avions et ils ne considéraient les ordinateurs que comme des outils auxiliaires pour les pilotes.

Depuis 1967, l'URSS utilise des systèmes d'amarrage entièrement automatiques: d'abord Igloo, puis Course. Ces développements ont permis de construire la station Mir à partir de modules automatiques qui agissent comme des vaisseaux spatiaux indépendants avec leurs propres ordinateurs, systèmes d'alimentation et moteurs.


Modules de la station Mir.

Cependant, les systèmes d'amarrage soviétiques ont été fabriqués en Ukraine et après l'effondrement de l'URSS, Moscou et Kiev ne se sont pas entendus sur les prix. Roscosmos, essayant de réduire sa dépendance à l'égard de composants étrangers, a développé une alternative - TORU , qui a permis à l'opérateur de la station spatiale de contrôler à distance le navire à l'aide de deux joysticks.

TORU a été testé avec succès dans l'espace. En 1997, le navire Progress M-34 avec une cargaison pour la station a réussi à s'amarrer automatiquement au monde. Et puis, de façon inattendue, il y a eu une instruction pour le désamarrer, et au lieu de retourner sur Terre, le re-ancrer à la station manuellement afin de vérifier à nouveau le système d'amarrage.


Vasily Tsibliev contrôle le navire depuis la station Mir.

L'équipage a tenté de garder le contrôle du Progress surchargé (il transportait le prochain lot de déchets de la station, qui devait être renvoyé sur Terre), et il était difficile de détecter Mir sur la vidéo transmise par le navire. Lorsque les astronautes ont finalement vu le navire qui approchait par les fenêtres, il était trop tard pour ralentir. Le navire a endommagé le panneau solaire du module Spectrum, qui fournissait 40% de l'électricité de la station, et a fait un trou dans la coque.

Les astronautes ont entendu un sifflement et leurs oreilles ont été bloquées. La station perdait de l'air.

L'équipage a dû débrancher les câbles provenant du Spectrum, fermer le module et le laisser non scellé. Et trois ans plus tard, la station a été inondée dans l'océan.

En conséquence, le cours n'a pas été abandonné du système d'amarrage; aujourd'hui, il est fabriqué en Russie. Le cours et TORU sont utilisés sur des navires russes, TORU est un système de secours.

À ce jour, les raisons de la première et jusqu'à présent la seule collision dans l'espace ne sont pas entièrement claires . Le centre de masse du navire a été déplacé en raison d'une surcharge, les astronautes étaient fatigués et mal possédés TOPU. Le test lui-même a été organisé à la hâte: à ce moment-là, un astronaute américain était à bord du monde, et ni lui ni la NASA n'étaient au courant du test jusqu'à ce que la station soit dépressurisée.


Dommages au monde après une collision avec le Progress M-34 en 1997.

Cette histoire m'a rappelé le célèbre script d'installation de pilotes pour une carte vidéo qui a détruit les systèmes Linux . Le développeur de bibliothèque épuisé, qui a travaillé la nuit, n'a manqué qu'une seule lacune:

  # 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 

Les gens ont tort. Préférez l'automatisation. Les voitures doivent souffrir!

Je suis la règle: si vous voyez la même erreur deux fois dans votre code source, il est préférable de créer un outil automatisé qui puisse empêcher cette erreur à l'avenir.

Les linters de code source (comme ESLint pour JavaScript et Stylelint pour CSS) trouvent très bien les bogues qui peuvent vous coûter beaucoup de temps et d'argent. Vous passerez plusieurs heures à écrire votre propre plugin linter, mais à long terme, cela sera payant.

Vous voulez éviter les fautes de frappe dans la documentation? Essayez yaspeller . Vous souhaitez organiser les propriétés en CSS dans un certain ordre? Ajoutez un ordre de style à vos outils de développement.

* * *

J'espère que vous avez apprécié mes histoires spatiales. Même si elles vous semblaient farfelues, les leçons apprises restent utiles à tous les développeurs de logiciels.

L'histoire de l'exploration spatiale n'est pas seulement l'inspiration pour mes histoires lors de conférences et d'after-parties, mais sert également de source aux bonnes techniques. Quoi de mieux vous rappelle la nécessité d'envoyer un rapport sur le problème qu'un vaisseau spatial en feu?