في أغسطس فتحت Tessel طلب الدمج (pull request) رقم عشرة آلاف لإصلاح عطل. فقرأنا عينة من ألف طلب منها، إلى جانب ما فعله عملاؤنا بكل واحد منها، وفاجأتنا بضعة أمور.
معظم الأعطال مملة
أصلح نحو ثلثي طلبات الدمج واحداً من خمسة أشياء: عموداً أُعيدت تسميته، أو نوعاً تغيّر، أو قيمة جديدة في اختبار القيم المقبولة (accepted values)، أو مرجعاً (ref) انكسر بعد إعادة هيكلة، أو مرشّحاً تزايدياً فاتته صفوف وصلت متأخرة. لا شيء من هذا صعب. إنها مجرد مقاطعات، ويبدو أنها تحدث دائماً في الساعة 2 فجراً.
الاختبار هو المنتج
في البداية، لم تحتوِ طلبات الدمج لدينا إلا على الإصلاح. كانت نسب الدمج جيدة، لكن المراجعين أخبرونا أنهم لا يثقون بها. وعندما بدأنا نضيف اختباراً يفشل قبل التغيير وينجح بعده، ارتفعت نسبة الطلبات المدموجة دون تعديل من 61% إلى 79%.
المراجع لا يريد أن يصدّق الإصلاح، بل يريد أن يرى الدليل عليه.
متى نتوقف
تعلّمنا أكثر ما تعلّمناه من طلبات الدمج التي أُغلقت. فكلها تقريباً كانت حالات يتوقف فيها الإصلاح الصحيح على قرار تجاري: هل تُحتسب فئة منتجات جديدة ضمن الإيرادات؟ وهل ينبغي لمصدر متأخر أن يوقف التشغيل أم أن نتخطاه؟ أصبحنا الآن نكتشف هذه الحالات ونشرح السبب بدلاً من التخمين.
- أصلحه عندما تكون النية واضحة من الشيفرة والسجل.
- اشرحه عندما يحتاج الإصلاح إلى قرار ينبغي أن يتخذه إنسان.
- لا تلمس مستودع البيانات أبداً؛ كل شيء يمر عبر المراجعة.
ما التالي
نعمل على إضافة أنماط إصلاح لفحوص الأصول (asset checks) في Dagster ولأخطاء الصلاحيات في Snowflake، وكلاهما من أكثر الأنماط طلباً. إن كان هناك عطل يصلحه فريقك يدوياً كل شهر، فأخبرنا به؛ فقد يكون نمطنا التالي.
