الأصل: مقال " ما تعلمته كمطور من الحوادث التي وقعت في الفضاء " ، بقلم أندريه سيتنيك ، من مدونة Evil Martians " Martian Chronicles "

قام Andrei Sitnik ، مؤلف PostCSS و AutoPrefixer ، باختيار مجموعة من القصص المتعلقة باستكشاف الفضاء من قبل الاتحاد السوفيتي. سوف تتعلم الدروس التي تعلمها Andrei من أجل النمو كمطور ومشارك في حركة المصادر المفتوحة. الالتحام غير الناجح ، والدخول الدراماتيكي في الغلاف الجوي والانتقال الفريد على طول السكك الحديدية بين سفن الفضاء - ما علاقة كل هذا بتطوير الويب الحديث؟ قرأت عن كل هذا في وظيفة!

استكشاف الفضاء يهمني بقدر ما أتذكر. الناس الذين عرفوني شخصيا سمعوا عن الفضاء أكثر مما يريدون. قبل الانضمام إلى Evil Martians ، قمت بإدارة النسخة الروسية من ويكيبيديا ، وكانت إحدى هواياتي المفضلة هي تحرير مقالات متعلقة بالفضاء. ذهبت لمشاهدة عمليات الإطلاق في بايكونور وكيب كانافيرال ، وكلما علمت بجهود استكشاف الفضاء ، كلما أثرت هذه المعرفة لي كمطور.

على الرغم من أن برامج الكتابة ليست صعبة مثل بناء الصواريخ (بالنسبة للجزء الأكبر) ، إلا أننا ، نحن مهندسو البرمجيات ، نعمل غالبًا في فرق كبيرة لإنشاء أنظمة معقدة. وكمستكشفين للفضاء ، في بعض الأحيان نفقد المعركة ضد التعقيد.

"بداية واحدة للطوارئ تعطينا الكثير لمعرفة ومعرفة النظام أكثر من العشرات من الناجحين"

- نيكولاي بيليجين ، أكاديمي ، مصمم ، متخصص في مجال أنظمة التحكم المستقلة لمجمعات الصواريخ والصواريخ الفضائية.

في كل برنامج فضاء ، تحدث أخطاء ، وليس كلها مأساوية. سوف أتحدث في هذا المقال عن أمثلة من التاريخ السوفيتي والروسي لاستكشاف الفضاء ، والتي لا تُعرف إلا خارج مجتمع المتحمسين (نحن نتحدث عن المجتمع الغربي - ترجمة تقريبية). انتهت هذه القصص بشكل جيد.

الدرس الأول: لا تلوم المستخدمين مطلقًا *

* ... وإجراء تغييرات على كل من طلباتهم.

في أواخر الستينيات ، أكملت الولايات المتحدة والاتحاد السوفيتي العمل على جيل جديد من المركبات الفضائية. كان أبولو والاتحاد خطوة كبيرة إلى الأمام بعد التجريبية ميركوري / الجوزاء وشرق / شروق الشمس. تم تصميم سفن جديدة للعمل ليس فقط في مدارات قريبة من الأرض ، ولكن أيضًا للرحلات الجوية إلى القمر والعودة.

في أكتوبر 1968 ، تعافى الاتحاد السوفيتي من كارثة Soyuz-1 وكان مستعدًا للقيام بمحاولة جديدة: تم التخطيط لأول مرة لأداء رسو يدوي لسفينتين في المدار. كان من المفترض أن يدخل نظام Soyuz-2 التلقائي حيز الفضاء أولاً. ثم كان على جورجي بيرجوفوي في سويوز 3 الدخول في المدار نفسه ورصيف السفن.


يوضح طيار سويوز -4 ، سويوز -8 و سويوز -10 فلاديمير شاتالوف ، إرساء سفينتين.

سار إطلاق جيدا. بعد 1.5 ساعة فقط ، كان Soyuz-3 على مسافة الإرساء. تم التخطيط للمناورة في "الليل" ، في ظل الأرض. ومع ذلك ، انتهت جميع محاولات الإرساء اليدوي دون جدوى.

وفقط عندما كانت كلتا السفينتين على جانب النهار ، اكتشف بيرجوفوي خطأ: تم تدوير سويوز -2 180 درجة على طول المحور الطولي.

