Asli: artikel “ Apa yang saya pelajari sebagai pengembang dari kecelakaan di luar angkasa ”, oleh Andrei Sitnik, dari blog Evil Martians “ Martian Chronicles ”

Andrei Sitnik, penulis PostCSS dan AutoPrefixer , membuat pilihan cerita yang berkaitan dengan eksplorasi ruang angkasa oleh Uni Soviet. Anda akan belajar pelajaran apa yang dipelajari Andrei dari mereka agar tumbuh sebagai pengembang dan peserta dalam gerakan open-source. Docking yang tidak berhasil, entri dramatis ke atmosfer dan transisi unik di sepanjang rel antara pesawat ruang angkasa - apa hubungannya semua ini dengan pengembangan web modern? Baca semua ini di pos!

Eksplorasi ruang angkasa menarik saya sebanyak yang saya ingat. Orang-orang yang mengenal saya secara pribadi mendengar lebih banyak tentang ruang daripada yang mereka inginkan. Sebelum bergabung dengan Evil Martians, saya mengelola Wikipedia versi bahasa Rusia, dan salah satu hobi favorit saya adalah mengedit artikel yang berhubungan dengan ruang. Saya pergi untuk menonton peluncuran di Baikonur dan Cape Canaveral, dan semakin saya belajar tentang upaya eksplorasi ruang angkasa, semakin banyak pengetahuan ini memengaruhi saya sebagai pengembang.

Meskipun program menulis tidak sesulit membangun roket (sebagian besar), namun kami, insinyur perangkat lunak, sering bekerja dalam tim besar menciptakan sistem yang kompleks. Dan sebagai penjelajah luar angkasa, kadang-kadang kita kalah melawan kompleksitas.

“Satu permulaan darurat memberi kita lebih banyak untuk mengetahui dan meningkatkan sistem daripada lusinan yang berhasil”

- Nikolai Pilyugin, akademisi, perancang, spesialis di bidang sistem kontrol otonom untuk kompleks roket dan roket ruang angkasa.

Di setiap program luar angkasa, kesalahan terjadi, tidak semuanya tragis. Dalam artikel ini saya akan berbicara tentang contoh-contoh dari sejarah eksplorasi ruang angkasa Soviet dan Rusia, yang sedikit diketahui di luar komunitas penggila (kita berbicara tentang komunitas Barat - kira-kira. Terjemahan.). Kisah-kisah ini berakhir dengan baik.

Pelajaran pertama: jangan pernah menyalahkan pengguna *

* ... dan buat perubahan pada masing-masing banding mereka.

Pada akhir 1960-an, Amerika Serikat dan Uni Soviet menyelesaikan pekerjaan pada pesawat ruang angkasa generasi baru. Apollo dan Uni adalah langkah besar ke depan setelah Merkurius eksperimental / Gemini dan Timur / Matahari Terbit. Kapal baru dirancang untuk bekerja tidak hanya di orbit dekat Bumi, tetapi juga untuk penerbangan ke bulan dan kembali.

Pada bulan Oktober 1968, Uni Soviet pulih dari bencana Soyuz-1 dan siap untuk melakukan upaya baru: direncanakan untuk pertama kalinya melakukan docking manual dua kapal di orbit. Soyuz-2 otomatis seharusnya pergi ke luar angkasa terlebih dahulu. Kemudian Georgy Beregovoi di Soyuz-3 memasuki orbit yang sama dan berlabuh di kapal.


Pilot Soyuz-4, Soyuz-8 dan Soyuz-10 Vladimir Shatalov menunjukkan docking dua kapal.

Peluncuran berjalan dengan baik. Setelah hanya 1,5 jam, Soyuz-3 berada pada jarak docking. Manuver itu direncanakan untuk waktu "malam", di bayang-bayang Bumi. Namun, semua upaya penghubungan manual berakhir tidak berhasil.

Dan hanya ketika kedua kapal berada di sisi hari, Beregovoi menemukan kesalahan: Soyuz-2 diputar 180 derajat di sepanjang sumbu longitudinal.

