عندما قام Github بشحن طلب السحب (PR) لأول مرة في عام 2008 ، فقد لفت نصًا عاديًا في تدفق العمل الاجتماعي: التعليقات ، والموافقات ، وزر دمج يرفض بشكل أساسي الإضاءة دون ما لا يقل عن إبهام واحد من مطور آخر. قرار التصميم هذا المساءلة الصلبة في البرامج الحديثة والسماح للمحاربين بتوسيع نطاق محادثات الردهة أو تصحيحات البريد الإلكتروني.

بعد سبعة عشر عامًا ، لا تزال كل أداة ترميز “Agentic” ، من عروض الأبحاث إلى منصات المؤسسات ، تقوم بتسليط عملها من خلال بوابة الدمج نفسها. يظل العلاقات العامة هو سجل التدقيق ، وطبقة الحوكمة ، والعقد الاجتماعي الذي يقول لا شيء يشحن حتى يكون الشخص على استعداد لامتلاكه.

الآن بعد أن تمكنت نماذج اللغة الكبيرة (LLM) من سقالة المشاريع ، وتقديم PRS ، وحتى الرد على التعليقات المراجعة التي كتبوها بأنفسهم ، فإن السؤال التالي الواضح هو ، من هو المسؤول عن الكود الذي يشحن عندما يأتي جزء منه من نموذج؟

في Github ، نعتقد أن الإجابة لم تتغير بشكل أساسي: إنه المطور هو الذي يضرب “دمج”. ولكن ما تغير هو كل ما يحدث قبل هذا النقر.

في هذه المقالة ، سنستكشف كيف نعيد التفكير في مراجعات الكود لعالم يعمل فيه المطورون بشكل متزايد مع الذكاء الاصطناعي (وكيف يمكن لفريقك أيضًا).

ما تعلمناه من قدرات مراجعة رمز Github Copilot

في وقت سابق من هذا العام ، أجرى فريق Github Copilot Code Review مقابلات متعمقة مع المطورين حول عملية مراجعة الكود الخاصة بهم. كما سارونا من خلال سير عمل مراجعة الكود. كشفت هذه المقابلات عن ثلاثة أنماط متسقة:

1. لا معاملة خاصة لمنظمة العفو الدولية: قام المراجعون المشويون بإنشاء النماذج الصعبة مثل تلك الموجودة في المطورين الآخرين.
2. رفعت المراجعات الذاتية الأرضية: المطورين الذين ركض مراجعة Copilot قبل فتح العلاقات العامة غالبًا ما يتم القضاء على فئة كاملة من المخططات التافهة (أي ، الواردات المشذبة ، الاختبارات المفقودة) ، وتراجع عن الثلث تقريبًا.
3. لم يكن منظمة العفو الدولية بديلاً للحكم البشري: غالبًا ما تتضمن البرمجة المقايضات. يمكن لـ LLMS إبلاغك بهذه المفاضلات ، ولكن يتعين على شخص ما إجراء الدعوة حول المسار الذي يجب اتخاذه بناءً على أهداف ومعايير مؤسستك.

سرعان ما أصبح مبدأ شامل واضحًا: منظمة العفو الدولية تزيد من الحكم المطور ؛ لا يمكن استبداله. وتبلغ النتائج التي توصلنا إليها ، من درجات الثقة إلى التفسيرات الحمراء ، كيف نبني ميزات مراجعة رمز CoPilot.

ما يمكن (ولا يمكن) التعامل (ولا يمكن) التعامل معه اليوم

LLMS رائعة بالفعل في طبقة “طحن” للمراجعة:

• المسح الميكانيكي. “هل هناك خطأ مطبعي؟” “هل كل الحجج تستخدم؟”
• مطابقة نمط. “هذا يبدو مثل حقن SQL” أو “لقد نسيت في انتظار هذا الوعد”.
• الاتساق المتحذرين. “الأسماء المتغيرة Snake_case هنا ، Camelcase هناك.”

قريباً سيكونون قادرين على فعل المزيد ، مثل فهم سياق المنتج والمجال. لكنهم ما زالوا يختصرون:

• الهندسة المعمارية والمقايضات. هل يجب أن نقسم هذه الخدمة؟ ذاكرة التخزين المؤقت محليا؟
• الإرشاد. شرح لماذا نمط مهم ومتى يكسره.
• قيم. هل يجب أن نبني هذه الميزة على الإطلاق؟

هذه الثغرات تبقي المطورين في الحلقة وفي مقعد الطيار. هذا المبدأ أساسي بالنسبة لنا ونحن نستمر في تطوير Github Copilot.

كتاب اللعب لمراجعات التعليمات البرمجية الحديثة

يبدأ النهج الأكثر فعالية في مراجعات الرمز المدعوم من AI قبل إرسال طلب السحب الخاص بك. فكر في الأمر باعتباره القاعدة الذهبية للتنمية: علاج المراجعين عن الكود بالطريقة التي ترغب في معالجتها لك.

استخدم منظمة العفو الدولية لمراجعة الرمز الخاص بك في IDE الخاص بك

قبل دفع الكود الخاص بك ، قم بتشغيل مراجعة رمز Github Copilot في IDE الخاص بك للقبض على الأشياء الواضحة حتى يتمكن زملائك في الفريق من التركيز على القضايا الدقيقة التي تتطلب رؤية المطورين. يمكن لمراجعة رمز Copilot تمشيط فرقك المرحلي ، وتقترح docstrings ، وعلم الإخلاء الفارغ. من هناك ، يمكنك إصلاح كل ما يجده قبل تقديم العلاقات العامة الخاصة بك حتى لا يرى زملاء الفريق الضوضاء.

احصل على ملكية الكود الخاص بك