منذ ذلك الوقت كانت جميع إمدادات الوقود قد استُخدمت في محاولات الالتحام ، أمر بيريجوف بإكمال المهمة والعودة إلى الأرض بعد أربعة أيام. دعا صحف رحلة ناجحة ، Beregovoy حصل على لقب بطل الاتحاد السوفياتي وتمت ترقيته قريبا. ومع ذلك ، تم تعلم الدروس الصحيحة من هذه القصة ، وتم تقديم قواعد جديدة لجميع الصلات التالية:

• قفص الاتهام فقط على الجانب المشمس.
  
• لا تخطط للالتحام في يوم واحد مع الإطلاق ، بحيث يكون للطيارين الوقت للتأقلم في المدار.
  

قفص الاتهام سويوز 4 في فيلم "أربعة في الفضاء" .

تذكر هذه القصة عند إدخال قابس USB Type-A مرة أخرى على الجانب الخطأ.

لا يوجد مستخدمون سيئون - هناك واجهة سيئة.

من السهل إلقاء اللوم على المستخدمين. ومع ذلك ، سيكون الناس دائما على خطأ. المطورين ليست استثناء. كمشارك في حركة المصادر المفتوحة ، أدركت أنه إذا ألقت باللوم على المطورين عن الأخطاء ، فإنها لن تساعد في منع الأخطاء في المستقبل.

إغلاق مشكلة حول مشكلة في مستودع المصادر المفتوحة الخاص بك مع إجابة وقحة نمط RTFM (أو ما هو أسوأ ، لا إجابة على الإطلاق!) ، فلن تحمي نفسك من ظهور نفس المشكلة. سوف تتلقى نفس الرسائل مرارا وتكرارا.

بصفتي منشئي PostCSS و Auto Prefixer ، أحصل على الكثير من تقارير المشكلات . لكي لا أضيع الوقت على المدى الطويل ، أتبع القاعدة: كل مشكلة يجب أن تؤدي إلى تغيير في الكود أو الوثائق .

من الأفضل تحسين تجربة المستخدم ، UX (من وجهة نظر المكتبة مفتوحة المصدر ستكون واجهة برمجة تطبيقات) ، بحيث في المستقبل سيكون من المستحيل ارتكاب نفس الخطأ. في أسوأ الأحوال ، يمكنك إضافة تحذير.

على سبيل المثال ، ينسى العديد من مستخدمي PostCSS خيار المحلل اللغوي ويحاولون معالجة ملفات .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' } 

الدرس الثاني: أعلم المطور بكل المشكلات

بعد ثلاثة أشهر من رحلة Soyuz-2 و Soyuz-3 ، كان اتحاد الجمهوريات الاشتراكية السوفياتية مستعدًا لمحاولة جديدة لرسو السفن يدويًا ، وأكثر طموحًا.

تم التخطيط لإطلاق مركبتين فضائيتين مأهولتين بفارق يوم واحد: Soyuz-4 مع رائد فضاء واحد و Soyuz-5 مع ثلاثة. بعد الإرساء ، كان من المفترض أن يذهب المهندس الرائد ومهندس الأبحاث من Soyuz-5 عبر الفضاء المفتوح إلى Soyuz-4 ويعودان إلى الأرض. وهذا هو ، أقلعت في سفينة واحدة ، في نزهة في الفضاء ، وهبطت على متن سفينة أخرى.


الانتقال عبر الفضاء الخارجي للاتحاد - 5 إلى الاتحاد - 4.

بوريس فولينوف ، طيار من طراز Soyuz-5 ، كان عليه أن يظل وحيدا ويعود إلى الأرض بعد يوم.

هذه المرة كان الالتحام ناجحًا ، أكمل Soyuz-4 مهمته دون أي مشاكل. وفي 18 يناير 1969 ، حان الوقت للعودة إلى المنزل وإلى فولينوف. يتكون الاتحاد من ثلاث وحدات قابلة للفصل ، وقد تم تصميم وحدة واحدة فقط ، وهي الوحدة المركزية ، لدخول الغلاف الجوي.


مخطط الاتحاد. المصدر: ناسا

أثناء عودة فولينوف ، لم تفصل الوحدة النمطية للأدوات بشكل طبيعي. بعد فوات الأوان لمقاطعة الهبوط. دخلت المركبة الفضائية الغلاف الجوي مع اتجاه غير صحيح في الفضاء: الأنف إلى الأمام. لم يعارض التدفق الوارد سوى فتحة مدخل رفيعة ، وكان درع الحرارة في الخلف ، بين الوحدات التي لم يتم تقسيمها.

