متلازمة السباكة: قواعد التعليمات البرمجية القديمة للاختبار

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

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

عندما تعمل مع "برامج طويلة الأمد" ، فإن نسبة كبيرة منها بما فيه الكفاية هي الرمز القديم. على سبيل المثال ، تم تطوير Parallels Desktop منذ أكثر من 15 عامًا. في كل عام يتوسع الفريق ، يأتي أشخاص جدد ، انظر إلى ما هو مكتوب وأعلن: "كل شيء معوج ، دعنا نمزق أيدي المبرمج ونعيد كتابة كل شيء". موقف مألوف؟

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

الحكمة المخولة

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

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

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

ماذا تفعل

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

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

3. D'Artagnan . في معظم الأحيان ، يحدث هذا مع المهندسين الذين ليس لديهم خبرة وتجربة المنتج في المشاريع الكبيرة الذين لا يفهمون السعر الذي يحصلون عليه. رجل يضرب كعبه في صدره ، ويقول إنه سيفعل ذلك ببراعة ، طازجًا ، وفي غضون أسبوع فقط ، ولكن يمكن أن يكون مخطئًا بشدة بشأن قدراته ، ولأنه يفتقد تمامًا نقاطًا مثل الاختبار والاندماج في النظام الأكبر الحالي.

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

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

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

"إنها قبيحة."
المشكلة هي أنه في كثير من الأحيان ليس لدى الشخص حجج أخرى. "غير متقدم تقنيًا" ، "تم إجراؤه على بعض الرسائل غير المرغوب فيها" ، "لماذا تمت كتابتها بالحرف C ، أصبح من المألوف الآن الكتابة في Go." هذه ليست الحجج لإعادة تشكيل النظام. لأنه عندما تتجاوز قطعة واحدة من التعليمات البرمجية ، تبدأ في إدراك أن إعادة العمل الخاصة بك قد تكون أسوأ مما كانت عليه من قبل. قد يبدو أجمل في الداخل ، ويعمل بشكل أبطأ ، وهو أمر غير مقبول للمنتج. لم أر هذا في Parallels ، ولكن في الشركة السابقة كان علينا أن نختبر جميع عواقب هذه الخطوة بشكل كامل. قررنا أن عائلة السائقين لمعدات معينة تم تنفيذها بشكل قبيح ، وكنا بحاجة إلى تصميم أكثر أناقة وتوسعة سيكون من الأسهل الحفاظ عليه وإضافة وظائف جديدة إليه. كتبوا جديدة وجميلة لمدة عام ونصف ، ولكن في النهاية اتضح أنها مروعة ولا تعطي أي مزايا. وتبين أن تكلفة الموارد باهظة جدًا: فقد قام اثنان من المطورين بتلميح شركة ونصف سنة من العمل.

لماذا من الأفضل عدم لمس الكود طويل الأجل لمشروع كبير

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

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

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

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

يمكنك إهدار الموارد
ويرد مثال لمثل هدر الموارد أعلاه. يجب أن نفهم أن أي ثورة تؤدي إلى حرب أهلية ، إلى فترة معينة مع تدهور في الحالة ، حيث لن ينجح شيء.

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

ماذا تفعل عندما يكون قرار عدم إعادة القرار واضحا ، والشخص "يحترق بفكرة"؟

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

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

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

عندما لا تزال بحاجة إلى إعادة

يموت المنتج في ظل الظروف الحالية
حجة الإعادة - إذا تغيرت البيئة الخارجية إلى حد توقف المنتج الحالي عن العمل. على سبيل المثال ، عندما أطلقوا نظام تشغيل جديدًا ، بدأ المستخدمون في التحول إليه بكميات كبيرة ، ولكن تغير شيء ما في نظام التشغيل هذا بحيث توقف منتجك ، الذي كان يعمل بشكل طبيعي في الإصدارات السابقة ، عن العمل أو كان المستخدم غير مرتاح تمامًا لاستخدامه. أو عندما تموت المنصة - على سبيل المثال ، من منصة قديمة ، يمكنك الاستشهاد بـ BeOS ، الذي عملوا بموجبه كثيرًا مع منتجات الوسائط المتعددة ، على سبيل المثال ، الموسيقى المؤلفة. مات النظام ، وبما أنه كان مميزًا تمامًا ، لم يتم نقل الرموز منه عمليًا إلى أنظمة أخرى. مع BeOS OS نفسه ، حدث الشيء نفسه: كانت هناك أجهزة كمبيوتر Atom تستهدفها ، ثم توقفت الشركة المصنعة عن إطلاق هذه المعالجات ، ولم يترك الأشخاص الذين كتبوا لهذا الكمبيوتر عمليًا أي شيء. واضطروا إلى التكيف بشكل عاجل مع Intel ، والتي اتضح أنها سيئة بالنسبة لهم - تم احتلال المكان المناسب وساد نظام تشغيل آخر هناك. ومن أجل إطالة حياتهم بطريقة أو بأخرى ، كان عليهم أن يعيدوها بجدية في اتجاه تحسين قابلية النقل وما إلى ذلك.

عملت متلازمة السباكة: مراحل إعادة البناء

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

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

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

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

أو هذا الخيار: تم إصلاح الواجهة ، ويتم التنفيذ ، ثم تبدأ الواجهة في التغيير بشكل متكرر.

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

بدلا من الاستنتاج

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