كيفية تصحيح أخطاء الشيفرة البرمجية في 7 خطوات قابلة للتكرار
تعرّف على كيفية تصحيح أخطاء الشيفرة البرمجية عبر 7 خطوات عملية، بما يشمل السجلات ونقاط التوقف واختبارات الانحدار، مع مثال عملي من Enter Pro لخطأ خصم مزدوج في سلة التسوق.
يمكن لسلة تسوق أن تُجمَّع بنجاح، وما تزال تمنح خصمًا زائدًا بقيمة 5 دولارات. في هذا التمرين المُتحكَّم به، تم إدخال الخلل عمدًا: يُطبَّق كود الخصم مرة واحدة، ثم يؤدي تغيير الكمية إلى خصمه مجددًا. السؤال المفيد هنا هو كيف تُثبت أين يحدث هذا الخصم الزائد بالضبط.
الحساب الرقمي يجعل عملية التحقيق واضحة وملموسة. سلة بقيمة 54 دولارًا تصبح** 49 دولارًا** بعد تطبيق كود خصم واحد. إذا أضفت عنصرًا آخر بقيمة** 24 دولارًا**، يصبح الإجمالي الصحيح بعد الخصم** 73 دولارًا**. أما الحساب المعيب فيُنتج** 68 دولارًا**. يمكنك استخدام هذا التناقض لتتبع تغيّر الحالة بدلًا من تخمين السطر الذي يبدو مشبوهًا.
عند شرح كيفية تصحيح أخطاء الشيفرة البرمجية، أبدأ بقاعدة واحدة: احتفظ بحالة الفشل قبل تعديل البرنامج. حدّد النتيجة المتوقعة، وضيّق نطاق البحث، واختبر سببًا واحدًا. يصبح الإصلاح مقنعًا عندما يفسّر التناقض وينجح في المرور بنفس التسلسل الذي كشف المشكلة.
فهم الخلل قبل تصحيحه
فصل العرَض عن السبب الجذري
العرَض هو ما يمكنك ملاحظته: إجمالي خاطئ، تعطّل، صفحة فارغة، أو طلب لا ينتهي أبدًا. أما السبب الجذري فهو الافتراض المخالَف الذي يُنتج هذا العرَض. في مثال سلة التسوق، يزداد الخصم عند تغيّر الكمية، مع أن قيمة كود الخصم الثابتة يجب أن تبقى 5 دولارات.
لن أبدأ بتغيير دالة تنسيق العملة؛ فهي تعرض فقط النتيجة التي تستلمها. تتبّع القيمة إلى الخلف عبر مكوّن الملخص، وحساب الإجمالي، وإجراء تغيير الكمية، وحالة كود الخصم، إلى أن تجد أول نقطة تباعد عن الحساب المتوقع.
هذه عادة مفيدة عند تصحيح شيفرة لم تكتبها أنت. تتبّع المكدّس (stack trace) أو اسم مكوّن يبدو مشبوهًا يمنحك نقطة انطلاق، لا حكمًا نهائيًا. قد يكون المصدر الحقيقي أسبق في تدفّق البيانات، أو خارج العملية التي تعرض الفشل أصلًا.
تصنيف نوع الفشل
يمنع الخطأ النحوي تشغيل الشيفرة عندما تخالف بنيتها قواعد لغة البرمجة.
الخطأ النحوي يمنع التحليل اللغوي للشيفرة؛ الاستثناء في وقت التشغيل يقطع التنفيذ؛ الخطأ المنطقي يُنتج نتيجة غير صحيحة. أخطاء التكامل تظهر عند الحدود بين الأنظمة. أعطال البيئة تعتمد على الإعدادات أو الصلاحيات أو التبعيات؛ وأخطاء التزامن تعتمد على التوقيت والحالة المشتركة.
خلل كود الخصم لدينا هو أساسًا مشكلة حالة ومنطق. قد تقبل أدوات البناء كل الملفات بينما يبقى الحساب التجاري خاطئًا. يجب أن تختار الدليل الذي يطابق نوع الفشل، بدلًا من توقّع أن أمرًا واحدًا ناجحًا يُثبت الصحة.
الاحتفاظ بالأدلة وتقييم الأثر
سجّل النتيجة المتوقعة، والنتيجة الفعلية، والمدخلات الدقيقة، وتسلسل الإجراءات، والإصدار المعيب. أضِف تفاصيل البيئة، والطوابع الزمنية، ومعرّفات الطلبات، والسجلات، والتغييرات الأخيرة عندما تكون ذات صلة. هدفك أن يتمكّن شخص آخر من الوصول إلى نفس الفشل دون أن يعيد بناء جلستك من الذاكرة.
أفرّق بين التحقيق والاحتواء. إذا كان خلل في بيئة الإنتاج يتسبّب في خصم مبلغ خاطئ، فأوقف أو قيّد المسار المتأثر أولًا عبر إجراء تخفيف معتمد. تمرين سلة تسوق قابل للاستغناء عنه يسمح بالتجربة الحرة؛ أما حادثة دفع فعلية فتتطلّب تغييرات مضبوطة ومسؤولًا واضحًا.
كيفية تصحيح أخطاء الشيفرة البرمجية في 7 خطوات قابلة للتكرار
تشكّل هذه الخطوات تسلسلًا، لكن يمكنك التنقل ذهابًا وعودة بين الفحص واختبار الفرضيات. يجب أن يقلّل كل دوران من عدم اليقين. إذا وجدت نفسك تعدّل ملفات غير مرتبطة مرارًا، توقّف واسأل: أي ملاحظة ستفصل بأقوى شكل بين التفسيرات المتبقية؟
التحقيق القابل للتكرار يحافظ على إعادة التكرار بينما يقلّص عدد الأسباب المحتملة.
الخطوة 1 — حدّد الفشل وأعِد تكراره
استبدل عبارة "كود الخصم معطّل" بتسلسل محدّد: حمّل السلة، طبّق كود الخصم بقيمة 5 دولارات، ازِد كمية العنصر بقيمة 24 دولارًا من واحد إلى اثنين، ثم قارِن الإجمالي بـ 78 − 5 = 73 دولارًا. اذكر الكميات الابتدائية لتكون النتيجة المتوقعة واضحة دون غموض.
| الإجراء | الإجمالي الفرعي | الإجمالي المتوقع | دليل من النسخة المعيبة |
|---|---|---|---|
| سلة ابتدائية، بلا كود خصم | 54$ | 54$ | 54$ في الخطة/التقرير |
| تطبيق كود الخصم بقيمة 5$ | 54$ | 49$ | 49$ في المعاينة |
| زيادة كمية الغلّاية إلى 2 | 78$ | 73$ | 68$ في المعاينة؛ خصم 10$ |
القيمتان 49$ و68$ تظهران بوضوح في لقطات متتابعة من المعاينة المعيبة. القيمة الابتدائية 54$ محدّدة في الخطة وتقرير البناء؛ ومعاينة لاحقة مُصلَحة ومُعاد ضبطها تُظهر أيضًا 54$. تحتفظ لقطات الشاشة بهذه الحالات، بينما يمكن لتسجيل فيديو أو اختبار تفاعل أن يُثبت تسلسل النقرات الكامل.
بالنسبة لفشل متقطّع، سجّل التكرار والشروط بدلًا من افتراض تسلسل حتمي. "ثلاثة أعطال من عشرين محاولة بعد إعادة الاتصال" دليل مفيد إذا كانت تلك المحاولات مسجَّلة. أما "يتعطّل أحيانًا" فلا يمنحك شيئًا يُذكر للمقارنة.
القيم المتوقعة تتبع أسعار العرض التجريبي. النتيجة المعيبة تطرح نفس كود الخصم بقيمة 5$ مرة ثانية.
الخطوة 2 — اختزله إلى أصغر حالة فشل ممكنة
أزِل كل ما لا يؤثر على التناقض. حسابنا يحتاج فقط إلى أسعار العناصر وكمياتها، وحالة كود الخصم، وحساب الإجمالي. صور المنتجات، والبحث، والشحن، وتكامل الدفع لا تفسّر خصمًا ثابتًا زائدًا في هذا التمرين المتحكَّم به.
أحافظ على التحوّل المهم كما هو بينما أقلّص الشيفرة المحيطة به. قد يحذف المثال المصغّر الذي يُزيل إجراء تغيير الكمية الخلل نفسه أيضًا. تحتاج إلى إعادة تكرار أصغر لنفس الفشل، لا برنامج مختلف يصادف أنه يعمل.
وثّق ما حذفته وأكّد أن العرَض ما يزال يحدث. هذا التأكيد يحميك من استخلاص نتائج حول اختبار لم يعد يُشغّل المسار الأصلي. بالنسبة لخلل يعتمد على البيانات، قلّص مجموعة المدخلات دون تغيير القيمة التي تُطلقه.
الخطوة 3 — فحص الأخطاء والسجلات وإطارات المكدّس والحالة
اقرأ أول فشل ذي صلة قبل التتابع اللاحق من الأخطاء. فحص القيم الفعلية عند الحدود: كميات العناصر، والإجمالي الفرعي، وقيمة كود الخصم، والإجمالي المعروض قبل التغيير وبعده. السؤال المهم هو: هل تم تطبيق الخصم مرتين، لا هل تعرض الواجهة تسمية معيّنة.
تكشف أدوات تصحيح الأخطاء في VS Code المتغيرات، وتعبيرات المراقبة، وإطارات المكدّس، وعناصر التحكّم بالتنفيذ. استخدم نقطة توقّف عند موضع تعيين الإجمالي، ثم فحص المستدعين والقيم الحالية. أراقب أنا نفس القيمة عبر عمليات كتابة متتابعة بدلًا من التوقّف عند أول قيمة تبدو معقولة.
واجهة مصحّح أخطاء حقيقية مأخوذة من وثائق VS Code. تعرض اللوحة عدة أنواع من الأدلة معًا.
قد لا يُنتج الخلل المنطقي أي استثناء على الإطلاق. يمكنك مؤقتًا تسجيل المدخلات والنتيجة المحسوبة، أو إيقاف التنفيذ قبل التعيين الخاطئ مباشرة. حافظ على نطاق الملاحظات ضيّقًا بما يكفي للتفسير؛ فسجل كونسول مليء بكائنات كاملة يدفن غالبًا التحوّل الذي تحتاج إليه.
الخطوة 4 — ضيّق نطاق البحث
قسّم المسار المشتبه به إلى حدود مفيدة. هل حالة العنصر خاطئة، أم الإجمالي الفرعي خاطئ، أم أن الإجمالي المعروض يصبح خاطئًا بعد ذلك؟ إذا كان الإجمالي الفرعي 78 دولارًا لكن المعروض** 68 دولارًا**، يمكنك التوقّف عن التحقيق في عملية الضرب والتركيز على تطبيق الخصم.
بالنسبة لمشكلة انحدار (regression)، تبحث أداة git bisect بين إصدار جيد معروف وإصدار سيّئ معروف. في بحث ثنائي مثالي، تتقلّص 1024 نسخة محتملة إلى واحدة في 10 جولات تنصيف. التحقيقات الحقيقية تحتاج أيضًا إلى نقاط نهاية موثوقة، وعمليات بناء قابلة لإعادة التكرار، وفحص موثوق لتحديد "جيد أم سيّئ".
يجد Bisect التغيير المرتبط بالانحدار؛ لكنه لا يفسّر السبب الجذري بنفسه.
يوضّح الرسم بحثًا مثاليًا. أما عمليات البناء المكسورة، أو الإصدارات المتجاوزة، أو تعدّد الأعطال غير المرتبطة، فيمكن أن تعقّد التشغيل الفعلي.
كنت سأُشغّل bisect في مساحة عمل نظيفة أو فرع قابل للاستغناء عنه، مع الحفاظ أولًا على أي عمل غير مُلتزَم به. علّم الإصدار بأنه سيّئ فقط عندما تفشل إعادة التكرار نفسها. مشكلة تثبيت تبعية غير مرتبطة ليست دليلًا على أن حساب كود الخصم معيب.
الخطوة 5 — اختبر فرضية واحدة في كل مرة
اجعل الفرضية قابلة للتفنيد: "إجراء تغيير الكمية يضيف 5 دولارات أخرى إلى خصم كود الخصم المخزَّن." إذا كان هذا صحيحًا، يجب أن يرتفع الخصم من 5 إلى 10 دولارات بعد أول تغيير للكمية بينما يظل كود الخصم فعّالًا. إزالة هذا التراكم يجب أن تُعيد بالضبط خصمًا ثابتًا واحدًا.
لا تجمع بين تعديل الحساب وإعادة كتابة مكوّن، وتحديث تبعية، وقاعدة كود خصم جديدة. أريد أن تُميّز نتيجة تجربة واحدة تفسيرًا واحدًا. نتيجة ناجحة بعد أربعة تعديلات غير مرتبطة تترك السبب غير مؤكّد.
إذا فشلت الفرضية، سجّل السبب واختر التالية بناءً على الأدلة. تكرار نفس التفسير غير المؤكَّد بصياغات مختلفة قليلًا لا يُعدّ تجربة جديدة. يجب أن تكون قادرًا على قول ما تغيّر في فهمك بعد كل محاولة.
الخطوة 6 — أصلح السبب الجذري
يشير نموذج الحالة إلى إصلاح محدَّد الهدف: استنتج الخصم الثابت من حالة كود الخصم بدلًا من تراكمه عند تغييرات الكمية. هذا يتبع توجيهات React حول تجنّب الحالة الزائدة. إذا كان يمكن حساب قيمة من المدخلات الحالية، فإن نسخة منفصلة مخزَّنة يمكن أن تنحرف عن التطابق معها.
يستخدم مثال الوثائق أسماءً شخصية؛ ينطبق المبدأ نفسه على إجمالي سلة مُستنتَج من العناصر وحالة كود الخصم.
نموذج إصلاح مبسّط يستنتج الخصم من حالة كود الخصم الحالية:
const subtotal = getSubtotal(state.quantities);
const couponDeduction = state.couponApplied ? COUPON_VALUE : 0;
const total = subtotal - couponDeduction;
أُفضّل هذا الإصلاح لأن تغيير الكمية لا يُراكم تاريخ الخصم بعد الآن. ما تزال تحتاج إلى قواعد عمل واضحة: هل كود الخصم ثابت أم نسبي؟ هل يمكن أن يتجاوز الإجمالي الفرعي؟ وكيف تُمثَّل العملة؟ عادةً تستخدم الحسابات في بيئة الإنتاج وحدات صحيحة فرعية (integer minor units) أو تمثيلًا نقديًا مقصودًا آخر.
يجب أن يغيّر تغيير الكمية حالة العنصر والإجمالي الفرعي، بينما يبقى كود الخصم الثابت 5 دولارات. فحص الفرق الفعلي للمشروع للتأكّد من أن الخصم المتراكم قد أُزيل.
الخطوة 7 — تحقّق من الإصلاح، وثّقه، وراقبه
أعِد التسلسل الأصلي، ثم اختبر حالات قريبة منه: تقليل الكمية، إزالة كود الخصم، تطبيقه مجددًا، وإزالة عنصر. احتفظ بالفشل كـاختبار انحدار. فحص يقتصر على تحميل السلة فقط لا يحمي تحوّل تغيير الكمية.
| حالة الانحدار | الشرط المتوقع |
|---|---|
| تطبيق كود الخصم على السلة الابتدائية | إجمالي 49$ |
| زيادة الكمية مع كود خصم فعّال | إجمالي 73$ |
| إعادة الكمية إلى قيمتها الابتدائية | إجمالي 49$ |
| تطبيق كود خصم فعّال مسبقًا | خصم واحد، لا اثنان |
| إزالة كود الخصم | الإجمالي يساوي الإجمالي الفرعي الحالي |
يجب أيضًا أن تراجع القواعد المحيطة التي يلمسها هذا التصحيح. إذا كانت الإجماليات تُرسَل إلى خادم أو مزوّد دفع، تحقّق من التطابق عند تلك الحدود. كنت سأسجّل السبب، والملفات المُعدَّلة، ونتائج الاختبار، وحالة الإصدار أو التراجع قبل إغلاق مشكلة في بيئة الإنتاج.
طابِق طريقة التصحيح مع نوع الخلل
معرفة كيفية تصحيح أخطاء الشيفرة البرمجية تشمل معرفة الأداة التي تكشف الدليل المفقود. نقطة التوقّف ممتازة للحالة المحلية؛ وهي أقل فائدة لفشل حدث يوم أمس عبر ثلاث خدمات. اختر الطريقة بحسب الحدود التي تحتاج إلى فحصها.
| نوع الخلل | السؤال الأول | الدليل المفيد |
|---|---|---|
| استثناء | أي مدخل بلغ أول إطار فاشل ذي صلة؟ | تتبّع المكدّس والمتغيرات المتوقَّفة |
| نتيجة خاطئة | أين تبدأ القيمة بالتباعد أولًا؟ | قيم وسيطة وتأكيدات |
| انحدار | ما الذي تغيّر بعد آخر إصدار جيد معروف؟ | فرق الإصدارات وbisect |
| عملية بطيئة | أي مرحلة تستهلك الوقت؟ | التحليل الزمني، والقياسات، والتتبّع |
| فشل متقطّع | أي حالة أو شروط توقيت تتزامن؟ | أحداث مرتبطة ومعرّفات |
| فشل خاص بالبيئة فقط | ما الفرق بين البيئات؟ | الإعدادات، والإصدارات، والصلاحيات، والبيانات |
| خلل في واجهة المستخدم | هل فشل الحدث، أم الاستجابة، أم الحالة، أم التصيير؟ | أدوات المتصفح واختبارات المكوّنات |
استخدم نقاط التوقّف والتنفيذ خطوة بخطوة للحالة المباشرة
نقطة توقّف السطر تُوقّف التنفيذ عند موضع معيّن؛ أما نقطة التوقّف الشرطية فتوقّف فقط عندما يكون شرطها صحيحًا. تغطّي وثائق نقاط التوقّف في Chrome أيضًا نقاط توقّف الأحداث، وDOM، والطلبات، والاستثناءات. يمكنك اختيار المحفّز الأقرب إلى العرَض.
تربط الوثيقة الرسمية بين أعراض مختلفة وشروط إيقاف مختلفة.
استخدم "تخطّي فوق" (Step Over) لفحص نتيجة استدعاء ما، و"خطوة إلى الداخل" (Step Into) عندما تحتاج إلى تنفيذه الداخلي، و"خطوة إلى الخارج" (Step Out) بعد فحص الدالة الحالية. أستخدم تعبيرات المراقبة لمجموعة صغيرة من القيم ذات الصلة. مراقبة كل شيء قد تكون مشتّتة بقدر تسجيل كل شيء في السجلّات تقريبًا.
يمكن لعبارة debugger في JavaScript طلب إيقاف عند توفّر أدوات تصحيح الأخطاء. أزِل عبارات التصحيح المؤقّتة قبل الإصدار. إذا كانت الشيفرة المنشورة مُجمَّعة (bundled) أو مُحوَّلة (transpiled)، فحص إعدادات source map لضمان تطابق المصدر المعروض مع الشيفرة قيد التشغيل.
عبارة debugger هي أداة فحص مساعدة. لا تأثير إيقاف مفيد لها عندما لا تتوفّر أي أداة لتصحيح الأخطاء.
استخدم السجلات والتتبّع والتحليل الزمني للأدلة الموزَّعة
السجلات المُهيكَلة تسجّل الأحداث بحقول ثابتة؛ والتتبّع (tracing) يتبع العمل عبر الحدود؛ والتحليل الزمني (profiling) يفحص أين يُستهلَك الوقت أو الموارد. معرّف الطلب يتيح لك ربط الأحداث ذات الصلة دون التخمين من طوابع زمنية مجاورة. لا تُسجّل بيانات اعتماد، أو أسرار دفع، أو بيانات شخصية غير ضرورية.
بالنسبة لسلة التسوق، قد تكون حقول التشخيص المفيدة هي الكمية، والإجمالي الفرعي، وحالة كود الخصم، وسبب الحساب، والإجمالي الناتج. بالنسبة لتدفّق طلب عن بُعد، تحتاج أيضًا إلى المبلغ المقبول من الخادم ونتيجته. أتجنّب الادّعاء بأن قيمة في الواجهة الأمامية تُثبت ما عالجته خدمة منفصلة فعليًا.
يمكن لنقاط السجلّ (Logpoints) تسجيل قيمة دون تعديل المصدر أو إيقاف التطبيق.
استخدم الاختبارات والتأكيدات والبحث الثنائي لعزل السبب
التأكيد (assertion) يحوّل افتراضًا إلى فحص. اختبار الوحدة يمكن أن يتحقّق من دالة إجمالي خالصة؛ واختبار التفاعل يمكن أن يُشغّل تطبيق كود الخصم متبوعًا بتغيير الكمية. تحتاج إلى كلا النوعين عندما يمكن أن يفشل الحساب وتسلسل الأحداث كل بشكل مستقل.
أختار أصغر اختبار يحافظ على الخلل، ثم أضيف فحصًا أوسع حيث يعبر الفشل حدًّا ما. هذا يحافظ على فائدة الاختبار. فشل كبير من النوع end-to-end قد يُخبرك أن الترتيب خاطئ بينما يترك الطبقة المعيبة غير واضحة.
صحّح شيفرة مُولَّدة بالذكاء الاصطناعي دون الثقة بالتصحيح الأعمى
راجع التغيير المُولَّد قبل تشغيله
يمكن للذكاء الاصطناعي المستخدَم في تصحيح الأخطاء البرمجية أن يساعد في تنظيم الفرضيات وفحص شيفرة غير مألوفة، لكن التفسيرات المعقولة ليست دليل تنفيذ. راجع الملفات المتأثرة، والأوامر، والتبعيات، والاستدعاءات الخارجية، وتحوّلات البيانات. يجب أن تفهم نطاق التصحيح قبل قبوله.
أفصل بين فحص الأنواع (type-checking)، والبناء، وتنفيذ الاختبار، والسلوك المُلاحَظ. كلّها تجيب عن أسئلة مختلفة. يمكن لاختبار reducer أن ينجح بينما تظل معالجة حدث زر معطّلة، لذا احتفظ بنطاق اختبار واضح عند تصحيح شيفرة مُولَّدة بالذكاء الاصطناعي في مشاريعك الخاصة.
أعطِ النموذج دليلًا بدلًا من طلب إعادة كتابة كاملة
قدِّم أصغر شيفرة ذات صلة، والتناقض الدقيق، وإعادة التكرار، والبيئة، والثابت الثابت (invariant). في هذه السلة، الثابت هو "كود الخصم الثابت بقيمة 5 دولارات يُطبَّق مرة واحدة بصرف النظر عن تغييرات الكمية." اطلب تفسيرًا مُرتَّبًا بحسب الأولوية، وأصغر تغيير يمكن أن يختبره.
قد يكون طلبًا مركَّزًا كهذا: "تتبَّع كيف تتغيّر قيمة couponDeduction بعد SET_QUANTITY. اشرح لماذا يصبح الإجمالي الفرعي 78 دولارًا هو 68 دولارًا. اقترح تصحيحًا صغيرًا يحافظ على كود الخصم الثابت عند 5 دولارات، وأضِف اختبارًا لتطبيق كود الخصم قبل تغيير الكمية." تمنح النموذج شيئًا يمكنه التفكير فيه، وشيئًا يمكنك التحقّق منه أنت.
فحص الفرق واعتمد التحقّق المستقلّ
اقرأ الفرق المُقترَح قبل قبول ملخّص مطمئن. هل أزال الإصلاح الخصم المتراكم في إجراء تغيير الكمية، أم أخفى فقط عواقبه في العرض؟ هل غيّر قيمة كود الخصم، أو أدخل حزمة جديدة، أو عدّل مكوّنًا غير مرتبط؟
أريد اختبارات تفشل مقابل الخلل، وتنجح مقابل الإصلاح، مع الاحتفاظ بالأوامر والناتج. يجب أن تُعيد تشغيل إعادة التكرار الأصلية أيضًا. اختبار مُولَّد يمكنه تأكيد توقّع خاطئ بنفس الثقة التي يمكن بها لشيفرة تطبيق مُولَّدة أن تحسب إجماليًا خاطئًا.
صحّح تطبيق Enter Pro من المعاينة إلى الشيفرة
يُظهر العرض التجريبي لتصحيح خلل كود الخصم كيفية تصحيح أخطاء الشيفرة البرمجية في مشروع Enter Pro متحكَّم به. تتبع ست لقطات الشاشة: موجّه الطلب، والخطة، والمعاينة المعيبة، وطلب الإصلاح، والمعاينة المُصلَحة. تم زرع الخلل عمدًا لهذا التمرين.
حدّد قاعدة واحدة قبل البناء
يُثبّت الموجّه الأسعار عند 24 و18 و12 دولارًا، ويبدأ كل كمية بواحد، ويستبعد الشحن والضرائب. القاعدة بسيطة: كود خصم فعّال يخصم بالضبط 5 دولارات. يطلب النسخة المعيبة أولًا بحيث يمكن الاحتفاظ بالفشل قبل الإصلاح.
موجّه بناء Enter Pro: زرع عمدي لخصم ثانٍ بقيمة 5 دولارات بعد تغيير الكمية.
تتوقّع الخطة 54 دولارًا في البداية، و49 دولارًا بعد تطبيق كود الخصم، وإجماليًا معروضًا بقيمة 68 دولارًا مقابل القيمة الصحيحة 73 دولارًا بعد زيادة كمية الغلّاية. تسجّل الخطة السلوك المقصود؛ وتقدّم المعاينة الدليل التالي.
تسجّل خطة المشروع الأسعار، والإجماليات المتوقَّعة، وخلل إجراء الكمية المخطَّط له.
أمسِك بالفشل في المعاينة
مع كون جميع الكميات عند واحد وكود الخصم فعّالًا، تُظهر المعاينة إجماليًا فرعيًا بقيمة 54 دولارًا، وخصمًا بقيمة 5 دولارات، وكلا الإجماليين عند 49 دولارًا. زيادة كمية الغلّاية إلى اثنين ترفع الإجمالي الفرعي إلى 78 دولارًا، لكن الخصم يصبح 10 دولارات. يكشف المبلغ المعروض 68 دولارًا والمبلغ المحسوب بشكل مستقل 73 دولارًا عن التناقض.
قبل تغيير الكمية: إجمالي فرعي 54$، خصم كود الخصم 5$، الإجماليان المعروض والصحيح كلاهما 49$.
بعد زيادة كمية الغلّاية إلى اثنين: إجمالي فرعي 78$، خصم 10$، المعروض 68$، الصحيح 73$.
تخزّن الخطة المرئية قيمة couponDeduction. يضبطها APPLY_COUPON عند 5 دولارات؛ ويضيف SET_QUANTITY 5 دولارات أخرى عندما يكون كود الخصم فعّالًا. يتطابق مسار الحالة المخطَّط له هذا مع زيادة الخصم المُلاحَظة. فحص شيفرة reducer المقابلة قبل تصحيحها.
اطلب إصلاحًا محدَّد الهدف
يحافظ طلب الإصلاح على المشروع، والمنتجات، وقاعدة كود الخصم. يطلب اختبار انحدار يفشل قبل التصحيح وينجح بعده، وأسماء الملفات المُعدَّلة الفعلية والفرق، والأوامر الدقيقة، وأي فحوصات لم يمكن تشغيلها. هذا يمنح الوكيل ثابتًا محدَّدًا ليحميه.
يطلب موجّه الإصلاح تغييرًا صغيرًا ودليل انحدار حقيقي، بينما تظل نتيجة الفشل 68/73 ظاهرة.
تحقّق من الإصلاح عند المستوى الصحيح
تصف اللقطة الأخيرة خلل كود الخصم بأنه تم إصلاحه، وتذكر أن الخصم يُستنتَج الآن من حالة كود الخصم. تُعاد معاينتها إلى الضبط الافتراضي: كل كمية هي واحد، وكود الخصم غير فعّال، وكلا الإجماليين 54 دولارًا. تلتقط هذه اللقطة خط الأساس المُصلَح؛ ولا تُظهر الإجمالي المُصلَح لتغيير الكمية البالغ 73 دولارًا.
المعاينة المُصلَحة في حالة إعادة الضبط: كلا الإجماليين 54$. يحدّد التقرير بشكل منفصل فحوصات واجهة المستخدم غير المُنفَّذة.
يستشهد التقرير بلقطة سجلّ اختبار npm قبل الإصلاح برمز خروج 1. لا تعرض لقطة الشاشة التشغيلات الفاشلة والناجحة الخام الكاملة أو الفرق الفعلي. يذكر أيضًا أن الاختبارات تغطّي دوال reducer والإجمالي، دون بيئة jsdom وTesting Library لاختبار واجهة المستخدم/DOM.
زر "تطبيق" معطّل بينما يكون كود الخصم فعّالًا، لذا فإعادة التطبيق فحص على مستوى reducer. تم تمييز عروض الهاتف المحمول والتنسيق الداكن أيضًا كغير مُتحقَّق منها. لإنهاء التحقّق، أعِد ضبط السلة المُصلَحة وكرِّر 54$ → 49$ → 73$ مرتين، ثم تحقّق من التقليلات وإزالة كود الخصم. احتفظ بالفرق وبناتج الانحدار الكامل.
صعّد الخلل وأغلقه بالدليل
صعّد عندما تتجاوز المخاطر قيمة إجراء تجربة أخرى
صعّد عندما يتضمّن الخلل مدفوعات، أو فقدان بيانات، أو تعرّضًا أمنيًا، أو سلوكًا غير آمن، أو نظامًا لا يمكنك فحصه. لا يزال يمكنك جمع دليل غير تدخّلي، لكن يحتاج المسؤول إلى اتخاذ قرار بشأن الاحتواء والإصدار. لن أختبر تصحيحًا افتراضيًا لكود خصم مقابل معاملات عملاء حقيقيين.
انقل حزمة دليل قابلة لإعادة التكرار
يجب أن يشمل التسليم الإصدار المعيب، وإعادة التكرار، والنتيجة المتوقَّعة والفعلية، والسجلات ذات الصلة، والفرضيات المختبَرة، والإجراء الوقائي الحالي. أضِف معرّفات الطلبات والتوقيت عندما يعبر الفشل الخدمات. أنت تنقل حالة التحقيق، لا تُسند مجرّد شكوى غامضة.
أكمِل قائمة فحص تصحيح أخطاء الشيفرة البرمجية
قبل الإغلاق، تأكّد من السبب، والفرق المحدَّد، وإعادة التكرار الأصلية، وحماية الانحدار، والمسارات المجاورة، وحالة النشر. أزِل التشخيصات المؤقّتة أو اجعلها آمنة ومقصودة. أسجّل أيضًا أي فحص يظلّ غير محسوم، حتى لا يخلط مراجع مستقبلي بين الصمت والنجاح.
يربط الإغلاق بين السبب والإصلاح والدليل المحتفَظ به. البناء الناجح وحده يغطّي جزءًا واحدًا منه فقط.
خاتمة: كيف تُصحّح أخطاء الشيفرة البرمجية بشكل موثوق
لا تحتاج إلى إعادة كتابة جذرية لتصحيح الشيفرة بفعالية. تحتاج إلى تناقض دقيق، وإعادة تكرار محفوظة، ودليل يُضيّق السبب. في تمرين سلة التسوق، الدليل الحاسم هو ارتفاع الخصم من 5 إلى 10 دولارات عند تغيّر الكمية.
العملية التي أُفضّلها لتصحيح شيفرة مُولَّدة بالذكاء الاصطناعي هي الفحص أولًا، ثم تغيير أمر واحد ذي صلة، ثم التحقّق من التحوّل الأصلي بعد ذلك. يجعل عرض Enter Pro التجريبي الحساب وتغيّر الحالة مرئيَين، بينما يفصل تقرير إصلاحه فحوصات الحساب عن فحوصات واجهة المستخدم غير المُنفَّذة. احتفظ بالفرق، وناتج الانحدار، ونتائج المعاينة المتكرّرة معًا بحيث يمكن للشخص التالي تقييم الإصلاح.
جرّب هذا الأسلوب في Enter Pro: احتفظ بحالة فشل، واطلب إصلاحًا محدَّد الهدف، وراجع الدليل قبل قبوله.
الأسئلة الشائعة
ما أول شيء يجب فعله عندما تفشل الشيفرة؟
اكتب السلوك المتوقَّع والفعلي، واحتفظ بالمُدخل الذي سبّب الفشل، وأنشئ إعادة تكرار. إذا كان الخلل يُسبّب ضررًا فعليًا حيًّا، فقد يحتاج الاحتواء إلى أن يحدث قبل مزيد من التحقيق.
كيف أُصحّح شيفرة تفشل فقط في بعض الأحيان؟
سجّل تحوّلات الحالة، والتوقيت، وإعادة المحاولات، والمعرّفات عبر محاولات متكرّرة. قارِن التشغيلات الفاشلة والناجحة تحت شروط مماثلة. إعادة تشغيل ناجحة واحدة لا تُظهر أن السبب المتقطّع قد اختفى.
هل يجب أن أستخدم عبارات الطباعة أم مُصحّح الأخطاء؟
استخدم مُصحّح الأخطاء عندما تحتاج إلى تدفّق تحكّم مباشر وقيم محلّية. استخدم السجلات لدليل بعيد، أو تاريخي، أو حسّاس للتوقيت. عبارات الطباعة المؤقّتة مفيدة عندما تُجيب عن سؤال محدَّد ويتم تنظيفها بعد ذلك.
هل يمكن للذكاء الاصطناعي تصحيح الشيفرة من أجلي؟
يمكن للذكاء الاصطناعي المستخدَم في تصحيح الأخطاء البرمجية أن يقترح أسبابًا، ويفحص شيفرة ذات صلة، ويقترح اختبارات أو تصحيحات. ما تزال تحتاج إلى مراجعة التغيير والتحقّق من النتيجة. تعامل مع التفسيرات المُولَّدة والفحوصات المُبلَّغ عنها وفقًا للدليل المتوفّر.
كيف أُصحّح الشيفرة دون أن أزيد الخلل سوءًا؟
احتفظ بالحالة الأصلية، واعمل في بيئة منفصلة، وغيّر متغيّرًا واحدًا ذا صلة في كل مرة. حافظ على مسار تراجع لتغييرات بيئة الإنتاج، وتجنّب إجراءات التشخيص التي تُعدّل بيانات عملاء حقيقية.
لماذا يعود خلل بعد إصلاحه؟
قد يكون التصحيح أخفى العرَض فقط، أو فوّت مسارًا آخر، أو فشل في الاحتفاظ بالحالة في اختبار انحدار. قارِن الفشل الجديد بالدليل الأصلي قبل افتراض أن له نفس السبب.
كيف يمكنني استخدام Enter Pro لتصحيح الشيفرة؟
احتفظ بالمعاينة المعيبة والإصلاح في مشروع واحد. أعطِ Enter Pro تسلسل الإجراءات، والإجماليات المتوقَّعة والفعلية، والقاعدة التي يجب أن يحافظ عليها التصحيح. اطلب منه فحص الحساب، وإجراء تغيير محدَّد الهدف، والاحتفاظ بدليل الانحدار. راجع الفرق الفعلي وكرِّر التسلسل بنفسك.
ما الذي يجب أن أتحقّق منه بعد أن يُصلح Enter Pro خللًا؟
كرِّر الفشل الأصلي والمسارات القريبة منه، ثم فحص نتائج الاختبار الكاملة. في هذا العرض التجريبي، يجب أن تُظهر المعاينة المُصلَحة 73 دولارًا بعد تطبيق كود الخصم وزيادة كمية الغلّاية إلى اثنين. لا تستطيع لقطة شاشة إعادة الضبط عند 54 دولارًا وحدها إثبات ذلك. تعامل مع اختبارات reducer، واختبارات تفاعل واجهة المستخدم، وفحوصات البناء كأدلة منفصلة.