بدأ الختم حول الفتحة في الاحتراق ، وبدأت كبسولة الهبوط ممتلئة بالدخان السام. قام الجاذبية والغلاف الجوي بعملهما ؛ تم تثبيت فولينوف الأعزل على كرسي.


الصورة الفنية لمدخل الغلاف الجوي للاتحاد 4.

ومع ذلك ، فإن الحرارة التي يمكن أن تقتل فولينوف أنقذته بشكل غير متوقع: انفجرت خزانات الوقود في وحدة الأدوات ، ونتيجة لذلك انفصلت. تحولت كبسولة الهبوط إلى الموضع الصحيح ، درع الحرارة إلى الأمام.

طوال هذا الوقت ، سجل فولينوف ، واثقًا من أنه كان يعيش في الدقائق الأخيرة ، كل ما يراه ويسمعه بصوت عالٍ.

المشاكل لم تنته عند هذا الحد. أصبحت حبال المظلة متشابكة ، ولم تنجح محركات الهبوط اللينة. اصطدمت الكبسولة بالأرض بسرعة عالية بعيدة عن المنطقة المخطط لها. كان على الجريح فولينوف البقاء على قيد الحياة في البرد عند درجة حرارة 38 درجة مئوية حتى وصل إليه رجال الإنقاذ.

علق رائد الفضاء بصوت عالٍ على كل صوت واهتزاز ، معربًا عن أمله في أن ينجو مسجل الرحلة من الحادث وأن يتمكن المهندسون من الاستماع إلى التسجيلات ومنع وقوع كوارث جديدة.

ماذا علمتني هذه القصة التي تستحق التعديل السينمائي في هوليود؟

في كل مرة أواجه فيها مشكلة مرتبطة بمكتبة أو أداة تطوير ، أتذكر بوريس فولينوف. إذا كان قادرًا على الإبلاغ عن المشكلات حتى على وشك الموت ، فيمكنني بالتأكيد قضاء بضع دقائق لإرسال تقرير إلى المطور.

حتى التقرير البسيط يمكن أن يكون مساهمة كبيرة في المشروع.

بسبب متلازمة الدجال المنتشرة في صناعتنا ، غالبًا ما نجد أنفسنا مذنبين بالمشاكل التي تنشأ. تم تفويت شيء في الوثائق ، أو ببساطة لم تكن ذكية بما فيه الكفاية. لكن لا تنسى الدرس من القصة الأولى: لا يوجد مستخدمون سيئون ، فهناك واجهة سيئة فقط. وليس هناك مطورين سيئين ، لا يوجد سوى أدوات تطوير سيئة.

إذا ارتكبت خطأً عند استخدام الإطار ، فأنت على الأرجح ليست الأولى وليس الأخيرة. بالإضافة إلى ذلك ، نظرت إلى المنتج من منظور فاته المطورين الذين يشاهدون الكود كل يوم. نظرة جديدة تجعل من الأسهل ملاحظة المشاكل في التوثيق وتجربة التطوير العامة.

قمت بإجراء خطأ مطبعي ، وحصلت على رسالة خطأ غير مفهومة ونتيجة لذلك ، أمضيت ساعة في تصحيح الأخطاء؟ هذه فرصة رائعة لتحسين رسالة الخطأ مع الإصدار الجديد أو PR. تبحث عن وسيلة في جميع أنحاء المكتبة لفترة طويلة جدا؟ فكر في المعلومات التي يمكن أن تساعدك في الوثائق.

الدرس الثالث: الثقة في التشغيل الآلي

حدثت هذه القصة في عام 1997 مع محطة مير الفضائية التي انتهت صلاحيتها الآن.

كان هناك فرق مهم واحد بين برنامج الفضاء السوفيتي والأمريكي. في اتحاد الجمهوريات الاشتراكية السوفياتية ، تم إنشاء السفن من قبل نفس الأشخاص الذين أنشأوا الصواريخ: لقد استخدموا الأتمتة على نطاق واسع واعتبروا أن الطيارين يشكلون عبئًا عمليًا. وفي الولايات المتحدة الأمريكية ، تم إنشاء السفن (على وجه الخصوص ، مكوك الفضاء) من قبل أشخاص قاموا بتصميم الطائرات ، واعتبروا أجهزة الكمبيوتر فقط بمثابة أدوات مساعدة للطيارين.

