لماذا يعمل البرنامج على جهازك ويفشل عند غيرك؟
عالم البرمجة
 |
| مطورة تقارن تشغيل البرنامج بين جهازين مختلفين |
تُنهي ميزة جديدة، وتشغل الاختبارات على جهازك، ثم ترسل المشروع إلى زميل.
يظهر خطأ لم تره من قبل: ملف غير موجود، مكتبة لا تُحمَّل، اتصال مرفوض،
أو وظيفة تتصرف بطريقة مختلفة.
تراجع الكود وتقول: لكنه كان يعمل على جهازي.
هذه الجملة لا تثبت أن الكود صحيح ولا أن الجهاز الآخر معيب.
هي تخبرك فقط أن التطبيق نجح داخل مجموعة محددة من الشروط: إصدار لغة، واعتمادات، وإعدادات، وصلاحيات، وملفات، وبيانات، ونظام تشغيل.
المشكلة ليست دائمًا في اختلاف الأجهزة بالمعنى الحرفي.
قد يكون الجهازان متماثلين، لكن أحدهما يحمل متغيرًا بيئيًا قديمًا أو ملف إعداد محليًا أو شهادة موثوقة أو قاعدة بيانات جرى تعديلها يدويًا.
لذلك لا تبدأ بتثبيت أدوات عشوائية على الجهاز المتعطل حتى يعمل.
ابدأ بتحويل الاختلاف الغامض إلى قائمة فروق قابلة للقياس، ثم اختبر كل فرق بدل إعادة تشكيل جهاز آخر.
البرنامج يعمل داخل بيئة لا داخل ملفاته فقط
الكود جزء من التطبيق، لكنه لا يعمل منفردًا.
المفسر أو وقت التشغيل يقرأه، ومدير الحزم يوفر مكتباته، ونظام التشغيل يمنحه ملفات وشبكة ووقتًا وصلاحيات، وقاعدة البيانات تعطيه بنية وبيانات، والخدمات الخارجية تستجيب وفق عقود وإعدادات قد تتغير.
على جهاز التطوير تتراكم هذه العناصر بمرور الوقت.
تثبت أداة لحل مشكلة، وتضيف متغيرًا بيئيًا، وتعدل ملفًا محليًا، وتمنح حسابك صلاحية واسعة،
ثم تنسى أن المشروع صار يعتمد على هذه الخطوات.
النجاح المحلي قد يكون نتيجة اعتماد ضمني لا يظهر في المستودع.
لهذا تكون إعادة التشغيل على جهاز نظيف اختبارًا مهمًا.
إذا احتاج المطور الجديد إلى تعليمات شفوية أو ملفات من مجلدك الشخصي أو أوامر غير موجودة
في دليل التشغيل، فالمشروع لم يصف بيئته بما يكفي لإعادة بنائها.
ومع ذلك، لا يعني اختلاف السلوك أن الحل هو نسخ الجهاز كله.
بعض التفاصيل يجب تثبيتها، وبعضها يجب أن يبقى مختلفًا بين التطوير والاختبار والإنتاج، مثل عناوين الخدمات والمفاتيح وحدود الموارد.
المطلوب بيئة قابلة للوصف، لا نسخة حرفية من حاسوب شخص واحد.
ابدأ بالسؤال: ما الذي يحتاجه التطبيق كي يبدأ، وما الذي يحتاجه كي يؤدي وظيفته؟ قد يفتح المنفذ
ثم يفشل عند أول اتصال بقاعدة البيانات، أو يمر فحص الصحة بينما لا يستطيع كتابة ملف
أو إرسال طلب خارجي.
الإصدارات والاعتمادات تغيّر معنى الكود
قد تعتمد الشيفرة على ميزة أضيفت في إصدار حديث من اللغة، أو على سلوك تغير بين نسختين من مكتبة.
قد يظهر الفرق أثناء التشغيل، أو يتغير السلوك عند معالجة حالة نادرة.
لا يكفي أن تكتب اسم الحزمة.
مدير الحزم قد يختار إصدارًا أحدث يطابق نطاقًا واسعًا، وقد تحمل الاعتمادات الفرعية تغييرات لم تذكرها مباشرة.
لهذا تؤدي ملفات القفل دورًا مهمًا: تسجل الحل المختبر بدل إعادة حل شجرة الاعتمادات في كل تثبيت.
لكن تثبيت الإصدارات ليس ضمانًا مطلقًا.
قد تختلف الحزم الثنائية حسب النظام والمعمارية، أو يتغير مصدر البناء، أو تعتمد المكتبة على مكتبة نظام غير موجودة.
كما أن نسخ مجلد البيئة الافتراضية بين الأجهزة ليس بديلًا آمنًا عن إعادة إنشائها من ملف موثوق.
سجل إصدار اللغة ووقت التشغيل ومدير الحزم وأداة البناء، وحدد طريقة إنشاء البيئة من الصفر.
عندما تحتاج إلى دعم عدة إصدارات، اختبرها صراحة.
ولا تحدث الاعتمادات داخل الإنتاج تلقائيًا لمجرد وجود إصدار أحدث.
اجعل التحديث تغييرًا مرئيًا يمر بالاختبارات والمراجعة.
إذا كان المشروع ينتج ملفًا تنفيذيًا أو حزمة نشر، فميّز بين كود المصدر وأثر البناء.
بناء الحزمة على جهاز ثم إعادة بنائها في مكان آخر قد يدخل فروقًا في الأدوات أو الخيارات؛ الأفضل
أن يكون مسار البناء نفسه موثقًا وآليًا قدر الإمكان.
نظام التشغيل والعتاد يكشفان افتراضات خفية
تختلف أنظمة الملفات في المسارات وحساسية حالة الأحرف والروابط والقيود على أسماء الملفات.
قد يستورد المشروع ملفًا باسم يختلف في حرف كبير عن الاسم الحقيقي، فيعمل على نظام غير حساس للحالة ويفشل على نظام يميزها.
وتختلف نهايات الأسطر، والترميزات الافتراضية، والإعدادات المحلية، والمنطقة الزمنية،
وطريقة تمثيل بعض الأحرف.
التطبيق الذي يعتمد على الإعداد الافتراضي بدل تحديد UTF-8 أو منطقة زمنية واضحة قد ينجح مع بياناتك ويشوّه نصوصًا أو تواريخ عند مستخدم آخر.
الصلاحيات أيضًا جزء من السلوك.
قد تعمل محليًا بحساب يستطيع إنشاء المجلدات والاستماع إلى المنافذ وقراءة الشهادات، بينما تعمل الخدمة في الإنتاج تحت مستخدم محدود.
تشغيلها بصلاحيات أعلى قد يخفي المشكلة ويزيد المخاطر بدل إصلاحها.
أما المعمارية، فقد تظهر في الحزم الثنائية والتعليمات الخاصة بالمعالج وحجم الكلمات وترتيب البايتات.
الحاوية المبنية لمعمارية معينة لا تصبح صالحة لكل معالج تلقائيًا، وقد تحتاج إلى بناء متعدد المنصات
أو محاكاة مع فهم أثر الأداء.
اقرأ ايضا : متى تصبح المكتبة الجاهزة عبئًا على مشروعك؟
وتكشف الموارد اختلافات أخرى.
تطبيق يعمل مع ذاكرة واسعة قد يُقتل عند حد أصغر، وخوارزمية تعتمد ضمنيًا على سرعة القرص قد تتجاوز مهلة في بيئة أبطأ.
لذلك سجل حدود الذاكرة والمعالج والتخزين، واختبر تحت قيود تشبه بيئة النشر.
الإعدادات والأسرار ليست جزءًا من الكود
عناوين قواعد البيانات، ومفاتيح الخدمات، ومستويات السجل، وأسماء الحاويات، وخيارات الميزات تختلف
بين البيئات.
وضعها داخل الكود يجعل التغيير صعبًا وقد يكشف أسرارًا، بينما الاعتماد على قيم موجودة يدويًا يجعل البيئة غير قابلة لإعادة الإنشاء.
افصل الإعداد عن المنطق، وحدد المتغيرات المطلوبة وأنواعها وقيمها الافتراضية الآمنة.
اجعل التطبيق يفشل مبكرًا برسالة مفهومة عندما تغيب قيمة إلزامية، بدل أن يستمر
حتى يظهر خطأ بعيد عن السبب الحقيقي.
لا تضع المفاتيح السرية في ملف مثال أو سجل خطأ.
استخدم وسيلة مناسبة لإدارة الأسرار، وامنح كل بيئة بيانات اعتماد مستقلة وصلاحيات بالحد الأدنى.
مشاركة سر التطوير مع الإنتاج تلغي العزل حتى لو كانت بقية الملفات متطابقة.
وقد تكون المشكلة خارج الجهازين: DNS مختلف، أو وكيل شبكة، أو جدار ناري، أو شهادة غير موثوقة،
أو خدمة تسمح بعناوين محددة.
اختبر الوصول من البيئة المتعطلة نفسها، ولا تستنتج من نجاح المتصفح على جهازك أن العملية داخل الخادم تملك المسار ذاته.
حدد أيضًا المهلات وإعادة المحاولة بحذر.
زيادة المهلة قد تخفي بطئًا حقيقيًا، وإعادة المحاولة غير المنضبطة قد تكرر عملية مالية أو تنشئ سجلًا مرتين.
الاختلاف البيئي لا يبرر تغييرًا عشوائيًا في السلوك.
البيانات وقاعدة البيانات قد تكونان الفرق الحقيقي
قد تعمل الميزة على قاعدة تطوير قديمة لأنك أضفت عمودًا يدويًا أو تملك بيانات تملأ كل الحقول.
على جهاز جديد تبدأ قاعدة فارغة، أو تُطبق الهجرات بترتيب مختلف، أو تظهر قيمة فارغة لم تواجهها
في بياناتك.
اجعل تغييرات البنية ملفات هجرة محفوظة مع المشروع، وطبّقها بالطريقة نفسها في كل بيئة.
لا تعدل الإنتاج يدويًا ثم تتوقع أن يعرف المستودع ما حدث.
واختبر الترقية من نسخة سابقة، لا إنشاء قاعدة جديدة فقط.
وفّر بيانات اختبار صغيرة ومصطنعة تغطي الحالات المهمة من دون نسخ معلومات العملاء.
البيانات الحقيقية قد تكشف خصوصية، كما أنها تجعل إعادة الخطأ صعبة إذا لم تعرف الحالة التي فعّلته.
قد تختلف كذلك إعدادات محرك البيانات: ترتيب الفرز، والمنطقة الزمنية، وحساسية الأحرف، ومستوى العزل، وامتدادات مفعلة محليًا.
اكتب الاختبارات ضد المحرك الذي ستستخدمه فعليًا عندما تؤثر هذه التفاصيل، ولا تعتبر قاعدة خفيفة بديلًا مطابقًا لمحرك الإنتاج.
الخدمات الخارجية تحمل النسخ والعقود نفسها.
استجابة تجريبية ثابتة قد لا تمثل حدود المعدل أو التأخر أو الحقول الاختيارية.
اختبر الفشل الجزئي، ووثّق إصدار الواجهة، ولا تجعل نجاح الحالة المثالية دليلًا على توافق كامل.
التوقيت والتزامن يصنعان أخطاء لا تظهر دائمًا
بعض البرامج تعمل على الجهاز الأبطأ وتفشل على الأسرع، أو العكس، لأن عيبًا في ترتيب العمليات يظهر فقط تحت توقيت معين.
عمليتان تقرآن وتكتبان المورد نفسه بلا تنسيق قد تنجحان عشر مرات ثم تتعارضان في المرة التالية.
هذه الأخطاء لا تعني أن المعالج السريع سيئ، بل إن الكود افترض ترتيبًا لم يضمنه النظام.
إضافة تأخير يدوي قد تجعل الاختبار يمر مؤقتًا، لكنها لا تصلح السباق؛ الحل في تحديد الملكية والتزامن والمعاملات والعمليات الآمنة للتكرار.
وقد تخفي بيئة التطوير المشكلة بسبب مستخدم واحد وبيانات قليلة.
عند التشغيل المتوازي تظهر حدود الاتصالات، وتعارضات الكتابة، وتسرب الموارد، والاعتماد على حالة مشتركة داخل الذاكرة.
اختبر الحمل والتوازي والبدء المتكرر، ولا تكتفِ بالتشغيل اليدوي مرة واحدة.
اجعل الاختبارات مستقرة ولا تربطها بوقت فعلي أو ترتيب غير مضمون إلا عندما يكون ذلك هو موضوع الاختبار.
راقب أيضًا الساعة والمنطقة الزمنية.
اختلاف الوقت أو انحرافه قد يكسر صلاحية رمز أو ترتيب حدث أو مهمة مجدولة.
خزّن الزمن بصيغة واضحة، وحوّل للعرض عند الحدود المناسبة، ولا تعتمد على المنطقة المحلية الضمنية.
الحاويات تقلل الفروق لكنها لا تلغيها
الحاوية تجمع التطبيق وملفاته واعتماداته ضمن صورة يمكن تشغيلها، وهي مفيدة عندما يكون بناء الصورة نفسه محددًا ومراجعًا.
لكنها ليست جهازًا افتراضيًا كاملًا؛ تشارك نواة المضيف، وتتأثر بالمعمارية والشبكة والتخزين والقيود والسياسات.
لهذا قد تعمل الصورة محليًا وتفشل في الإنتاج بسبب مجلد مثبت من المضيف، أو متغير مفقود،
أو منفذ غير منشور، أو مستخدم مختلف، أو حد ذاكرة، أو اختلاف معمارية.
عبارة «وضعناه في حاوية» لا تغلق التحقيق.
اجعل ملف البناء جزءًا من المستودع، وثبت صورة الأساس، وابنِ الصورة في مسار آلي، وافحصها وشغّل اختبارًا قصيرًا عليها قبل النشر.
لا تنسخ ملفات سرية أو مخلفات التطوير داخل سياق البناء.
وقد تكون البيئة الافتراضية المحلية كافية لمشروع مكتبي أو مكتبة، بينما تحتاج خدمة متعددة المكونات إلى وصف الشبكة وقاعدة البيانات والتخزين.
اختر مستوى العزل الذي يعالج الفروق الفعلية، لا الأداة الأكثر شهرة.
الأهم أن تختبر في بيئة قريبة من هدفك.
الحاوية التي لم تُشغّل إلا على حاسوب المطور لم تثبت توافقها مع منصة النشر أو بنيتها أو سياساتها.
استخدم بطاقة فرق البيئة قبل تعديل الكود
استخدم أداة واحدة تسمى بطاقة فرق البيئة.
افتحها عند أول فشل على جهاز آخر، وسجل خمسة محاور بدل جمع لقطات شاشة ورسائل متفرقة.
المحور الأول: البناء والاعتمادات.
سجل نسخة الكود، وأثر البناء، وإصدار اللغة ومدير الحزم وملف القفل وصورة الأساس والمعمارية.
المحور الثاني: التشغيل.
سجل نظام التشغيل والمستخدم والصلاحيات والموارد والمسارات والمنطقة الزمنية والإعدادات المحلية.
المحور الثالث: الإعداد والاتصال.
تحقق من أسماء المتغيرات من دون كشف قيم الأسرار، ومن DNS والمنافذ والشهادات وعناوين الخدمات والمهلات.
المحور الرابع: البيانات والحالة.
سجل إصدار مخطط قاعدة البيانات، وآخر هجرة مطبقة، ونوع البيانات التي فعّلت الخطأ، وحالة التخزين
أو الطوابير أو الذاكرة المؤقتة.
المحور الخامس: الدليل.
اجمع رسالة الخطأ الكاملة، ورمز الخروج، والسجل المرتبط بمعرّف طلب، وخطوات إعادة المشكلة.
تجنب تسجيل كلمات المرور والرموز والبيانات الشخصية.
قارن البطاقة بين البيئة التي تعمل والبيئة التي تفشل.
غيّر فرقًا واحدًا عندما تستطيع، وأعد الاختبار.
بهذه الطريقة يتحول «لا يعمل عندهم» إلى فرضية يمكن إثباتها أو استبعادها.
بعد اكتشاف السبب، لا تكتفِ بإصلاح الجهاز المتعطل.
انقل المعرفة إلى المشروع: ملف قفل، أو فحص إعداد، أو هجرة، أو اختبار متعدد الأنظمة، أو توثيق،
أو تنبيه أوضح.
ابنِ مسارًا يكشف الفروق قبل المستخدم
ابدأ من مستودع نظيف داخل بيئة جديدة، ونفذ خطوات البناء والتشغيل كما يفعل عضو جديد.
هذا الاختبار يكشف الملفات غير المتتبعة والاعتمادات المثبتة عالميًا والتعليمات التي تعيش في ذاكرة المطور.
ثم شغّل التكامل المستمر على الإصدارات والأنظمة التي تعلن دعمها.
لا تحتاج إلى اختبار كل تركيبة ممكنة؛ اختر مصفوفة تعكس مستخدميك ومنصة النشر، وأزل دعمًا
لا تستطيع اختباره أو توثيقه بصدق.
أضف فحوص بدء واضحة: صحة الإعداد، والاتصال بالخدمات، وتطبيق الهجرات، والقدرة على القراءة والكتابة في المسارات المطلوبة.
افصل بين الجاهزية لاستقبال الحركة وبين كون العملية ما زالت حية.
اجعل السجلات تصف السياق المفيد من دون تسريب الأسرار.
سجل إصدار التطبيق والبيئة ونوع الخطأ ومعرّف التتبع، لكن لا تسجل محتوى الرموز أو بيانات العملاء
أو نسخًا كاملة من الطلبات الحساسة.
اقرأ ايضا : لماذا يصبح تعديل المشروع البرمجي الصغير أصعب مع كل ميزة؟
خطوتك العملية اليوم هي تشغيل المشروع من نسخة جديدة على بيئة لا تحمل تاريخ جهازك، ثم تعبئة بطاقة فرق البيئة عند أول فشل.
لا تثبت أداة يدويًا قبل أن تسجل سبب الحاجة إليها وتضيفها إلى مسار البناء أو دليل التشغيل.
الهدف ليس أن يتطابق كل جهاز، بل أن تكون الفروق المقصودة معلنة، والاعتمادات قابلة لإعادة البناء، والبيئات المدعومة مختبرة.
عندها لا تختفي الأعطال كلها، لكنها تتحول من مفاجآت مرتبطة بحاسوب واحد إلى أخطاء يمكن إعادة إنتاجها وتشخيصها ومنع عودتها.