Original: Artikel „ Was ich als Entwickler aus Unfällen im Weltraum gelernt habe “ von Andrei Sitnik aus dem Blog der bösen Marsmenschen „ Martian Chronicles “

Andrei Sitnik, Autor von PostCSS und AutoPrefixer , hat eine Auswahl von Geschichten über die Erforschung des Weltraums durch die Sowjetunion zusammengestellt. Sie werden lernen, welche Lehren Andrei aus ihnen gezogen hat, um als Entwickler und Teilnehmer an der Open-Source-Bewegung zu wachsen. Erfolgloses Andocken, dramatischer Eintritt in die Atmosphäre und ein einzigartiger Übergang entlang der Schiene zwischen Raumschiffen - was hat das alles mit moderner Webentwicklung zu tun? Lesen Sie darüber in einem Beitrag!

Die Weltraumforschung hat mich so sehr interessiert, wie ich mich erinnere. Leute, die mich persönlich kannten, hörten mehr über den Weltraum als sie wollten. Bevor ich mich den Evil Martians anschloss, verwaltete ich die russischsprachige Version von Wikipedia und eines meiner Lieblingshobbys war das Bearbeiten von weltraumbezogenen Artikeln. Ich habe mir die Starts in Baikonur und Cape Canaveral angesehen, und je mehr ich über die Weltraumerkundungsbemühungen erfuhr, desto mehr wirkte sich dieses Wissen auf mich als Entwickler aus.

Obwohl das Schreiben von Programmen nicht so schwierig ist wie das Erstellen von Raketen (größtenteils), arbeiten wir Softwareingenieure häufig in großen Teams, um komplexe Systeme zu erstellen. Und als Weltraumforscher verlieren wir manchmal den Kampf gegen die Komplexität.

„Mit einem Notfallstart können wir das System viel besser kennenlernen und verbessern als mit Dutzenden von erfolgreichen.“

- Nikolai Pilyugin, Akademiker, Designer, Spezialist auf dem Gebiet der autonomen Kontrollsysteme für Raketen- und Weltraumraketen-Komplexe.

In jedem Raumfahrtprogramm passieren Fehler, nicht alle sind tragisch. In diesem Artikel werde ich über Beispiele aus der sowjetischen und russischen Geschichte der Weltraumforschung sprechen, die außerhalb der enthusiastischen Gemeinschaft wenig bekannt sind (wir sprechen über die westliche Gemeinschaft - ungefähr übersetzt). Diese Geschichten endeten gut.

Erste Lektion: Nutzer niemals beschuldigen

* ... und nehmen Sie Änderungen an den jeweiligen Einsprüchen vor.

In den späten 1960er Jahren haben die USA und die UdSSR die Arbeiten an einer neuen Generation von Raumfahrzeugen abgeschlossen. Apollo und die Union waren nach dem experimentellen Mercury / Gemini und East / Sunrise ein großer Schritt nach vorne. Neue Schiffe sollten nicht nur in erdnahen Umlaufbahnen funktionieren, sondern auch für Flüge zum Mond und zurück.

Im Oktober 1968 erholte sich die UdSSR von der Sojus-1- Katastrophe und war bereit, einen neuen Versuch zu unternehmen: Es war erstmals geplant, zwei Schiffe manuell im Orbit anzudocken. Die automatische Sojus-2 sollte zuerst ins All gehen. Dann sollte Georgy Beregovoi in Sojus-3 in dieselbe Umlaufbahn eintreten und die Schiffe andocken.


Der Pilot von Sojus-4, Sojus-8 und Sojus-10 Vladimir Shatalov demonstriert das Andocken von zwei Schiffen.

Der Start verlief gut. Nach nur 1,5 Stunden war Sojus-3 in Andockentfernung. Das Manöver war für die "Nacht" im Schatten der Erde geplant. Alle Versuche zum manuellen Andocken blieben jedoch erfolglos.

Und erst als sich beide Schiffe auf der Tagesseite befanden, entdeckte Beregovoi einen Fehler: Sojus-2 wurde um 180 Grad entlang der Längsachse gedreht.