منذ عام 1967 ، استخدم اتحاد الجمهوريات الاشتراكية السوفياتية أنظمة الإرساء التلقائي بالكامل: أولاً ، Igloo ، ثم Course. مكّنت هذه التطورات من بناء محطة Mir من وحدات تلقائية تعمل كمركبة فضائية مستقلة مع أجهزة الكمبيوتر الخاصة بها وأنظمة الطاقة والمحركات.


وحدات من محطة مير.

ومع ذلك ، تم تصنيع أنظمة الالتحام السوفيتي في أوكرانيا ، وبعد انهيار الاتحاد السوفيتي ، لم توافق موسكو وكييف على الأسعار. قام Roscosmos ، في محاولة للحد من اعتماده على المكونات الأجنبية ، بتطوير بديل - TORU ، والذي سمح للمشغل في المحطة الفضائية بالتحكم عن بعد في السفينة باستخدام جويستيك.

تم اختبار TORU بنجاح في الفضاء. في عام 1997 ، رست السفينة Progress M-34 المحملة بالشحن إلى المحطة بنجاح تلقائيًا إلى العالم. وبعد ذلك ، بشكل غير متوقع ، كانت هناك تعليمات بإلغاء الإرساء ، وبدلاً من العودة إلى الأرض ، أعد توصيلها إلى المحطة يدويًا للتحقق من نظام الإرساء مرة أخرى.


فاسيلي تسيبليف يسيطر على السفينة من محطة مير.

حاول الطاقم الحفاظ على السيطرة على "بروجرس" المحملة بأكثر من طاقتها (حملت المجموعة التالية من النفايات من المحطة ، والتي كان من الضروري إعادتها إلى الأرض) ، وكان من الصعب اكتشاف مير على الفيديو المنقول من السفينة. عندما رأى رواد الفضاء أخيرًا السفينة التي تقترب من النوافذ ، فقد فات الأوان على التباطؤ. ألحقت السفينة أضرارًا بالألواح الشمسية لوحدة Spectrum التي وفرت 40٪ من كهرباء المحطة ، وأحدثت ثقبًا في الهيكل.

سمع رواد الفضاء صافرة وكانت آذانهم مسدودة. كانت المحطة تفقد الهواء.

اضطر الطاقم إلى فصل الكابلات القادمة من Spectrum وإغلاق الوحدة وتركها مغلقة. وبعد ثلاث سنوات ، غمرت المحطة في المحيط.

نتيجة لذلك ، لم يتم التخلي عن الدورة التدريبية من نظام الالتحام ، واليوم يتم تصنيعها في روسيا. يتم استخدام الدورة و TORU على السفن الروسية ، TORU هو نظام النسخ الاحتياطي.

حتى يومنا هذا ، أسباب الاصطدام الأول والوحيد في الفضاء ليست واضحة تمامًا حتى الآن. تم تغيير مركز كتلة السفينة بسبب الحمولة الزائدة ، وكان رواد الفضاء متعبين و TOPU سيئة ملكية. تم تنظيم الاختبار نفسه على عجل: في تلك اللحظة ، كان رائد فضاء أمريكي على متن العالم ، ولم يكن هو ولا ناسا على علم بالاختبار حتى تم الضغط على المحطة.


الأضرار التي لحقت العالم بعد تصادم مع التقدم 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 for JavaScript و Stylelint for CSS) جيدًا الأخطاء التي قد تكلفك الكثير من الوقت والمال. سوف تقضي عدة ساعات في كتابة ملحق linter الخاص بك ، ولكن على المدى الطويل ، سيؤتي ثماره.

تريد تجنب الأخطاء المطبعية في الوثائق؟ حاول yaspeller . هل تريد تنظيم العقارات في CSS بطريقة ما؟ أضف stylelint-order إلى أدوات التطوير الخاصة بك .

* * *

آمل أن تستمتع بقصصي الفضائية. حتى لو بدت بعيدة المنال بالنسبة لك ، تظل الدروس المستفادة مفيدة لجميع مطوري البرامج.

إن تاريخ استكشاف الفضاء ليس فقط مصدر إلهام لقصصي في المؤتمرات والحفلات اللاحقة ، ولكنه أيضًا بمثابة مصدر للتقنيات الصحيحة. ما الذي يذكرك بشكل أفضل بضرورة إرسال تقرير عن المشكلة من سفينة الفضاء المحترقة؟