الخميس، 31 يناير، 2013

حَبِّر الورقة !

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

الإجابة هينةٌ و بسيطة و يمكن اشتفافها من قاعدة "حَبِّر الورقة"، لا أعني أن يقوم المبرمج بكتابة أي شيءٍ في أكواده حتي لو كان خطأً؛ فهذه مصيبةٌ قد تجعله يحس بالمزيد من الملل و تؤخر العمل إلي أن يتم التخلص من الخُرافات التي كتبها. بل أقصد أن يقوم المبرمج بكتابة الأكواد التي لا تحتاج إلي تفكيرٍ عميق، و لا ابتكار خوارزماتٍ مُعقَّدةٍ لا يستطيع ذهنه المُتعَبُ التفكيرَ فيها، مثل تعديل الوراثة بين العديد من الأصناف classes inheritance في مشروعه، أو إضافة تعليقاتٍ comments لأجزاء من الكود لم يتم التعليق عليها كما يجب، أو تكملة عمل التوثيقات documentations للمشروع، او ما شابَههن من أمور.
فائدة هذا الأسلوب أنه لن يكون هناك وقتٌ ضائعٌ لم تتم الاستفادة منه، بل كل ما هنالك أن جدول الأعمال قد اختلف بعض الشيء، و تم إنجاز أشياءٍ كانت موجودةً في ترتيبٍ متأخر. و في نفس الوقت لم يكن هناك الضغط النفسي الذي يسببه الجهد العقلي علي المُرهَقين من المبرمجين.

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

ليست هناك تعليقات:

إرسال تعليق