Da zu diesem Zeitpunkt alle Treibstoffvorräte für Andockversuche aufgebraucht waren, wurde Beregovoi befohlen, die Mission abzuschließen und vier Tage später zur Erde zurückzukehren. Zeitungen nannten den Flug erfolgreich, Beregovoy wurde der Titel Held der Sowjetunion verliehen und wurde bald befördert. Aus dieser Geschichte wurden jedoch die richtigen Lehren gezogen und neue Regeln für alle nachfolgenden Verknüpfungen eingeführt:

• Dock nur auf der Sonnenseite.
  
• Planen Sie nicht, an einem Tag mit dem Start zu docken, damit die Piloten Zeit haben, sich im Orbit zu akklimatisieren.
  

Dock Sojus-4 in dem Film "Four in Space".

Erinnern Sie sich an diese Geschichte, wenn Sie den USB-Stecker Typ A erneut auf der falschen Seite einstecken.

Es gibt keine schlechten Benutzer - es gibt eine schlechte Benutzeroberfläche.

Es ist einfach, den Benutzern die Schuld zu geben. Die Leute werden sich jedoch immer irren. Entwickler sind keine Ausnahme. Als Teilnehmer an der Open Source-Bewegung habe ich festgestellt, dass Fehler auch in Zukunft nicht verhindert werden können, wenn Sie die Entwickler für Fehler verantwortlich machen.

Das Schließen eines Problems in Ihrem OpenSource-Repository mit einer unhöflichen Antwort im RTFM-Stil (oder, schlimmer noch, gar keiner Antwort!) Schützt Sie nicht vor demselben Problem. Sie erhalten immer wieder die gleichen Nachrichten.

Als Schöpfer von PostCSS und Auto Prefixer erhalte ich viele Fehlermeldungen. Um auf lange Sicht keine Zeit zu verschwenden, befolge ich die Regel: Jedes Problem sollte zu einer Änderung des Codes oder der Dokumentation führen .

Es ist am besten, die Benutzerfreundlichkeit von UX zu verbessern (aus Sicht der Open-Source-Bibliothek handelt es sich um eine API), sodass es in Zukunft unmöglich ist, denselben Fehler zu machen. Im schlimmsten Fall können Sie eine Warnung hinzufügen.

Beispielsweise vergessen viele PostCSS-Benutzer die Parser-Option und versuchen, .less- und .scss-Dateien ohne die entsprechenden Parser zu verarbeiten. Anstatt die Benutzer zu beschuldigen, haben wir eine kleine Warnung hinzugefügt:

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

Zweite Lektion: Informieren Sie auf jeden Fall den Entwickler über die Probleme

Drei Monate nach dem Flug von Sojus-2 und Sojus-3 war die UdSSR bereit für einen neuen, noch ehrgeizigeren Versuch des manuellen Andockens.

Es war geplant, zwei bemannte Raumschiffe mit einem Unterschied von einem Tag zu starten: Sojus-4 mit einem Astronauten und Sojus-5 mit drei. Nach dem Andocken sollten der Pilotingenieur und der Forschungsingenieur von Sojus-5 durch den freien Raum nach Sojus-4 gehen und zur Erde zurückkehren. Das heißt, sie starteten in einem Schiff, schlenderten durch das Weltall und landeten auf einem anderen Schiff.


Übergang durch den Weltraum von Sojus-5 nach Sojus-4.

Boris Volynov , ein Sojus-5-Pilot, sollte einen Tag später alleine auf die Erde zurückkehren.

Diesmal war das Andocken erfolgreich, Sojus-4 beendete seine Mission ohne Probleme. Und am 18. Januar 1969 war es Zeit, nach Hause und nach Wolynow zurückzukehren. Die Vereinigung besteht aus drei abnehmbaren Modulen, und nur eines, das zentrale, sollte in die Atmosphäre gelangen.


Unionsschema. Quelle: NASA

Während der Rückkehr von Volynov trennte sich das Instrument-Aggregat-Modul nicht normal. Es war zu spät, um die Landung zu unterbrechen. Das Raumschiff trat mit einer falschen Orientierung in die Atmosphäre ein: die vordere Nase. Dem einströmenden Strom stand nur eine dünne Einstiegsluke gegenüber, der Hitzeschild befand sich hinten zwischen den Modulen, die nicht geteilt waren.

