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