العديد من المشاريع التي عملت بها ، مشاريع كبيرة ، تحولت إلى إرث ، ولحية تتفكك ، ونتيجة لذلك ، أصبح التطوير صعبًا للغاية. كانت هناك أوقات عندما ماتت المشاريع للتو بسبب الصعوبة الجهنمية لإجراء التغييرات. سأخبركم اليوم عن تجربتي في العمل مع المشاريع ، ولماذا أكتب لكم كل هذا على الإطلاق. كل شيء شخصي للغاية ، بالطبع.
لذا ، عملت ، وحاولت ، كبحار يريد أن يجرف المياه ويمنع السفينة من الغرق ، لكن جودة المشروع كانت تتدهور بشكل مطرد ، وكانت هناك عدة أسباب.
سوف تتعرف عليهم بسهولة ، فهم مرضى عاديون ، وسوف أذكرك بهم:
- الهيكل ضعيف ، من الصعب تنفيذ حل جديد
- أخطاء الترميز
- لا يوجد اختبار تلقائي
نتيجة لذلك ، وفقًا لنتائج تطوير المشروع خلال أول عام أو عامين ، تم الحصول على مزيج من الموروث ، والرمز الغامض ، والأنفاق المتشابكة مع الممرات السرية ، واللوحات الصخرية "تعمل هكذا ، لماذا لا أعرف".
أنا لا أتطرق إلى هذا كثيرًا ، فهذا هو الموضوع الأول في إعادة البناء ، لذلك مباشرة في الاستنتاجات التي توصلت إليها.
المنتج المطور هو خبرة جماعية
إذا كان لدى الفريق مطور واحد ضخم ، تم ضخه بالفعل ، ويعمل بشكل جيد ، فلن يقوم بتنظيفه بمفرده ، لأن الفريق يرتكب أخطاء باستمرار وسيسحب المشروع باستمرار.
يمكنك ، بالطبع ، محاولة إعطاء الفريق الحالي مهمة إعادة هيكلة ، ومن ثم يقوم أولئك الذين قاموا بلحامها بإعادة بناء نتيجة عملهم ، وسيعطون نفس الشيء ، حسنًا ، ربما أفضل قليلاً من المرة الأولى.
لذلك ، يجب ألا تتوقع ترقية جودة جذرية بدون ترقية الفريق.
هذه الحلقة المفرغة رقم 1 - خبرة الفريق ليست كافية ، لكن إعادة البناء تبدأ ، والانتباه ، نفس الأشخاص الذين كتبوها يفعلون ذلك.
بدلاً من ذلك ، يمكنك وضع عميل محتمل جيد يقوم بإجراء مراجعة وتنظيف هذه الأخطاء (على الرغم من أنه سيحاول القيام بذلك) ، ولكن في النهاية سينتهي الأمر بصداع لأولئك الذين يعملون بشكل سيئ ، ثم إما استبدال المطورين ، أو أنهم سيغادرون هم أنفسهم ، ومرة أخرى ، تحصل على بديل للمطورين.
سيكون نوعًا من الاختيار الطبيعي في المشروع.
يخشى الناس تغيير الكود
مرحبًا ، هذه جلسة علم نفس للمبرمجين.
المبرمجون خائفون حقًا من تغيير الكود ، ويمكن فهمهم:
- لا توجد اختبارات كافية أم لا
- كيف يعمل الكود غير واضح
- التواريخ في
- لا توجد موارد
- لن تفهم الإدارة (طبيعي ، ولكن إذا اشتعلت النيران في الإدارة ، فسيكون كل شيء على ما يرام)
نتيجة لذلك ، يُنظر إلى الشفرة القديمة المربكة القديمة التي تسحب المشروع لأسفل على أنها "من الأفضل عدم اللمس" ، ونتيجة لذلك فإن "عدم اللمس" يستمر إلى الأبد ، بل والأسوأ من ذلك ، يجبرك على كتابة التعليمات البرمجية بطريقة معينة ، مما يتسبب في مشاكل فنية أخرى ثم يقومون أيضًا بسحب المشروع لأسفل.
نأخذ مشروعًا ، ورمزًا خاطئًا ، ومخاوف الفريق ، ونضربها بمرور الوقت ، ونحصل على دين فني ضخم ، والذي يقف على حافة الهاوية ولا يسمح للفريق بالتحرك بشكل طبيعي وتطوير المشروع بسرعة.
يبدأ المشروع في الانهيار ، وتعطل المواعيد النهائية ، وتصبح الميزات الجديدة أكثر تكلفة بشكل كبير بالنسبة للمشروع ، ويبدأ المطورون في الشعور بالتوتر ، ويغادر البعض ، ويصعب العثور على عناصر جديدة ، تحصل على الفكرة ...
لذلك ، أعتقد أن هذه هي المشكلة رقم 1 ، الخوف من الكود والمخاطر.
من التجربة ، لوحظ أنه إذا تركت الديون الفنية ، فهذه قنبلة محتملة ، أو على الأقل أشعل النار. اتركهم 100 ، 1000 ، وستحصل على حقل ألغام ، لا تذهب إليه فقط (تطوير المشروع) ، ولن تتمكن من الزحف.
لذلك ، فإن الطريقة الوحيدة لتوفير متوسط سرعة تطوير المشروع وعدم خفض الجودة هي ، بفضل الغطاء ، الانتباه إلى الجودة وتنفيذ إعادة البناء.
حريق المجلس ، الجميع يعرف عنها ، لكن في الحقيقة لم تذهب القائمة أعلاه إلى أي مكان ، لذلك لا يمكنك فقط أخذها وإعادة بنائها ، لأنك ستحصل على مشروع ينهار ، ولماذا؟
نظرًا لعدم وجود اختبارات ، فإن كيفية عمل الكود غير واضح ، ونتيجة لذلك ، بدلاً من تغيير رسومات السيارة وتجميعها ، اتضح أن Vasya و Petya أخذوا طاحونة ، ونشروا Solaris ، وأعادوها إلى Tavria ، لكنها لم تذهب. لماذا ا؟ - أوه ، ولكن لأننا لم نكن نعرف عن هذا التأثير / السلوك / المهام
نعم ، يمكنك إعادة البناء بدون اختبارات ، ثم الاستقرار ، ولكن يمكن فقد العديد من البرامج النصية للمستخدم ، أو البرامج النصية اللازمة لتنفيذ التعليمات البرمجية ، أو قد يستغرق التثبيت وقتًا طويلاً جدًا.
لذلك ، هناك حلقة مفرغة أخرى - لا يمكنك ترك الشفرة بمفردها ، لكن لا يمكنك إعادة تشكيلها أيضًا ، كما كانت ، لأن هناك مخاطر كبيرة.
اتضح أننا لسنا بحاجة إلى Legacy ، لكن التخلص منه أمر مخيف وخطير ، لذلك غالبًا ما تترك الفرق Legacy على أنها "الخيار الأقل خطورة" من أجل الحصول على حل أكثر خطورة للمشروع لاحقًا.
الاختبارات هي المفتاح
اتضح أنه من أجل فتح إعادة البناء وجعله آمنًا ، فأنت بحاجة أولاً إلى تغطية جميع الحالات بالاختبارات ، وبعد ذلك عندما نقطع سولاريس ونجمعها إلى تافريا ، سيتوقف اللحام ويقول ، "مرحبًا ، نحتاج إلى سولاريس ، لقد أخطأت هنا."
تسمح لك الاختبارات بتجنب الأخطاء أثناء إعادة البناء ، أي لجعله آمنًا ، وبعد ذلك يمكنك قطع المشروع كما تريد وتحتاج دون خوف شديد من أن المخاطر ستنجح وستكون هناك مشاكل.
لذلك ، نحصل على سلسلة:
الاختبارات -> إعادة البناء -> وداعًا للحية والإرث
. يبدو الأمر بسيطًا وجميلًا ، ولكن في الممارسة العملية هناك القليل من الاختبارات. أو لا يحدث على الإطلاق ، وهناك عدة أسباب لذلك كالعادة:
- يعتبر المطورون الاختبارات كموضوع منفصل ولا يستثمرون في التقييمات ؛ فهم يكتبون بشكل منفصل عن التطوير. يكون الأمر أكثر صعوبة إذا اعتقدت إدارة المشروع ذلك وأرادت قطع الاختبارات للوفاء بالمواعيد النهائية.
- الاختبارات حان الوقت ، ويجب تسليم المشروع الآن ، ولا يوجد وقت لكتابة الاختبارات لنا (نظريًا ، هذا هو نفس النقطة رقم 1)
- المشروع / المكون بسيط ، لماذا توجد اختبارات ، كل شيء بسيط للغاية ويعمل هناك؟
- أولاً ، سنكتب الكود ، ثم سنقوم بتغطيته بالاختبارات. لكن لا ، لم نحصل عليه ، المشروع لم يتوقف ، لم يكن هناك وقت. إذن هذه المهمة تكمن في الصندوق الأسود إلى الأبد.
هناك بالفعل مليون سبب ، ولكن الحقيقة هي أنه يمنع إعادة البناء ، ونتيجة لذلك ، لا يسمح للجودة بالنمو.
لذلك ، تعد الاختبارات مهمة حاسمة ، وبدونها ، سيكون تطوير المشروع عالي الجودة على المدى الطويل صعبًا إن لم يكن مستحيلًا.
ماذا تفعل يا هيوستن؟
أنا أكتب هذا المقال فقط لأن الجميع لا يفهم هذا ، وهناك على الأقل من سيقرأه ويريد كتابة الاختبارات ، إعادة البناء ، مما يعني أنني لم أكتب هذا المقال عبثًا.
لذلك ، كل شخص لديه واجباته المدرسية - خذ وحدة مكتوبة بشكل سيئ ، ومكون ، وشيء ما ، واكتشف هناك أنك ترغب في إعادة بنائه ، وكتابة اختبارات لهذه الوحدة أو المكون ، وإعادة البناء.
نتيجة لذلك ، سوف تفهم أن الاختبارات هي:
- طريقة لتعلم البرمجة. قد يكون أكثر فاعلية من مجرد قراءته.
- المزيد
- يمكن إعادة هيكلة الكود القديم بالفعل ويمكن تحسين جودة المشروع
لقد كتبت كل شيء في نفس واحد ، بشكل شخصي للغاية ، وربما أكون مخطئًا ، هذه مجرد تجربتي. ربما صادفت مثل هذه المشاريع ، لا أعرف ، لكن المعلومات لا تزال مفيدة ، وإذا كنت تفكر بعد قراءتها ، فهذا جيد أيضًا.
أتمنى للجميع كودًا جيدًا واختبارات وحركة جيدة - لهذا السبب تم تعييننا ، فلنعمل بشكل جيد.
ملاحظة: إذا كنت ترغب في ذلك ، اكتب تجربتك في إعادة البناء في التعليقات ، سيكون الجميع مهتمًا.