Das Siegel um die Luke begann zu brennen, die Landekapsel begann sich mit giftigem Rauch zu füllen. Schwerkraft und Atmosphäre machten ihren Job, der wehrlose Volynov war in einem Stuhl gefesselt.


Künstlerisches Bild des Eingangs zur Atmosphäre der Union-4.

Die Hitze, die Volynov töten konnte, rettete ihn jedoch unerwartet: Die Kraftstofftanks des Instrumentenmoduls explodierten und trennten sich infolgedessen. Die Landekapsel drehte sich in die richtige Position, Hitzeschild nach vorne.

Volynov war zuversichtlich, dass er die letzten Minuten überlebt hatte, und nahm laut alles auf, was er sah und hörte.

Die Probleme endeten nicht dort. Die Fallschirmschlingen verhedderten sich und die weichen Landemotoren funktionierten nicht. Die Kapsel landete mit hoher Geschwindigkeit weit außerhalb des geplanten Bereichs. Der verwundete Volynov musste in der Kälte bei -38 ° C überleben, bis die Retter ihn erreichten.

Der Astronaut äußerte sich lautstark zu allen Geräuschen und Vibrationen und hoffte, dass der Flugschreiber den Absturz überleben und die Ingenieure die Aufzeichnungen anhören und neue Katastrophen verhindern könnten.

Was hat mir diese Geschichte, die einer Verfilmung in Hollywood würdig ist, beigebracht?

Jedes Mal, wenn ich auf ein Problem mit einer Bibliothek oder einem Entwicklungswerkzeug stoße, erinnere ich mich an Boris Volynov. Wenn er Probleme sogar kurz vor dem Tod melden konnte, kann ich mir definitiv ein paar Minuten Zeit nehmen, um dem Entwickler einen Bericht zu schicken.

Selbst ein einfacher Bericht kann einen großen Beitrag zum Projekt leisten.

Aufgrund des in unserer Branche vorherrschenden Betrugssyndroms machen wir uns allzu oft der auftretenden Probleme schuldig. In der Dokumentation wurde etwas übersehen oder es war einfach nicht schlau genug. Aber vergessen Sie nicht die Lektion aus der ersten Geschichte: Es gibt keine schlechten Benutzer, es gibt nur eine schlechte Benutzeroberfläche. Und es gibt keine schlechten Entwickler, es gibt nur schlechte Entwicklungswerkzeuge.

Wenn Sie bei der Verwendung des Frameworks einen Fehler gemacht haben, sind Sie wahrscheinlich nicht der Erste und nicht der Letzte. Darüber hinaus haben Sie das Produkt aus einer Perspektive betrachtet, die von Entwicklern, die den Code jeden Tag sehen, übersehen wurde. Ein frisches Aussehen erleichtert das Erkennen von Problemen in der Dokumentation und der allgemeinen Entwicklungserfahrung.

Sie haben einen Tippfehler gemacht, eine unverständliche Fehlermeldung erhalten und infolgedessen eine Stunde mit dem Debuggen verbracht? Dies ist eine großartige Gelegenheit, um die Fehlermeldung mit der neuen Ausgabe oder PR zu verbessern. Suchen Sie zu lange nach einem Weg in der Bibliothek? Überlegen Sie, welche Informationen in der Dokumentation Ihnen helfen würden.

Dritte Lektion: Vertrauensautomatisierung

Diese Geschichte geschah 1997 mit der inzwischen aufgelösten Raumstation Mir .

Es gab einen wichtigen Unterschied zwischen dem sowjetischen und dem amerikanischen Raumfahrtprogramm. In der UdSSR wurden Schiffe von denselben Leuten hergestellt, die die Raketen hergestellt haben: Sie nutzten die Automatisierung ausgiebig und betrachteten die Piloten praktisch als Belastung. Und in den USA wurden Schiffe (insbesondere Space Shuttle) von Menschen hergestellt, die Flugzeuge entwarfen, und sie betrachteten Computer nur als Hilfsmittel für Piloten.

Seit 1967 setzt die UdSSR vollautomatische Andocksysteme ein: zuerst Iglu, dann Kurs. Diese Entwicklungen ermöglichten den Bau der Mir-Station aus automatischen Modulen, die als eigenständige Raumfahrzeuge mit eigenen Computern, Energiesystemen und Motoren fungieren.


Module der Mir-Station.

