يرث فريقٌ وحدةَ فوترةٍ لا يفهمها أحدٌ تمامًا، ولا توجد اختباراتٌ تحمي سلوكها الحالي. يُقترحُ برنامجُ تطويرٍ سريعٍ "لتنظيفها"، وتتمثلُ الخطةُ في إعادةِ كتابةِ جوهرِها بهيكلٍ جديد. لا أحدَ يستطيعُ التأكدَ من أنَّ النسخةَ الجديدةَ لا تزالُ تُحاسبُ العملاءَ بشكلٍ صحيح.
هذا سيناريو توضيحي، وليس حادثة موثقة. يصف هذا السيناريو الفجوة التي يجب على مشروع تدريب إعادة هيكلة الكود سدها: مهندسون يرون أن الكود غير منظم، لكنهم لا يستطيعون بعدُ وضع خطة لتحسينه بشكل محدد وإثبات الحفاظ على سلوكه.
هذا الدليل مُخصّص لقادة تمكين الهندسة ومديري الهندسة. يُغطي كيفية وصف مشكلة الأداء، وتشخيص الثغرات، وإعداد التصميم والتطبيق العملي، ودراسة حالة عملية، وتقييم مدى قابلية تطبيق المهارات في بيئة العمل الحقيقية. يتناول الدليل تصميم التدريب. يجب على كبار المهندسين التحقق من صحة الكود والاختبارات والقواعد في برنامجك باستخدام منظومتك الخاصة.
ما هو مشروع تدريب إعادة هيكلة البرمجيات؟
مشروع تدريب إعادة هيكلة البرمجيات هو عمل منظم على الشيفرة البرمجية القديمة، يهدف إلى بناء القدرات وتحسين الشيفرة في آن واحد. يخطط المتدربون لتغيير صغير ومحدود، ويحمون السلوك الحالي بالاختبارات، ويحسنون التصميم تدريجيًا، ويقدمون أدلة تثبت عدم وجود أي خلل. تتحسن الشيفرة، والأهم من ذلك، يكتسب المهندسون الخبرة اللازمة لتقييم الديون التقنية الحقيقية.
حقائق سريعة
| سؤال | اجابة قصيرة |
|---|---|
| ما هي المهمة؟ | قم بالتخطيط والتحقق من صحة تحسين محدود للبرمجيات القديمة. |
| ما هي نتيجتك؟ | تحليل المخاطر، والأدلة التي تشير إلى الحفاظ على السلوك الحالي. |
| هل إعادة كتابة شاملة مشروع تدريبي جيد؟ | في الغالب لا. فهو يخفي المهارة التي يتم التدرب عليها ويجعل من الصعب إظهار السلوك المحفوظ. |
| هل يكفي اختبار قصير حول أنماط إعادة هيكلة الكود؟ | لا. إنه يؤكد المتطلبات الأساسية، ولكنه لا يؤكد ما إذا كان بإمكان المهندس التخطيط للتغيير والتحقق من صحته. |
| من الذي يتحقق من صحة المحتوى؟ | مدير هندسي ومهندس أول على دراية بقاعدة البيانات. |
| ما الذي لا يستطيع التدريب إصلاحه؟ | نقص أدوات الاختبار، وضغط التحرير، وعدم وضوح الملكية، وعدم وجود وقت لأعمال الصيانة. |
| كيف عرفت أنها نجحت؟ | حالة جديدة وغير مسبوقة من حالات البرمجيات القديمة، تم تقييمها وفقًا لمعايير متفق عليها، مع متابعة العمل الفعلي. |
1. صف مشكلة الأداء
ابدأ بالمهمة: خطط وتحقق من صحة تحسين محدود للبرمجيات القديمة. كلمة "محدود" هي الكلمة الأساسية. يختار المتعلم تغييرًا صغيرًا بما يكفي لإنجازه، ويمكنه تحديد ما هو داخل نطاق التغيير وما هو خارجه.
من المفيد استخدام المصطلحات بدقة. يصف مارتن فاولر عملية إعادة هيكلة الكود بأنها تقنية مضبوطة لتحسين تصميم قاعدة بيانات برمجية موجودةيتألف من تحويلات صغيرة تحافظ على السلوك. عبارة "الحفاظ على السلوك" هي ما يميز إعادة الهيكلة عن إعادة الكتابة، وهي ما يجب أن يُظهره التدريب. استعارة الدين التقني نفسها صاغ هذا المصطلح وارد كانينغهاموتُعد مناقشة فاولر بمثابة تذكير مفيد بأن الديون يمكن تحملها عن قصد وبحكمة، لذلك ليس كل وحدة فوضوية خطأ يجب إصلاحه.
يتبنى كتاب مايكل فيذرز حول البرمجيات القديمة نفس النهج فيما يتعلق بالتطبيق العملي. ويذكر وصف الناشر أنه يعلم المطورين كيفية كتابة اختبارات تضمن إنهم لا يغيرون التطبيق عن غير قصدولتحقيق السيطرة على البرامج الحالية دون الحاجة إلى إعادة كتابتها بالكامل.
اكتب بيان الأداء في جملة واحدة واطلب من مدير الهندسة التحقق منه: "بالنظر إلى وحدة نمطية قديمة وهدف محدد، يقترح المهندس تغييرًا محدودًا، ويضيف اختبارات تحدد السلوك الحالي، ويجري التغيير على خطوات صغيرة، ويظهر أن السلوك محفوظ."
2. تشخيص فجوات التعلم والسياق
قبل البدء في أي مشروع، قارن المهمة المطلوبة بما تمارسه في أنشطتك الحالية وقيمها. عادةً ما تُحدد ثلاثة أسئلة فجوة التدريب عن أي مشكلة أخرى:
- هل تستخدم الممارسة الحالية المهمة الحقيقية؟ إذا اقتصر التدريب على عرض أنماط إعادة هيكلة الكود في الشرائح، ولكن لم يقم أحد بتغيير الكود غير المختبر، فلن يكون أحد قد مارس حماية السلوك. وإذا كان التقييم عبارة عن اختبار متعدد الخيارات حول عيوب الكود، فإنه يقيس مدى استيعاب المستخدم.
- ما هو المطلب المعرفي؟ في تصنيف بلوم المُعدَّل، يقع تقييم مدى أمان التغيير ضمن مستويي التحليل والتقييم، بينما يصل تصميم الخطة والاختبارات إلى مستوى الإنشاء. ويُغطّي دليلنا كيفية ربط الأنشطة بهذين المستويين. مطابقة أنشطة التعلم مع تصنيف بلوم.
- هل هناك شيء آخر غير المهارة يعيق الأمر؟ راجع عدد الموظفين والأدوات والإجراءات. إذا استغرقت عملية البناء ساعة، فلن يُجري أحد اختبارات بشكل متكرر. وإذا لم تُجدول أعمال الصيانة، فلن يُجري المهندسون أي تعديلات إلا سرًا. أبلغ عن الأسباب غير المتعلقة بالتدريب للأشخاص القادرين على حلها.
3. تصميم إعداد وتدريب هادف
بمجرد أن تعرف الثغرات التي يمكن للتدريب أن يسدها، امنح كل مرحلة مهمة مميزة.
التحضير. تحقق من المتطلبات الأساسية من خلال تشخيص موجز: كيف يعمل إطار الاختبار الخاص بك، وما هو اختبار التوصيف، وكيف يقوم فريقك بالمراجعة والدمج. الدراسة الذاتية مناسبة لهذه المرحلة. أما مراجعة المعلومات فتؤكد المتطلبات الأساسية فقط.
الممارسة. استخدم مشاريع إعادة هيكلة منهجية ذات شكل واضح. ابدأ بعينة صغيرة وآمنة، ثم انتقل إلى جزء حقيقي ومحدد من قاعدة بياناتك البرمجية. تُعدّ "Gilded Rose" (الوردة الذهبية) نقطة انطلاق معروفة للخطوة الأولى. ملف README الخاص بها، والذي تُشرف عليه إميلي باش، يوصي بكتابة الاختبارات قبل تغيير الكود ويُقدّم التمرين كتدريب على اتخاذ خطوات صغيرة، وإجراء الاختبارات بشكل متكرر، وتحسين التصميم تدريجيًا. التسلسل الأمثل لكل مشروع هو: تحديد الهدف والحدود، وكتابة اختبارات تُغطي وظيفة الكود الحالية، وتغيير عنصر واحد في كل مرة، وإجراء الاختبارات بعد كل خطوة، وتدوين ما تم تعلمه.
ردود الفعل. اربط الملاحظات بالقرارات، لا بالنتيجة الإجمالية. فعبارة "لقد استخرجت منطق الخصم، لكن اختباراتك غطت المسار الأمثل فقط، لذا لم يكن بإمكانك ملاحظة تغيير التقريب" أكثر فائدة من "3 من 5".
هل تفضلون تلقي ملاحظات مباشرة من المدرب أم مراجعة غير متزامنة؟ تُضيف المدخلات المباشرة قيمةً كبيرةً عندما يكون الخيار غامضًا، على سبيل المثال، ما إذا كان ينبغي التوقف وإضافة اختبار مفقود أو المتابعة. أما المراجعة غير المتزامنة فهي كافية عندما يقارن المتعلمون خطتهم واختباراتهم بنسخة خبير مُعلّقة. تستخدم العديد من الفرق كلا الأسلوبين: التحضير الذاتي أولًا، ثم جلسة مُيسّرة للحالات الصعبة.
4. قم بدراسة مثال واقعي
توضيحي. يجب على مدير الهندسة التحقق من صحة الحالة ومعايير الإجابة قبل الاستخدام.
القضية. تقوم وظيفة قديمة بحساب إجمالي الطلب، بما في ذلك الخصم والضريبة وقواعد الشحن. وهي تفتقر إلى الاختبارات. يقترح فريق إعادة هيكلة وحدة الفوترة بالكامل لجعلها أكثر سلاسة.
المهمة. يشرح المتعلم ما سيفعله، ويستشهد بالأدلة التي سيجمعها، ويذكر ما هي المعلومات أو الدعم الإضافي الذي يحتاجه.
محاولة أولى. «سأقسم الوحدة إلى ثلاث خدمات، وأنقل المنطق إليها، ثم أتحقق من الأرقام في بيئة الاختبار». اختار المتعلم تغييرًا كبيرًا وفحصًا يدويًا متأخرًا. لا توجد طريقة لمعرفة ما إذا كانت النسختان القديمة والجديدة تتفقان في الحالات الاستثنائية.
تلقي الملاحظات وإعادة المحاولة. يسأل المراجع عن وظيفة البرنامج الحالية في حالة سلة فارغة، أو خصم يجعل المجموع سالباً، أو تقريب الأرقام. ويطلب من المتعلم في المحاولة الثانية حصر نطاق البرنامج في سلوك واحد، وشرح كيفية إثبات عدم تغيره.
محاولة أقوى. سأترك بنية الوحدة كما هي في الوقت الحالي. سأسجل نتائج دالة إجمالي الطلب الحالية لمجموعة من المدخلات، بما في ذلك الحالات الاستثنائية، كاختبارات. ثم سأستخرج حساب الخصم في دالة مستقلة، وأجري الاختبارات بعد هذه الخطوة، وأتوقف. سأشير إلى أن قاعدة الشحن تتضمن سلوكًا غير مفهوم، وسأستشير زميلًا قبل تعديلها. لاحظ أن هذا الحل يحدد نطاق التغيير، ويحمي السلوك أولًا، ويحدد ما هو غير معروف.
لماذا كل رد قابل للدفاع عنه أو غير مكتمل. قيّم كل محاولة وفقًا لمعايير معتمدة، وليس وفقًا لتفضيلات المُقيِّم. قد تكون المحاولة الأولى اتجاهًا منطقيًا على المدى الطويل، لكنها غير مكتملة كخطة، لأنها لا تحمل دليلًا على استمرار السلوك. أما المحاولة الأقوى فهي صغيرة، وقابلة للمراجعة، وصادقة بشأن عدم اليقين.
5. تقييم القدرات وتخطيط عملية النقل
يُعدّ الأداء في حالة استخدام برنامج قديم جديد لم يسبق للمتدرب رؤيته دليلاً على كفاءته. يُقيّم تحليل المخاطر والأدلة التي تُثبت الحفاظ على السلوك المطلوب. يستخدم معيار تقييم بسيط مقياسًا من 0 إلى 2 لكل معيار.
| معيار | أدلة قابلة للملاحظة |
|---|---|
| تنفيذ المهمة | يخطط ويتحقق من صحة تحسين محدود للبرمجيات القديمة، ويسجل الإجراءات والأدلة التي تدعمها. |
| منطق | يشرح القيود والبدائل وعدم اليقين، ويتحقق من المخاطر والأدلة التي تثبت الحفاظ على السلوك. |
| الحدود | يستخدم الإجراءات المعتمدة، ويطلب المساعدة عندما تكون المعلومات أو السلطة غير كافية. |
المعايير: 0 تعني غياب أو عدم وجود دعم، 1 تعني جزئية مع وجود إغفالات ذات صلة، و2 تعني اكتمال وتبرير وفقًا للمعايير المتفق عليها. حدد الأخطاء الحرجة بشكل منفصل، مثل تغيير السلوك دون وجود اختبار كان من شأنه أن يلاحظه، بحيث لا يمكن للدرجة الإجمالية إخفاء أي خطأ. هذا المعيار هو مجرد اقتراح، وليس معيارًا معتمدًا للجاهزية: قم بتكييفه مع مدير هندسي وجرّبه. دليلنا لـ تصميم تمارين تفاعلية مع تقديم ملاحظات مفيدة يوضح كيفية كتابة التعليقات التي ترتبط بالقرارات.
خطط لعملية النقل بعناية. بعد التمرين، امنح كل مهندس مهمة صغيرة وحقيقية لمعالجة مشكلة ما مع المراجع، أو قم بإجراء مراجعة سريعة لتغيير حديث تسبب في خلل ما. تحقق من عملية النقل بعد تعرض المهندس بشكل كافٍ للعمل الفعلي، وليس مباشرة بعد ورشة العمل.
حيث يساعد التوصيل التفاعلي
تُساعد التنسيقات التفاعلية في ضمان التزام جميع المشاركين قبل رؤية المجموعة. في جلسة مباشرة، يُمكن للمُيسّر عرض جزء قصير من الكود القديم، ثم يطلب من كل مهندس تقديم التغيير الأول الذي سيُجريه وكيفية إثبات سلامته، ثم عرض النتائج قبل بدء المناقشة. يُمكن استخدام نفس التوجيهات بشكل فردي للتحضير. يدعم AhaSlides التعلّم التفاعلي والتنقل بين العرض المباشر والعرض الفردي. إنه أداة للعرض والتعلّم، وليس مكانًا لتشغيل أو تحليل التعليمات البرمجية، لذا يُنصح بتشغيل عملية إعادة هيكلة الكود في بيئتك الخاصة. راجع أي وظيفة مُحددة للتأليف أو التعليقات أو إعداد التقارير التي تُخطط للاعتماد عليها في سير عملك. للاطلاع على إرشادات حول اختيار التنسيقات، راجع مقالتنا حول متى يتم استخدام التعلم التكيفي والتفاعلي والمباشر؟.
قم بقياس ما تغير
حدد مسبقًا ما يُثبت قدرة المهندسين على إنجاز المهمة. قارن جودة تحليل المخاطر وأدلة الحفاظ على السلوك في حالة غير مسبوقة، مع خط أساس. حدد من يشملهم التحليل، والمقام، والتوقيت. إذا تحسنت النتائج، فتحقق من التغييرات الأخرى التي طرأت خلال الفترة نفسها، مثل أدوات اختبار جديدة، أو تسريع عملية البناء، أو تغيير الملكية، قبل اعتماد التدريب.
القيود التي قد تبقى
- حان وقت أعمال الصيانة. إذا لم يتم جدولة أعمال سداد الديون، فلن يجد المهندسون المدربون مكاناً لاستخدام مهاراتهم.
- أدوات الاختبار. بدون نظام اختبار قابل للاستخدام أو عملية بناء سريعة، يصعب الحفاظ على الخطوات الصغيرة والفحوصات المتكررة.
- تغطية القضية. تُظهر إحدى الحالات القديمة أنواعًا قليلة من المخاطر. ولا تعكس النتيجة تقييم المهندس بشكل عام.
- تحديد متى لا ينبغي إعادة هيكلة الكود. من الأفضل ترك بعض الأكواد كما هي، أو استبدالها أو إيقافها، وهذا القرار يتطلب أكثر من مجرد مهارة.
- تحويل. الأداء في الكاتا ليس هو نفسه الأداء في وحدة إنتاج تحت ضغط التسليم.
أبلغوا الجهات الراعية بهذه المشكلات مبكراً وخططوا لإصلاحات منفصلة. التدريب يُحسّن قدرة المهندس على التخطيط والتنفيذ، لكنه لا يوفر الوقت أو الأدوات.
الأسئلة المتكررة
ما هو مشروع تدريب إعادة هيكلة البرمجيات؟
إنها ممارسة منظمة على التعليمات البرمجية القديمة حيث يخطط المهندسون لتغيير صغير، ويحمون السلوك الحالي بالاختبارات، ويغيرون التصميم على خطوات صغيرة، ويظهرون أنه لم يحدث أي عطل.
هل إعادة كتابة البرنامج بالكامل طريقة جيدة للتعرف على الديون التقنية؟
عادةً لا. إعادة كتابة الكود عملية ضخمة، يصعب التحقق من صحتها، وتخفي المهارة التي ترغب في تطويرها. أما التغيير المحدود مع اختبارات ترصد السلوك الحالي فيجعل المنطق واضحًا.
كيف يمكنك تقييم ما إذا كان بإمكان المهندسين إعادة هيكلة الكود بأمان؟
قدّم حالة جديدة لرمز برمجي قديم، وقيّم تحليل المخاطر والأدلة التي تثبت الحفاظ على السلوك وفقًا للمعايير المتفق عليها. اختبار قصير حول أنماط إعادة هيكلة الكود يؤكد استيفاء المتطلبات الأساسية فقط.
هل تحتاج إلى نموذج لقاعدة بيانات التدريب؟
أنت بحاجة إلى مكانٍ آمنٍ للتدرب. تبدأ العديد من الفرق بتدريبٍ عامٍ ثم تنتقل إلى جزءٍ مُحددٍ من كودها الخاص. يجب على مدير الهندسة لديك التأكد من ملاءمة الكود.
من أين أبدا
اختر تغييرًا واحدًا صغيرًا ومتكررًا من التغييرات القديمة في قاعدة بياناتك. اكتب بيان الأداء، واطلب من مدير الهندسة التحقق من الحالة والاختبارات التي تُظهر السلوك المحفوظ، وصغ معيارًا من ثلاثة معايير بمقياس من 0 إلى 2 وقائمة بالأخطاء الحرجة. جرّبه مع مجموعة صغيرة قبل إطلاقه.
للاطلاع على كيفية إجراء تمرين اتخاذ قرار إعادة الهيكلة بشكل مباشر مع فريقك الخاص، وإعادة استخدامه بوتيرة ذاتية بعد ذلك، استكشف AhaSlides.
