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