Karena pada saat itu semua pasokan bahan bakar telah digunakan untuk upaya docking, Beregovoi diperintahkan untuk menyelesaikan misi dan kembali ke Bumi empat hari kemudian. Surat kabar menyebut penerbangan itu berhasil, Beregovoy dianugerahi gelar Pahlawan Uni Soviet dan segera dipromosikan. Namun, pelajaran yang tepat dipelajari dari cerita ini, dan aturan baru diperkenalkan untuk semua bergabung berikut:

• Dok hanya di sisi yang cerah.
  
• Jangan berencana untuk berlabuh dalam satu hari dengan peluncuran, sehingga pilot punya waktu untuk menyesuaikan diri di orbit.
  

Dock Soyuz-4 dalam film "Four in Space . "

Ingat cerita ini ketika Anda memasukkan kembali steker USB Tipe-A di sisi yang salah.

Tidak ada pengguna yang buruk - ada antarmuka yang buruk.

Sangat mudah untuk menyalahkan pengguna. Namun, orang akan selalu salah. Pengembang tidak terkecuali. Sebagai peserta dalam gerakan open source, saya menyadari bahwa jika menyalahkan pengembang untuk kesalahan, itu masih tidak akan membantu mencegah kesalahan di masa depan.

Menutup masalah tentang masalah di repositori opensource Anda dengan jawaban gaya RTFM yang kasar (atau, lebih buruk, tidak ada jawaban sama sekali!), Anda tidak akan melindungi diri dari penampilan masalah yang sama. Anda akan menerima pesan yang sama berulang kali.

Sebagai pencipta PostCSS dan Auto Prefixer, saya mendapatkan banyak laporan masalah . Agar tidak membuang waktu dalam jangka panjang, saya mengikuti aturan: setiap masalah harus mengarah pada perubahan kode atau dokumentasi .

Cara terbaik untuk meningkatkan pengalaman pengguna, UX (dari sudut pandang perpustakaan open source itu akan menjadi API), sehingga di masa depan tidak mungkin untuk membuat kesalahan yang sama. Paling buruk, Anda bisa menambahkan peringatan.

Sebagai contoh, banyak pengguna PostCSS melupakan opsi parser dan mencoba memproses file .less dan .scss tanpa parser yang sesuai. Alih-alih menyalahkan pengguna, kami menambahkan peringatan kecil:

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

Pelajaran kedua: tentu saja, beri tahu pengembang tentang masalahnya

Tiga bulan setelah penerbangan Soyuz-2 dan Soyuz-3, Uni Soviet siap untuk upaya baru pada docking manual, bahkan lebih ambisius.

Direncanakan untuk meluncurkan dua pesawat ruang angkasa berawak dengan perbedaan satu hari: Soyuz-4 dengan satu astronot dan Soyuz-5 dengan tiga. Setelah docking, pilot engineer dan engineer riset dari Soyuz-5 seharusnya melewati ruang terbuka ke Soyuz-4 dan kembali ke Bumi. Artinya, mereka berangkat dengan satu kapal, berjalan di luar angkasa, mendarat di kapal lain.


Transisi melalui ruang luar Soyuz-5 ke Soyuz-4.

Boris Volynov , seorang pilot Soyuz-5, akan tetap sendirian dan kembali ke Bumi sehari kemudian.

Kali ini docking berhasil, Soyuz-4 menyelesaikan misinya tanpa masalah. Dan pada 18 Januari 1969, sudah waktunya untuk pulang dan ke Volynov. Serikat pekerja terdiri dari tiga modul yang dapat dilepas, dan hanya satu, modul pusat, yang dirancang untuk memasuki atmosfer.


Skema serikat pekerja. Sumber: NASA

Selama kembalinya Volynov, modul instrumen-agregat tidak terpisah secara normal. Sudah terlambat untuk menghentikan pendaratan. Wahana antariksa memasuki atmosfer dengan orientasi ruang yang salah: hidung ke depan. Aliran masuk ditentang hanya oleh pintu masuk tipis, perisai panas ada di belakang, antara modul yang tidak dibagi.

