يعمل على جهازي: ما هو، لماذا يحدث وكيفية منعه

ما معنى «يعمل على جهازي»

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

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

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

لماذا تختلف البيئة المحلية عن بيئة الإنتاج

تختلف البيئة المحلية للمطور تقريبًا دائمًا عن بيئة الإنتاج. يستخدم المطور macOS أو Windows، بينما يعمل الخادم على Linux. أنظمة التشغيل المختلفة لديها أنظمة ملفات مختلفة، ترميزات، توقيت الخيوط واستدعاءات النظام. حتى لو كانت كلتا البيئتين Linux، فإن إصدار النواة، glibc و OpenSSL قد تختلف.

السبب الثاني هو مجموعة البرمجيات المثبتة. قد يكون لدى جهاز المطور تثبيت عالمي لـ Node.js 20، بينما تحدد تكوينات CI/CD الإصدار 18. أو يستخدم المطور PostgreSQL 16 محليًا، بينما يعمل الإنتاج على PostgreSQL 14. الاختلافات في الإصدارات الثانوية غالبًا لا تكون ملحوظة، ولكن التحديثات الرئيسية يمكن أن تغير سلوك استعلامات SQL. وفقًا لـ npm Inc.، 67% من الأخطاء المتعلقة بالتبعيات ناجمة عن اختلافات في إصدارات التصحيح (patch).

السبب الثالث هو ظروف الشبكة. ليس لدى الجهاز المحلي زمن استجابة، ولا حدود عرض حزمة، ولا مشاكل DNS. في الإنتاج، أي طلب إلى API خارجي يمكن أن يستغرق 500 مص بدلاً من 5 مص. انقضاء المهلة، منطق إعادة المحاولة، سباق الشروط — تظهر هذه المشاكل فقط تحت الحمل الحقيقي وظروف الشبكة الحقيقية. محاكاة الشبكة عبر أدوات مثل Toxiproxy تساعد في تحديد هذه المشاكل قبل النشر.

الأسباب النموذجية لعدم قابلية إعادة إنتاج الخطأ محليًا

السبب الأول هو عدم وجود البيانات. يعمل المطور مع بيانات اختبارية، بينما يوجد في الإنتاج ملايين السجلات بقيم غير متوقعة. NULL في حقل اعتبره المطور إجباريًا، أحرف Unicode في اسم، سلاسل طويلة جدًا — كل هذا يمكن أن يسبب أخطاء غير قابلة للإعادة على قاعدة بيانات محلية ببيانات اصطناعية.

السبب الثاني هو اختلاف علامات التجميع والبناء. قد تختلف بناء الإصدار (Release/Distribution) عن بناء التصحيح (Debug). تحسينات المجمع، إزالة سجلات التصحيح، تضمين الدوال — كل هذا يمكن أن يخفي أو يظهر الأخطاء. مثال نموذجي: يعمل assert في بناء التصحيح ولكنه يفشل في بناء الإصدار بسبب ترتيب مختلف لتهيئة المتغيرات.

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

السبب الرابع هو التعارضات بين التبعيات العالمية والمحلية. الأدوات مثل Ruby gems، Python pip و Node.js npm يمكن أن تكون لديها حزم مثبتة عالميًا تساعد الكود على العمل محليًا ولكنها غائبة في الإنتاج. استخدام البيئات الافتراضية (virtualenv، venv، nvm) يعزل المشروع عن التثبيتات العالمية ويجعل البيئة قابلة للتكرار.

التأثير على العمل الجماعي والثقة

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

المشكلة الثانية هي إبطاء مراجعة الكود. إذا لم يتمكن المطور من إعادة إنتاج خطأ محليًا، فقد يرفض طلب سحب (pull request) لزميله بالقول «إنه يعمل لديَّ — لذا المشكلة في جهازك». يثير هذا الصراعات ويؤخر تسليم الميزات. توحيد البيئة يزيل هذا الصراع: إذا عمل كلا المطورين في نفس حاوية Docker، فإن سؤال «من لديه المشكلة» يفقد معناه.

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