فقط لأنك استخدمت AI لإنشاء رمز لا يعني أنه ليس رمزك. بمجرد ارتكاب رمز ، فأنت مسؤول عنها. هذا يعني فهم ما يفعله ، وضمانه يتبع معايير فريقك ، والتأكد من أنه يتكامل بشكل جيد مع بقية قاعدة الشفرة الخاصة بك.

إذا كتب وكيل منظمة العفو الدولية رمزًا ، فمن المعتاد تنظيفه قبل أن يظهر اسمي في اللوم.

جون ويغينز ، مهندس التعلم الآلي في علم الاستجابة

قم بتشغيل الكود الخاص بك من خلال بوابات CI الآلية

يجب أن يكون خط الأنابيب الخاص بك بالفعل يعمل على تشغيل اختبارات الوحدة ، والمسح السري ، و CODEQL ، وفحوصات التبعية ، وبياضات النمط. استمر في القيام بذلك. فشل بسرعة ، تفشل بصوت عال.

نصائح عملية لنظافة الكود الشخصي:

• راجع الرمز الخاص بك في IDE الخاص بك.
• تأكد من الأسماء المتغيرة والتعليقات والهيكل لتتناسب مع اتفاقيات فريقك.
• اختبار رمز تم إنشاؤه جيدًا قبل تضمينه في طلبات السحب.

استخدم منظمة العفو الدولية للتركيز على المجالات التي يكون حكمك فيها أمرًا بالغ الأهمية

القوة الحقيقية لـ AI في مراجعات التعليمات البرمجية ليست في استبدال المطورين كمراجعين. إنه في التعامل مع العمل الروتيني الذي يمكن أن يقلل من عملية المراجعة ، مما يحرر المطورين للتركيز حيث يكون حكمهم هو الأكثر قيمة.

AI لا تحل محل الشيكات الآلية الحالية.

تأكد من تمرير الاختبارات ، يتم استيفاء مقاييس التغطية ، وقد قامت أدوات التحليل الثابت بعملها قبل بدء مراجعات المطور. هذا يخلق أساسًا متينًا لمناقشة أكثر جدوى.

يمكنك استخدام LLM للقبض ليس فقط على مشكلات بناء الجملة ، ولكن أيضًا الأنماط والبق المحتملة وتناقضات الأسلوب. ومن المفارقات ، أن LLMs جيدة بشكل خاص في اصطياد أنواع الأخطاء التي ترتكبها LLMs ، والتي تكون ذات صلة بشكل متزايد مع دخول المزيد من الكود الذي تم إنشاؤه من الذكاء الاصطناعى.

تحديد الأدوار بوضوح

حدد توقعات واضحة حول متى ينبغي النظر في ملاحظات الذكاء الاصطناعى مقابل عندما يأخذ الحكم البشري الأسبقية. على سبيل المثال ، يجب أن تعتمد على مطورين آخرين للهندسة المعمارية والاتساق مع أهداف العمل والقيم التنظيمية. من المفيد بشكل خاص استخدام الذكاء الاصطناعي لمراجعة PRS المتكررة الطويلة حيث يمكن أن يكون من السهل تفويت الأشياء الصغيرة.

نصائح التنفيذ لبناء عملية مراجعة مستدامة AI

• توثيق إرشادات واضحة يحدد ذلك وقت استخدام الذكاء الاصطناعى في مراجعات التعليمات البرمجية ، وأنواع التعليقات التي يجب الثقة ، وكيفية التصعيد عندما يختلف المطورون مع مراجعة رمز الذكاء الاصطناعي. مع Github Copilot ، على سبيل المثال ، يمكنك استخدام إرشادات مخصصة لتعيين قواعد واضحة لكيفية انخراط Copilot مع الكود الخاص بك.
• تحديث الإرشادات بانتظام بناءً على ملاحظات الفريق وقدرات الذكاء الاصطناعي المتطورة. تذكر أنه مع تطور أدوات CodeBase وأدوات الذكاء الاصطناعي ، فإن ما ينجح اليوم قد لا يعمل غدًا.
• تشجيع مناقشات الفريق المفتوح حول نقاط القوة والقيود في المراجعات بمساعدة AI. شارك كل من التجارب الإيجابية والسلبية لمساعدة الجميع على التعلم وتحسين نهجهم.
• صقل الأتمتة باستمرار باستخدام ملاحظات من المراجعين لتحسين استراتيجية الاختبار الآلي. تحديد الأنماط التي يمكن أن تكون فيها حلول للمشكلات المتكررة تلقائيًا.

حكم المطور لا يزال حاسما

على الرغم من أن الذكاء الاصطناعى يمكنه التعامل مع الكثير من العمل الروتيني في مراجعات الكود ، إلا أن حكم المطور لا يمكن تعويضه عن القرارات المعمارية ، والتوجيه ونقل المعرفة ، والقرارات المحددة للسياق التي تتطلب فهم منتجك والمستخدمين.

وحتى مع تزايد الأذكى ، تظل ثلاث مهام مراجعة إنسانية بعناد:

1. مقايضات العمارة: هل يجب أن نقسم هذه الخدمة؟ ذاكرة التخزين المؤقت محليا؟ دفع ديون التكنولوجيا الآن أو في وقت لاحق؟
2. الإرشاد والثقافة: خيوط العلاقات العامة هي فصول الفريق. لا يمكن لوب الروبوت أن يخبر مهندسًا مبتدئًا قصة الحرب وراء ذلك الغريب.
3. الأخلاق وقيم المنتج: “هل يجب أن نبني هذا؟” هو سؤال لا يمكن أن يجيب عليه الذكاء الاصطناعي.

الهدف من ذلك هو جعل المطورين أكثر فاعلية من خلال السماح لهم بالتركيز على ما يفعلونه بشكل أفضل.

---