Segel di sekitar lubang palka mulai terbakar, kapsul pendaratan mulai terisi dengan asap beracun. Gravitasi dan atmosfer melakukan pekerjaan mereka, Volynov yang tak berdaya diikat di kursi.


Gambar artistik dari pintu masuk ke suasana Union-4.

Namun, panas yang bisa membunuh Volynov secara tak terduga menyelamatkannya: tangki bahan bakar modul instrumen meledak, dan sebagai hasilnya, terpisah. Kapsul pendaratan beralih ke posisi yang benar, perisai panas ke depan.

Selama ini Volynov, yakin bahwa ia hidup di menit-menit terakhir, merekam dengan keras segala sesuatu yang ia lihat dan dengar.

Masalahnya tidak berakhir di sana. Sling parasut menjadi terjerat, dan mesin pendaratan lunak tidak berfungsi. Kapsul itu menyentuh tanah dengan kecepatan tinggi jauh dari area yang direncanakan. Volynov yang terluka harus bertahan hidup dalam cuaca dingin pada −38 ° C sampai penyelamat mencapai dia.

Astronot dengan keras mengomentari setiap suara dan getaran, berharap bahwa perekam penerbangan akan selamat dari kecelakaan dan para insinyur akan dapat mendengarkan rekaman dan mencegah bencana baru.

Apa yang diajarkan cerita ini yang layak untuk adaptasi film Hollywood?

Setiap kali saya menemukan masalah yang terkait dengan perpustakaan atau alat pengembangan, saya ingat Boris Volynov. Jika dia dapat melaporkan masalah bahkan di ambang kematian, maka saya pasti dapat mengambil beberapa menit untuk mengirim laporan kepada pengembang.

Bahkan laporan sederhana dapat menjadi kontribusi besar bagi proyek.

Karena sindrom penipu merasuki industri kita, kita terlalu sering menemukan diri kita bersalah atas masalah yang muncul. Ada yang terlewat dalam dokumentasi, atau memang tidak cukup pintar. Tapi jangan lupa tentang pelajaran dari cerita pertama: tidak ada pengguna yang buruk, hanya ada antarmuka yang buruk. Dan tidak ada pengembang yang buruk, hanya ada alat pengembangan yang buruk.

Jika Anda membuat kesalahan saat menggunakan kerangka kerja, maka Anda mungkin bukan yang pertama dan bukan yang terakhir. Selain itu, Anda melihat produk dari perspektif yang terlewatkan oleh pengembang yang melihat kode setiap hari. Tampilan baru membuatnya lebih mudah untuk melihat masalah dalam dokumentasi dan pengalaman pengembangan umum.

Anda membuat kesalahan ketik, mendapat pesan kesalahan yang tidak bisa dipahami, dan akibatnya, Anda menghabiskan waktu satu jam untuk debugging? Ini adalah peluang bagus untuk meningkatkan pesan kesalahan dengan masalah baru atau PR. Mencari jalan di perpustakaan terlalu lama? Pikirkan informasi apa dalam dokumentasi yang akan membantu Anda.

Pelajaran ketiga: otomatisasi kepercayaan

Kisah ini terjadi pada tahun 1997 dengan Stasiun Luar Angkasa Mir yang sekarang sudah tidak ada.

Ada satu perbedaan penting antara program luar angkasa Soviet dan Amerika. Di Uni Soviet, kapal diciptakan oleh orang yang sama yang menciptakan roket: mereka menggunakan otomatisasi yang luas dan menganggap pilot secara praktis merupakan beban. Dan di AS, kapal (khususnya, Space Shuttle) diciptakan oleh orang-orang yang merancang pesawat, dan mereka menganggap komputer hanya sebagai alat bantu untuk pilot.

Sejak 1967, USSR telah menggunakan sistem docking otomatis sepenuhnya: pertama, Igloo, lalu Kursus. Perkembangan ini memungkinkan untuk membangun stasiun Mir dari modul otomatis yang bertindak sebagai pesawat ruang angkasa independen dengan komputer, sistem daya, dan mesin mereka sendiri.


Modul stasiun Mir.