كيفية توحيد بيئة المطور

الطريقة الأولى والأكثر فعالية هي Docker. يجب أن يكون المشروع بأكمله قابلًا للتشغيل بأمر docker-compose up دون خطوات إضافية. قاعدة البيانات، الذاكرة المؤقتة، طابور الرسائل، خادم الويب — كل شيء ينطلق داخل حاويات. يحتاج المطور فقط إلى تثبيت Docker و Git. كل شيء آخر يعمل داخل الحاويات. يضمن هذا أن جميع أعضاء الفريق لديهم نفس البيئة بغض النظر عن نظام التشغيل الخاص بهم.

الطريقة الثانية هي مديرو الإصدارات. إذا كان Docker غير ممكن (قيود الترخيص، بنية تحتية قديمة)، استخدم nvm (Node.js)، rbenv (Ruby)، pyenv (Python)، sdkman (Java). تسمح مديرو الإصدارات بتبديل إصدارات اللغات والأدوات حسب المشروع. يجب أن تكون ملفات .nvmrc، .ruby-version، .python-version في المستودع ويتم التحقق منها عبر CI/CD.

الطريقة الثالثة هي Vagrant للآلات الافتراضية. يقوم Vagrant بتشغيل آلة افتراضية بنظام تشغيل وتكوين محددين فوق VirtualBox أو VMware. تتم إعادة تثبيت جميع التبعيات داخل الآلة الافتراضية عبر نصوص التجهيز (shell، Ansible، Puppet). Vagrant أثقل من Docker ولكنه يوفر عزلاً كاملًا على مستوى نظام التشغيل — مفيد للمشاريع التي تعتمد على إصدار محدد لنواة Linux.

الطريقة الرابعة هي Makefile ونصوص التمهيد (bootstrap). حتى Makefile بسيط مع أهداف install، test، build، clean يمكنه توحيد المهام الروتينية. يجب أن يقوم أمر make install بتثبيت جميع التبعيات، إعداد قاعدة البيانات وإنشاء بيانات اختبارية. نقطة دخول واحدة لجميع المطورين تلغي الأخطاء اليدوية أثناء إعداد البيئة.

أدوات لمنع اختلاف البيئات

الأداة الرئيسية هي ملفات القفل للتبعيات. package-lock.json (npm)، yarn.lock (Yarn)، Podfile.lock (CocoaPods)، pubspec.lock (Flutter) تثبت الإصدارات الدقيقة لكل حزمة. بدون ملف قفل، قد يحصل مطوران يقومان بتثبيت التبعيات في أوقات مختلفة على إصدارات ثانوية مختلفة. يجب أن يكون ملف القفل في المستودع ولا يتم تحريره يدويًا.

الأداة الثانية هي .env.example في المستودع. ملف قالب لمتغيرات البيئة مع تعليقات. ينسخه المطور إلى .env ويملأ قيمه. يتحقق خط أنابيب CI/CD من أن جميع المتغيرات الإجبارية محددة. وفقًا لـ GitLab 2023، الفرق التي تستخدم .env.example تقلل حادثات متغيرات البيئة بنسبة 40%.

الأداة الثالثة هي خطافات pre-commit. فحوصات آلية تتم تشغيلها قبل كل التزام: مدقق الكود، منسق، فحص الأنواع، اختبارات. إذا تم تكوين الخطافات بنفس الطريقة لجميع المطورين، فإن أخطاء التنسيق أو الأنواع التي «نجحت محليًا» لن تصل إلى الإنتاج. Husky لـ JavaScript و pre-commit لـ Python هي حلول شائعة.

الأداة الرابعة هي خط أنابيب CI/CD يقوم بتشغيل الاختبارات في بيئة نظيفة. إذا نجحت الاختبارات في CI ولكن فشلت محليًا، فالمشكلة في إعدادات البيئة المحلية. إذا فشلت الاختبارات في CI، فإن طلب السحب لا يتم دمجه. هذه القاعدة الصارمة تمنع وصول الأخطاء التي «تعمل محليًا» إلى الفرع الرئيسي.