Die sowjetischen Dockingsysteme wurden jedoch in der Ukraine hergestellt, und nach dem Zusammenbruch der UdSSR einigten sich Moskau und Kiew nicht auf Preise. Um die Abhängigkeit von Fremdkomponenten zu verringern, entwickelte Roscosmos eine Alternative - TORU , mit der der Bediener der Raumstation das Schiff mit zwei Joysticks fernsteuern konnte.

TORU erfolgreich im All getestet. 1997 koppelte das Schiff Progress M-34 mit Fracht für die Station erfolgreich automatisch an die Welt an. Und dann gab es unerwartet eine Anweisung, es abzudocken und statt zur Erde zurückzukehren, es manuell an die Station anzudocken, um das Andocksystem erneut zu überprüfen.


Vasily Tsibliev steuert das Schiff von der Mir-Station aus.

Die Besatzung versuchte, die Kontrolle über den überlasteten Fortschritt zu behalten (sie transportierte die nächste Menge Abfall von der Station, die zur Erde zurückgebracht werden musste), und es war schwierig, Mir auf dem vom Schiff übertragenen Video zu erkennen. Als die Astronauten das herannahende Schiff endlich durch die Fenster sahen, war es zu spät, um langsamer zu werden. Das Schiff beschädigte das Solarpanel des Spectrum-Moduls, das 40% des Stroms der Station lieferte, und bohrte ein Loch in den Rumpf.

Die Astronauten hörten ein Pfeifen und ihre Ohren waren verstopft. Die Station verlor Luft.

Die Besatzung musste die vom Spectrum kommenden Kabel trennen, das Modul schließen und unversiegelt lassen. Und drei Jahre später wurde die Station im Ozean überflutet.

Aus diesem Grund wurde der Platz nicht aus dem Docking-System genommen, sondern wird heute in Russland hergestellt. Der Kurs und TORU werden auf russischen Schiffen eingesetzt, TORU ist ein Backup-System.

Bis heute sind die Gründe für die erste und bisher einzige Kollision im Weltraum nicht ganz klar . Der Schwerpunkt des Schiffes wurde aufgrund von Überladung verschoben, die Astronauten waren müde und schlecht besessenes TOPU. Der Test selbst wurde in Eile organisiert: In diesem Moment befand sich ein amerikanischer Astronaut an Bord der Welt, und weder er noch die NASA wussten von dem Test, bis die Station drucklos war.


Weltschaden nach einer Kollision mit dem Progress M-34 im Jahr 1997.

Diese Geschichte erinnerte mich an das berühmte Skript zur Installation von Treibern für eine Grafikkarte, die Linux-Systeme zerstörte . Der erschöpfte Bibliotheksentwickler, der nachts arbeitete, verpasste nur eine Lücke:

  # 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 

Die Leute liegen falsch. Bevorzugen Sie Automatisierung. Autos müssen leiden!

Ich befolge die Regel: Wenn Sie denselben Fehler zweimal in Ihrem Quellcode sehen, ist es besser, ein automatisiertes Tool zu erstellen, das diesen Fehler in Zukunft verhindern kann.

Quellcode-Linters (wie ESLint für JavaScript und Stylelint für CSS) finden sehr gut Fehler, die Sie viel Zeit und Geld kosten können. Sie werden mehrere Stunden damit verbringen, Ihr eigenes Linter-Plugin zu schreiben, aber auf lange Sicht wird es sich auszahlen.

Möchten Sie Tippfehler in der Dokumentation vermeiden? Versuchen Sie es mit yaspeller . Möchten Sie Eigenschaften in CSS in einer bestimmten Reihenfolge organisieren? Ergänzen Sie Ihre Entwicklungstools mit Stylelint-Order .

* * *

Ich hoffe, Ihnen haben meine Weltraumgeschichten gefallen. Auch wenn sie Ihnen weit hergeholt vorkamen, bleiben die gewonnenen Erkenntnisse für alle Softwareentwickler nützlich.

Die Geschichte der Weltraumforschung ist nicht nur die Inspiration für meine Geschichten auf Konferenzen und After-Partys, sondern dient auch als Quelle für die richtigen Techniken. Was erinnert Sie besser an die Notwendigkeit, einen Bericht über das Problem zu senden, als ein brennendes Raumschiff?