Namun, sistem docking Soviet dibuat di Ukraina, dan setelah runtuhnya Uni Soviet, Moskow dan Kiev tidak menyetujui harga. Roscosmos, mencoba mengurangi ketergantungannya pada komponen asing, mengembangkan alternatif - TORU , yang memungkinkan operator di stasiun ruang angkasa untuk mengontrol kapal dari jarak jauh menggunakan dua joystick.

TORU berhasil diuji di ruang angkasa. Pada tahun 1997, kapal Progress M-34 dengan muatan untuk stasiun berhasil secara otomatis merapat ke Dunia. Dan kemudian, secara tak terduga, ada instruksi untuk melepaskannya, dan alih-alih kembali ke Bumi, dok kembali ke stasiun secara manual untuk memeriksa kembali sistem dok.


Tsibliev dengan mudah mengendalikan kapal dari stasiun Mir.

Para kru mencoba untuk mempertahankan kendali atas Kemajuan yang kelebihan beban (itu membawa tumpukan limbah berikutnya dari stasiun, yang harus dikembalikan ke Bumi), dan sulit untuk mendeteksi Mir pada video yang dikirim dari kapal. Ketika para astronot akhirnya melihat kapal yang mendekat melalui jendela, sudah terlambat untuk memperlambat. Kapal merusak panel surya dari modul Spectrum, yang menyediakan 40% dari listrik stasiun, dan membuat lubang di lambung.

Para astronot mendengar peluit dan telinga mereka terhalang. Stasiun kehilangan udara.

Para kru harus mencabut kabel yang datang dari Spectrum, menutup modul dan membiarkannya tidak tertutup. Dan tiga tahun kemudian, stasiun itu banjir di lautan.

Akibatnya, Kursus tidak ditinggalkan dari sistem docking, hari ini sedang diproduksi di Rusia. Kursus dan TORU digunakan pada kapal Rusia, TORU adalah sistem cadangan.

Hingga hari ini, alasan untuk tabrakan pertama dan sejauh ini di ruang angkasa tidak sepenuhnya jelas . Pusat massa kapal digeser karena kelebihan muatan, para astronot lelah dan TOPU kurang dimiliki. Tes itu sendiri diselenggarakan dengan tergesa-gesa: pada saat itu, seorang astronot Amerika berada di Dunia, dan baik dia maupun NASA tidak tahu tentang tes sampai stasiun itu tertekan.


Kerusakan Dunia setelah tabrakan dengan Kemajuan M-34 pada tahun 1997.

Kisah ini mengingatkan saya pada skrip terkenal untuk menginstal driver untuk kartu video yang merusak sistem Linux . Pengembang perpustakaan yang kelelahan, yang bekerja pada malam hari, hanya melewatkan satu celah:

  # 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 

Orang salah. Memilih otomatisasi. Mobil harus menderita!

Saya mengikuti aturan: jika Anda melihat kesalahan yang sama dua kali dalam kode sumber Anda, lebih baik membuat alat otomatis yang dapat mencegah kesalahan ini di masa depan.

Kode sumber linter (seperti ESLint untuk JavaScript dan Stylelint untuk CSS) sangat baik menemukan bug yang dapat menghabiskan banyak waktu dan uang. Anda akan menghabiskan beberapa jam menulis plugin linter Anda sendiri, tetapi dalam jangka panjang akan terbayar.

Ingin menghindari kesalahan ketik dalam dokumentasi? Coba yaspeller . Ingin mengatur properti dalam CSS dalam urutan tertentu? Tambahkan stylelint-order ke alat pengembangan Anda .

* * *

Saya harap Anda menikmati cerita luar angkasa saya. Sekalipun hal itu tampaknya tidak masuk akal bagi Anda, pelajaran yang dipetik tetap bermanfaat bagi semua pengembang perangkat lunak.

Sejarah eksplorasi ruang angkasa tidak hanya menjadi inspirasi bagi cerita saya di konferensi dan setelah pesta, tetapi juga berfungsi sebagai sumber teknik yang tepat. Apa yang lebih baik mengingatkan Anda tentang perlunya mengirim laporan tentang masalah daripada pesawat ruang angkasa yang terbakar?