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