قاعدةٌ اخري من قواعد التنقيح debugging العملية، و لكنها هذا اليوم بسيطةٌ جداً و قد يجد الواحد منكم نفسه يراعيها بالفعل أو لا يحتاج إليها من الأصل.
الحكاية وما فيها أنه حينما تعمل علي مشروعٍ برمجيٍ ضخمٍ (مثلاً مُفسِّرٍ للغة برمجةٍ متقدمة) فيجب عليك أن تقوم بكتابة العلل التي تقابلها أثناء اختباراتك للبرنامج باستمرار و بأسلوبٍ واضحٍ مستفيض؛ حتي يمكنك الرجوع لها بسهولةٍِ فيما بعد لترتيب أولويات عملك في المراحل القادمة، و لتغطية جوانب النقص و حل المشاكل التي تظهر في عمل البرنامج.
هذا أمرٌ طبعيٌ، أليس كذلك ؟
كل الناس تدرك أهمية أن تكتب العلل التي تظهر في البرنامج لتسهيل حلها فيما بعد، لكن الذي قد يغفل عنه كثيرٌ من الناس و قد يسبب لهم في بعض الأحيان ارتباكاً غير مرغوبٍ فيه هو استخدام وسيلةٍ قوية و واضحةٍ لمعرفة العلل التي تم حلها من تلك التي لم تُحَل بعد، و التفرقة بينهما و بين العلل التي تم حلها بشكلٍ جزئيٍ علي أن يتم حلها بشكلٍ كاملٍ فيما بعد. و التدوين الشامل لكل هذا بحيث يسهل مراجعته و ترتيبه و تحديد الأولويات و الخطط المستقبلية من خلاله ببساطة.
حل هذا بالنسبة لي (و لخبرتي الصغيرة و وقتي الضيق) كان عمل ملفٍ خاصٍ أكتب فيه كل ما يتعلق بالمشروع (مثلاً: مُفسِّر أُبْدِع) من عللٍ و تطوراتٍ و أرقام إصداراتٍ و الربط بينها و بين الخصائص التي ستكون متوفرةً لكل إصدارة،
و اعتدتُ أن يكون الجانب الأيمن من ذلك الملف خاصاً بكل العلل و الخطط المستقبلية و الأمور التي أريد تذكرها بدون ترتيبٍ جيد، بحيث أكتب ما يخطر في ذهني مباشرةً قبل أن أنساه، لكني أقوم علي الناحية اليسري في كل فترةٍ بكتابة العلل التي سأقوم بحلها في كل فترةٍ من الفترات من بين تلك التي تملأ الجانب الأيمن،
و هكذا لم أكن أعتمد علي مجرد وُريقةٍ صغيرةٍ أُلصِقها علي الحائط بجانبي لتذكرني بما يجب عَلَيَّ عمله في الفترة التالية كما يفعل كثيرٌ من الناس، إنما كان لدي دفترٌ كاملٌ فيه قصة حياة كل إصدارةٍ من الإصدارات للمُفسِّر، و كذا فهو يحتوي علي معظم الخوارزمات الأساسية التي ابتكرتُها لأُبْدِع (إن لم يكن يحتوي عليها كلها) !
المشكلة هي أنه يجب التنبه عند استخدام أسلوبٍ مماثلٍ أنه قد ينسي الواحد منا تحديث معلومات العلل في مكانٍ من الأماكن حينما يُحدِّثها في الأماكن الأخري، و بالتالي يجد أحدنا أن هناك علةً ينبغي عليه إصلاحها و قبل البدء في العمل علي ذلك الإصلاح يكتشف عند التدقيق أنه قد حَلَّها بالفعل من قبل، و لكنه نسي أن يضع العلامة التي تدل علي هذا في مكانٍ من أماكن شرح العلة !
من الواضح أنها ليست مشكلةً ضخمةً جداً، و لكنها قد تكون خطيرةً إذا ما تكررت بحيث يُصبح المُبرمِج غير قادرٍ علي تحديد أي العلل تم حلها و أيها حُلَّت جزئياً و أيها لم تُحَل بعد، و حينما تتضارب بيانات العلل بين أرجاء الملف الخاص بالمشروع، و المصيبة الأكبر لو كان ذلك الملف قد تضخم في الحجم لأن الأمور تصير كابوسية.
لذا فبكل بساطةٍ: عَوِّدوا أنفسكم علي عمل ملفٍ كاملٍ لكل مشروعٍ "ضخمٍ" تعملون عليه حتي لا تضيع عليكم أيٌ من تفاصيله، و حتي يكون بإمكانكم العودة إليه بسهولةٍ لو حدث أن انقطعتم عنه لفترةٍ من الفترات، و لكن انتبهوا إلي جزئية تناثر بيانات العِلَل و الأماكن التي ينبغي تحديثها عند التعامل معها (سواءٌ بحلها أم بتأجيلها أم بخلافه).
بفضل الله تعالي أولاً و آخراً يسعدني أن أُعلن الإطلاق الرسمي لمشروع (البرمجة بإبداع) و الإصدارة الأولي من لغة البرمجة العربية الإحترافية إبداع بعد عامين كاملين من العمل بصمتٍ قدر الإمكان، و كان عامٌ كاملٌ منهما مُفرَّغاً تماماً للعمل علي المشروع بكل قوة، 
