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