أخطاءُ المُبرمجين المبتدئين

ترجمة بتصرّف لمقال: Beginner Programmers’ Mistakes)

الترجمة والتدقيق والمراجعة: أسامة خان

لنتحدّث عن أخطاءٍ يرتكبها المبتدئِون عادةً، لكن قبل ذلك أوضح شيئًا: إذا كنت منهم، فنحن لا نريدك أن تستَاء حِيال أخطاءِك التي قد ترتكبها، بل نريد إطلاعك عليها وتعليمك علاماتها لتكتشفها ونذكرك لتتجنّبها.

لقد ارتكبت من هذه الأخطاء الكثير. وهي الطريقة التي علمتني لأقوم بعمل أفضل. لا تستاء إن كنت ترتكبها اليوم، تعلَّم لماذا تعتبر أخطاء؟ أنا سعيدٌ لأني شكّلت عادات ترميز (Coding) تساعدني في تجنّبها. عليك فِعلُ ذلك أيضًا.

لم تُرتَّبِ الأخطاء وِفق أي مِعيار.

١. البرمجة دون تخطيط

المحتوى عاليَ الجودة لا يُنشأ بسهولة، بل يتطلّب تفكيرًا وبحثًا دقيقًا. البرامِج عالية الجودة كذلك.

كتابة برنامجٍ جيِّد عملية متدفِّقة -متسلسلة-:

تفكير، بحث، تخطيط، كتابة، تحقق، تعديل.

لسوء الحظّ لا يوجد اختصار جيِّد لهذه. أنت بحاجة للتعوّد على القدرِ الكافي من هذه النشاطات.

أحد أكبر الأخطاء هي البدءُ في كتابةِ البرمجية فورًا دون تفكيرٍ أو بحث كافٍ. بالرغم من أنه قد ينجح في تطبيقٍ صغير مستقلّ، إلا أنّ لهُ تأثير سلبيّ كبير على التطبيقات الكبيرة.

كما تحتاج للتفكير قبل قولٍ كلمةٍ قد تندم عليها، فأنت تحتاج للتفكير قبل ترميزٍ قد تندم عليه. الترميز وسيلةٌ لإيصال أفكارك.

«إن كنت غاضبًا، عُدّ إلى عشرة قبل التحدّث. أمّا إن كنت غاضبًا جدًا، عُدّ إلى مئة».
توماس جيفرسون (Thomas Jefferson)

تنطبق نصيحته على الترميز كذلك:

«عند مراجعة الترميز، عُدّ إلى عشرة قبل إعادة صياغته. إذا لم تكُن لهُ اختبارات، عدّ إلى مئة».
سامير بونا (Samer Buna)

البرمجة هي قراءةُ الترميز السابق، البحث عن المطلوب وكيف سيناسِب النظام الحاليّ، وتخطيط لكتابة خصائص بإضافات صغيرة قابلة للاختبار. غالبًا كتابة أسطر الترميز فعليًا تشكِّل ١٠% من العملية ككلّ.

لا تفكِّر أن البرمجة هي كتابة سطور الترميز. البرمجة إبداعٌ مبنيّ على المنطِق يحتاج لعناية.

٢. التخطيط الزائد قبل كتابة الترميز

نعم، التخطيط قبل الترميز جيِّد، لكنّ الشيء إن زاد عن حدِّه انقلب إلى ضدِّه. شرب كمٍ كبير من الماءٍ قد يُسمِّمُك.

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

أتحدّثُ هنا فقط عن التخطيط للخصائص الصغيرة. التخطيط لكل الخصائص مرةً واحِدة محظورٌ وُجوبًا! هذا ما نسمِّيه نهج الشلال (Waterfall Approach)، وهي خطّة خطّيّة بها خطوات صغيرة تُنفّذ واحِدة تِلو الأخرى. لك أن تتخيل كمّية التخطيط المطلوب لهذا النّهج. لا أتحدّث عن هذا النوّع من التخطيط، نهج الشلال لن يعمل، أي شيءٍ معقّد يمكن أن يُطَبّق عليه نهج التكيِّف الرشيق مع الواقع (agile).

كتابة البرمجيات لابد أن تكون نشاطًا متجاوِبًا. في خطة الشلال: ستُضيف خصائص لم تفكر بها، وتُزيل أخرى لأسباب لم تأخذها بعين الاعتبار. عليك إصلاح الأخطاء والتكيف مع التغيّرات. يجب أن تكون رشيقًا.

على كلٍ، خطط دائمًا لبضعة خصائص تالية. خططّ بحذر دون تفريط أو إفراط، كليهما سيضرّان جودة الترميز، لا يمكنك المخاطرة بجودة الترميز.

٣. التقليل من أهمّية جودة الترميز

إذا كنت ستنظر إلى جانبٍ واحِد من الترميز الذي تكتبه، ينبغي أن يكون المقروئية. الترميز المُبهَم لا فائدة منه، حتى لإعادة الاستخدام.

لا تقلل أبدًا من أهمية جودة الترميز. انظر إلى الترميز على أنّه وسيلة لإيصال التطبيق، عملُك الرئيسي كمبرمجِ هوَ إيصال تطبيقاتِ الحلول التي تعمل عليها.

أحد اقتباساتي المفضّلة عن البرمجة:

«برمِج دائمًا وكأنّ المسؤول عن صيانة برمجيِّتك مختلٌ عقليّ، يعرِف أين تسكُن».
جون وودز (John Woods).

نصيحةٌ رائعة يا جون!

حتّى أصغر الأشياء يهُمّ. على سبيل المثال: إذا لم تلتزِم بالمسافة البادئة والحروف الكبيرة، يجب أن تفقد ترخيص البرمجة.

الأمر الآخر: كتابة سطورٍ طويلة. أي شيء يتجاوز الثمانين حرفًا يصعب قراءته. قد تميل إلى فكرةِ أن وضع شروطٍ طويلة بنفس السّطر يجعل كتلة جملة الشرط أوضح، لا تفعل، لا تتجاوز الثمانين حرفًا أبدًا.

عددٌ من المشاكل البسيطة مثل أعلاه، يمكن حلّها بسهولة باستعمال أدوات التنسيق. في JavaScript لدينا أداتان رائعتان تعملان معًا بإتقان: ESLint و Prettier. استعملها معًا لمصلحة نفسِك.

الأخطاء المتعلِّقة بجودة الترميز:

  • كتابة أسطر عديدة في الدّالة (function) أو الملف. يجب عليك دائمًا تقسيم الترميز إلى كُتل صغيرة قابلة للاختبار والإدارة باستقلالية.

أي دالّة أكثر من عشرة أسطر، طويلة.

  • لا تستعمل أداتيّ نفيِ. رجاءً لا لا لا تفعل ذلك.

استعمال أداتيّ نفي هو فقط ليس ليس سيء.

  • تسمية المتغيرات بأسماء قصيرة أو عامّة أو بناءً على نوعِها. سمِّ متغيراتِك بأسماء وصفية غير غامضة.
هناك فقط شيئان صعبان في علم الحاسِب: مسح التّخزين المؤقت وتسمية الأشياء. 
فِل كارلتون (Phil Karlton)
  • استعمال النصوص والأرقام مباشرةً دون وصف. إذا أردتَ كتابة ترميز منطقيّ يعتمدُ عليها، ضعِ القيمةَ في ثابتٍ (constant) وسَمِّهِ.

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

الاستعمال المفرِط للمنطِق الشَّرطِيّ. أغلب ما تظنّه بحاجة إلى شرط، يمكن استيفاؤه بدونه. انظُر في البدائل، واختر ما يُحسِّن المقروئية. لا تُحسِّن الأداء ما لم تكن قادرًا على قياسِه. وكذلك: ابتعِد عن تنسيق يُودا (yoda) للشرط، وعن إسناد القيم للمتغيرات داخل الجملة الشرطية.

٤. اختيار الحلّ الأول

هذه هي العلامة الخفيّة الدالّة على المبتدئ الحقيقي. تحدث مشكلة، يبحثون عن حلّ، يُطبِّقون هذا الحلّ. يُنفِّذون بسرعة دون تفكير في التعقيدات والمشاكل المحتملة للحل المُحدد.

بالرغم من أنّ الحل الأول قد يكون مغريًا، إلا أن الحلول الجيِّدة غالبًا لا تُكتشف إلّا بعد التشكيك فيما وجدت من حلول. إذا لم تستطع التفكير في عدَّة حلول لمشكلة مّا، فربما تكون هذه علامة على عدمِ فِهمك للمشكلة تمامًا.

كمُبرمج محترف، إنّ عملك لا يقتصر على إيجاد حل للمشكلة، إنّما إيجاد أبسط حل لها. وأعني: أن يكون حلًا صحيحًا أداؤه كافٍ، وسهلَ القراءة والفهم والصيانة.

هناك طريقتان لتصميم البرمجية. الأولى هي جعله بسيطًا يوضِح أنّه لا قصور فيه، والثانية هو جعله معقدًا حتّى لا يكون فيه قصور واضِح.
تشارلس هوَر (C.A.R Hoare)

٥. التَّشبُّث

خطأٌ آخر يرتكبه المبتدئِون، وهو التشبّث بالحلِّ الأوّل حتّى بعد معرفتِهم أنّه ليس الأفضل. ربما هذا مرتبطٌ نفسيًا بِعقلية «التشبث». هي عقلية جيِدة في معظم الأنشطة، لكنّها ليست كذلك في البرمجة. للمعلومية، عندما نتحدث عن البرمجة، فإن العقلية الصحيحة هي: اِفشَل مُبكرًا، افشل كثيرًا.

اللحظة التي تشك فيها في الحلّ، فكِّر في التخلّص منه وإعادة التفكير في المشكلة. بغضّ النّظر عن المبلغ الذي استثمرته في الحلّ. أدوات التحكم في مصدر البرمجية مثل (GIT) قد تساعدك في تجربة حلولٍ مختلفة. استفد منها. لا تتعلَّق بالحلّ بسبب مقدارِ الجهد الذي بذلته فيه، التّرميز السيء لابد أن نتخلص منه.

٦. عدم البحث بجوجل

في حالات عديدة، أهدرت وقتًا ثمينا في محاولة حل مشكلة، بينما كان ينبغي علي البحث.

ما لم تكن تستخدم تقنية متطوّرة، فعندما تواجه مشكلةً مّا، فلعلّ شخصًا مّا قد تعرض لنفس المشكلة، وأوجَد حلًا لها. حافظ على وقتك وابحث أولًا.

أحيانًا، نتائج البحث ستكشف أنّ ما تظنّه مشكلة ليس كذلك، وعليك احتواؤها بدلًا من حلِّها. لا تتوقّع أنّك تعرِف ما هو مطلوب لاختيار الحل، جوجل سوف يُفاجئِك.

وفي ذلك، للمبتدئ علامةٌ أخرى وهيَ نسخ التّرميز واستعمالِها دون فهمها. على الرّغم من أنّ الترميز قد يحلّ مشكلتك، لكن لا ينبغي استعمالُ أي سطر من التعليمات البرمجية دون فهمها جيِّدًا، إذا كنت تريد أن تصبح مبرمجًا محترفًا، لا تتوقّع أنّك عارفٌ بكلّما تفعله.

كشخصٍ مبدع، أخطر فكرةٍ هي أنّك تعرف بالضبط ما تفعله.
برِت فِيكتور (Bret Victor)

٧ . عدم استعمال التغليف (Encapsulation)

هذه النّقطة ليست عن استعمال نموذج البرمجة الكائنيّة. استخدام مفهوم التغليف عمليٌّ دائمًا. عدمُ استعمالهِ يؤدي إلى أنظمة صعبة الصيانة.

كل خاصيِّة يجب أن تكون في مكانٍ واحِد في البرمجيِّة لمعالجتها. وهي غالبًا مسؤولية كائن واحِد. الكائِن يجب أن يكشِف فقط ما استخدامه ضروري للكائنات الأخرى في البرمجية. هذا لا يتعلق بمفهومِ السرِّية، بل بمفهوم تقليل التبعيِّة بين أجزاء البرمجية المختلفة. اِلتزامك بهذه القيود يسمح لك بتعديل ترميز المصنفات البرمجية، والكائنات، والدّوال دون تعطيل المكونات واسعة النطاق.

يجب أن تُفصل وِحدات المفاهيم المنطقية في مصنفات خاصة بها. ونقصد بالمصنفات: قالِب المخطط (blueprint template). ربمّا تكون مصنفًا (Class) أو دالّة لكائن. ربمّا تُعرِّفها كِوحدة (Module) أو كحِزمة.

في المصنفات المنطقية، الأجزاء المستقلة ينبغي أن تحتوي على دوالّها الخاصة. الدوالّ لابد أن تؤدي مهمّة واحدة فقط وبكفاءة. المصنفات المتشابهة ينبغي أن تتشابه أسماء دوالِّها.

عادةً ليس لدى المبتدئين دافع إنشاء مصنفٍ جديد لوِحدة مفاهيمية، ولا يمكنهم تحديد ما يمكن أن يكون مستقلًا. إذا رأيت المصنفات الخدمية (Util classes) استُعمِلت كمكبٍ لعدةٍ أشياء غير مترابطة، فهي علامةُ برمجية مبتدئ. إذا غيَّرت تغييرًا بسيطًا وأكتشفت أن له تأثير متسلسل وعليكَ تعديل عدّة أشياء في مكانٍ آخر، فهي كذلك علامةٌ أخرى.

قبل إضافة دالّة لمصنّف، أو مسؤوليات جديدة لدالّة، فكِّر واسأل نفسك. استثمر وقتًا في هذا. لا تتخطّاها ولا تفكر بأنّك ستعيد صياغتها لاحقًا. افعلها بشكلٍ صحيح من المرّة الأولى.

الفكرة الشاملة هي أنّك تريد ترميزًا بتماسك عالٍ، واقترانٍ منخفض، وهو مصطلح رائع يعني الحِفاظ على الترميز المتعلِّق متقاربًا (في مُصنف) وتقليل التبعيات بين مختلفِ المصنّفات.

٨. التخطيط للمجهول

التفكير في ما وراء الحلّ الذي تكتبه، مُغرٍ حقًا. كل أنواعِ الأسئلة ستحوم في رأسك عند كل سطرٍ تكتبه. هذا جيِّدٌ لاختبار الحالات المتطرِّفة (edge cases)، لكنّه سيءٌ استعماله كمُرشدٍ للمتطلبات المُحتملة.

عليكَ تصنيف الأسئلة في ذهنك، إلى أي النّوعين تنتمي؟ لا تكتب ما لا تحتاجه اليوم. لا تخطط للمستقبلِ المجهول.

كتابة خاصِّية فقط ظنًا منك أنك قد تحتاجها في المستقبل خطأٌ ببساطة. لا تفعل ذلك.

اكتب دائمًا أقلّ قدرٍ من الترميز الذي تحتاجه اليوم للحلّ الذي تُنّفِّذه. بالتأكيد أدِر الحالات المتطرِّفة، لكن لاتُضِف ميزاتٍ لست بحاجتها.

النّمو من أجلِ النّمو فقط هو مبدأُ الخليَّة السرطانية.
إدوارد آبي (Edward Abbey)

٩. استعمال هيكلة بيانات خاطئة

عند الاستعداد للمقابلات الشخصية، المبتدئون غالبًا يصبّون تركيزهم على الخوارزميّات. من الجيِّد تمييز الخوارزميات الجيِّدة واستعمالها عند الحاجة، لكن حفظَها لن يُعدَّ من عبقريتك البرمجية.

ومع ذلك، فحِفظ نقاط القوّة والضعف في مختَلفِ هياكل البيانات التي يمكنك استعمالها بلغتك ستجعل منك مطوِّرًا أفضل.

استعمال هيكلة بياناتٍ خاطئة هي علامة واضحة على أنّ الترميز ترميزُ مبتدئ هنا.

ليس هناك كتاب يعلِّمك عن هياكل البيانات، لكن دعني أذكر لك بعض الأمثلة سريعًا:

مثال: استعمال القوائم (مصفوفات) بدلًا من الخرائط ( كائنات)

قد يكون أكثر خطأٍ شائع في هيكل البيانات، هو استعمال القوائم (lists) بدلًا من الخرائط (maps) لإدارة قائمة السجلّات. نعم، لإدارة القائمة عليك استعمال خريطة.

على سبيل المثال في جافاسكربت: أشهر هيكل قوائم هو المصفوفة وأشهر هيكل خريطة هو الكائِن (أيضًا هناك هيكل خريطة في جافاسكربت الحديثة).

استعمال القوائم بدلًا من الخرائط غالبًا خطأ. وهو أشد خطأً في المجموعات الكبيرة، لكن أقول لك: إلتزم بها دائمًا. هناك حالاتٌ خاصّة يكون فيها استعمال القوائم خيارًا أفضل من الخرائط، وهذه الحالات بدأت تختفي في اللغات الحديثة. فقط استعمل الخرائط.

السبب الرئيسيّ في أهميّتها هو الوصول للعناصِر وهو في الخرائط أسرع بكثيرٍ من القوائم. الوصول للعناصر شيء تفعله باستمرار.

أمّا أهمية استخدام القوائم يكمُن في ضمانها لترتيب العناصر. ومع ذلك، يمكن لهياكل الخرائط الحديثة ضمانُ ذلك.

مثال: عدم استعمال التكديس

عند كتابة أي ترميز يتطلّب نوعًا من الاستدعاء الذاتي (recursion)، من السهل استعمال مفهومه. لكنّه من الصّعب تحسينُه، خاصةً في البيئة أحادية المسار (single-threaded).

يعتمد تحسين الاستدعاء الذاتي على ما تُرجِعُه دالّة الاستدعاء الذاتي. مثال: الدالة التي تُعيد استدعاء نفسها مرتين أو أكثر، أصعب بكثير في التّحسين من الدّالة التي تعيد استدعاء نفسها مرةً واحِدة.

ما ينساهُ المبدئون غالبًا، هو أنّ هناك بدائل للاستدعاء الذاتي. يمكنك ببساطة استعمالُ هيكلة التكديس (Stack structure). ارسِل استدعاءَات الدالّة للمُكدِّس بنفسِك ثمّ ابدأ في تفريغِها عندما تكون جاهزةً للاجتياز.

١٠. جعل الترميز أسوأ مما كان عليه.

تخيَّل أنّك أُعطِيتَ غرفةً فوضويَّة كهذه:

ثمّ طُلب منك إضافة عنصرٍ لهذه الغرفة، ونظرًا لأنّها فوضى كبيرة فقد تميل إلى وضعه في أي مكان. فيمكنك إنجاز مهمّتك في ثوانٍ.

لا تفعل هذا مع ترميزٍ فوضويّ. لا تجعله أسوأ! اترك الترميز أنظف ممّا كان عندما تتعامل معه.

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

فيما يلي بعض الممارسات التي غالبًا ستجعل الترميز أكثر فوضويةً مما كانت (ليست قائمة كاملة):

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

 ومما يتعلق بنفس الموضوع، فكِّر في الترميزِ التّالي:

إنّ دالة isOdd أعلاه تحوي عدة مشاكل، أترى أوضحها؟

إنّه استعمالُ عبارةٍ شرطية لا داعي لها. هنا ترميزٌ مُقابل، لنفس العملية:

١١. التعليق على نقاط واضِحة

أتفادى التعليق ما استطعتُ. أعتقد أنّ التعليقات يمكن استبدالها بتحسين تسمية العناصر في التّرميز.

مثال، بدلًا من الترميز التّالي:

نفسُ التّرميز يمكن كتابته دون تعليقات، كالتّالي:

إنّ مجرّد تسميةٍ أفضل للدوال والمتغيرات كفيلٌ بزوال أهمية التعليقات. انتبه لهذا قبل أي تعليق.

أحيانًا تُجبر على كتابة التعليقات لكونها السبيل الوحيد لتوضيحِ الترميز. وهنا عليك تنظيم التعليق حتّى يُجيب على (لماذا هذا الترميز) بدلًا من (ماذا يفعل الترميز).

إذا كنت منجذبا لكتابة تعليقات تفسِّر فعلَ التّرميز (ماذا) للتوضيح، فرجاءً لا توضِّح الواضِح. هنا مثال على تعليقات المبتدئ:

لا تكن مثله. ولا تقبل هذا التّرميز. امسح هذه التعليقات إذا كنت تتعامل مع المبتدئين. إذا كنت توظِّف مبرمجين يكتبون مثل هذه التعليقات، سرِّحهم الآن.

١٢. عدم كتابة الاِختبارات

سأجعل هذه النقطة بسيطةً. إذا كنت تظنّ أنّك مبرمج خبير وهذا الظنّ يمنحك الثقة الكافية لكتابة الترميز دون اختبارات، فأنت في كتابي مُبتدئٌ (حرفيًا).

إن كنت لا تكتب هذه الاختبارات أثناء البرمجة، فالراجح أنّك تختبر برنامجك بطريقة أخرى، يدويًا. عند بناءِ تطبيق للشبكة (web application)، فستُحدِّث وتتفاعل مع التطبيق كلّ بضعة أسطر برمجية.

أنا فعلتُ ذلك أيضًا. لا خطأَ في اختبارِ تطبيقك يدويًا. لكن يجب أن تختبر تطبيقك يدويًا لتحديد كيفية اختبارِه تلقائيًا. إذا نجحت في اختبار التفاعل مع تطبيقك، عُد للمحرر واكتب ترميزًا لتنفيذ الاختبار تلقائيًا في المرّة القادمة عند إضافة بعض التعليمات البرمجية.

أنت إنسان. ستنسى اختبار جميع عمليات التحقق السابقة بعد كل تعديل للترميز. اجعلِ الحاسب الآليّ ينفذّ ذلك عنك.

إذا استطعت، ابدأ بتخمين أو تصميم عمليات التحقق قبل كتابة تّرميز لاستيفاءِها. التطوير المُقَاد بالاختبار (TDD) ليس مجرّد موضةٍ وهمية. إنّما هو يؤثر إيجابيًا على طريقةِ تفكيرك في الخواصِّ وكيفية استيفاءها بأحسن تصميم.

التطوير المُقاد بالاختبار ليس للجميع ولا يعمل جيدًا في جميعِ المشاعِر، لكن إن أمكن تطبيقه (ولو جزئيًا) فطبِّقه.

١٣. افتراض أنّ كلما يعمل صحيح

ألقِ نظرةً على الدالّة التّالية (sumOddValues) التي تجمع الأعداد الفردية. هل هناك خطأ هنا؟

التأكيد (assertion) نجَح. الأمور على مايرام. صحيح، فعلًا؟

مشكلةُ الترميز أعلاه أنّه ناقص، يتعامل بشكل صحيح مع بعض الحالات والتأكيد المستخدم واحدٌ منها.

الدالّة أعلاه تحتوي عددًا من المشاكل إضافة لما سبق. دعنا نمرّ ببعضها:

المشكلة الأولى: ليس هناك معالجة للمدخلات الفارغة. ما الذي سيحدث لو لم يمُرَّرَ للدالة أي متغيرات؟ سيظهر الآن خطأٌ يوضِح كيف تتعامل الدّالة مع ذلك:

خطأ كتابيّ: لا يُمكن قراءة خاصية ‘reduce’ غير محددة.

هذه علامة على ترميزٍ سيء لسببين رئيسيين:

  • مستخدميّ الدالّة يجب أن يكتشفوا تفاصيل التنفيذ المتعلقة بها.
  • رسالة الخطأ ليس مساعِدة للمستخدم. دالّتك لم تعمل معهم. على كلّ حال: إذا كانت رسالة الخطأ عن طريقة الاستخدامِ الخاطئة أوضح، فسيعرفون أنّهم استعملوا الدالة بشكل خاطئ. مثال: يمكنك جعل الدالة ترمِي استثناءً معروفًا للمستخدم مثل:

خطأ كتابيّ: لا يمكن تنفيذ الدّالة بقائمة فارغِة.

ربما بدلًا من رسالةِ الخطأ، تريد تصميم دالتك لتتجاهل المُدخل الفارغ وتُرجِع صفرًا. أيًا يكن، لابدّ من التصرف حِيال هذه الحالة.

المشكلة الثانية: لا توجد معالجة لمُدخلات غير صحيحة. ما الذي ينبغي أن يحدث لو يتم تمرير سلسلة نصيِّة أو رقم أو كائن، بدلًا من المصفوفة؟

هنا ما ستقوم به الدالة:

خطأ كتابيّ: array.reduce ليس دالّة

حسنًا، هذا مؤسف لأنّ array.reduce بالتأكيد دالّة!

نظرًا لأننا سَمَّيْنَا الوسيط المصفوفة، أي شيء يمرر للدالة (مثل ٤٢ في المثال) تُعلَّم كمصفوفة داخل الدالّة. الخطأ يقول لك ببساطة 42.reduce ليست دالّة.

رأيت كيف أنّ هذا الخطأ مركب، صحيح؟ مثل المشكلة الأولى، هذا يحدث بسبب عدم معالجتنا للحالة المحددة.

ربما ستكون الرسالة أنفع لو صارت: ٤٢ ليس مصفوفة، يا صديقي.

يشار إلى المشكلة الأولى والثانية بأنّها من الحالات المتطرِّفة. هذه بعض الأمثلة الشائعة التي ينبغي التخطيط لها، وهناك بعض الحالات المتطرِّفة أقل وضوحًا ينبغي عليك التفكير فيها أيضًا.

المشكلة الثالثة: عدم اختبار الحالات المتطرفة. بغض النظر عن الحالات الواضحة، الدالّة أعلاه لا تعالج حالات أخرى متطرفة جيدًا. على سبيل المثال: ما الذي يحدث عند استعمال أرقام في السالب؟

حسنًا، -١٣ هو رقم فرديّ. هل هذا السلوك الذي تودّ أن تسلكه الدالة؟ أيجب أن تُرجِع الدّالة خطأً؟ أينبغي تضمين الأرقام السالبة في الجمع؟ أو يجب ببساطة تجاهل الأرقام السالبة مثلما تفعل الدالة حاليًا؟ لربّما ينبغي أن نسمِّي الدّالة جمع الاعداد الفردية الموجبة sumPositiveOddNumbers.

يجب أن تقرر قرارًا حيال هذه الحالة. إذا لم يكن لديك اختبار للحاله يوثِّق قرارك، لربما تترك تعليقًا قصيرًا، تعليق يوضّح لماذا تتصرف الدالة هذا التصرف هنا.

المشكلة الرابعة: عدم اختبار جميع الحالات الصحيحة. اِنس الحالاتِ المتطرفة، هذه الدالة لديها حالة صحيحة وبسيطة لا تُعالجها جيِّدًا:

رقم ٢ أعلاه مضمّنُ في عملية الجمع، بينما لا ينبغي له ذلك.

إذا فاجئك هذا، حاوِل معرفة سبب المشكلة.

الحلّ بسيط، دالة reduce تقبل الوسيط الثّاني لِتُستَخدم كقيمة أوليّة للمُجمِّع (accumulator). إذا لم يُوفَّر هذا الوسيط (كما في الترميز السابق)، فإنّ دالة reduce تستعمل القيمة الأولى في المصفوفة كقيمة أوليّة للمُجمِّع. وهذا يفسر سبب تضمين قيمة العدد الزوجي في الاختبار أعلاه في عملية الجمع.

بالرغم من أنك قد تكون رصدت هذه المشكلة عند كتابة الترميز، إلا أنّ الاختبار الأخير هو الذي كشف ضرورة وأولوية تضمينه بجانب الاختبارات الأخرى مثل قائمة الأرقام الزوجية، وقائمة تحتوي صفرًا، وقائمة فارغة.

إذا رأيت اختباراتٍ قليلة، لا تتعامل مع جميع الحالات المتطرفة أو تتجاهلها، فهذه علامة أخرى على ترميزِ المبتدئ.

١٤. عدم استجواب التّرميز

ما لم تكن مبرمجًا خارِقًا يعمل دائمًا منفردًا، لا شكّ أنّك ستواجه بعض الترميز الغبيّ في حياتك. المبتدئون لن يميزوها وغالبًا ما يتوقّعون أنه جيدٌ ما دام يعمل وهو جزء من البرمجية الأساس لفترةٍ طويلة.

الأسوأ من ذلك أنّه إذا كان الترميز السيء يستعمل ممارسات سيئة، المبتدئ قد يميل إلى تكرار الممارسات السيئة في كل مكان في البرمجية لأنّه تعلّمه من الترميز الذي يعتقد أنّه جيدة.

بعض الترميز يبدو سيئًا لكنّ له حالة خاصة أجبرت المطوِّر كتابته بهذه الطريقة. من الجيِّد هنا التعليق المفصّل لتعليم المبرمج المبتدئين حول الحالة والسبب خلف كتابته بهذه الطريقة.

كمبتدئ، عليك افتراض أن أي ترميز لا تفهمه مرشّح ليكون سيئًا. شُكك فيه واسأل عنه وألقِ اللوم عليه.

إذا كان قد مضى وقتٌ طويل على كتابة الترميز، أو لم تتمكن من تذكّره، فابحث عنه وحاوِل فهم كل شيءٍ فيه.

١٥. هوَس أفضل الممارسات

لفظةُ «أفضل ممارسة» هي في الحقيقة ضارّة. لأنّها تعني أنّه لا حاجة لمزيدٍ من البحث. هنا أفضل ممارسة مطلقًا. لا تشكّ فيها! ليس هناك ممارسة هي الأفضل. ربما هناك ممارسة أفضل لليوم ولهذه اللغة البرمجية.

بعض ما عرَّفناه سابقًا كأفضل ممارسة في البرمجة، صار اليوم يُعلَّم بأنّه ممارسة سيئة.

يمكنك دائمًا الحصول على ممارسة جيدة إذا استثمرت وقتًا كافيًا. لا تهتم بأفضل ممارسة وركِّز على ما تستطيعه بشكل أفضل. أفضل ممارسة صحيحة جيدة في الترميز هي الممارسة العامة. مثال: اكتب ترميزًا بأعلى جودةٍ في استطاعتك.

لا تفعل شيئًا لأنّك قرأت اقتباسًا أو رأيت أحدًا يفعله، أو قال أنّه أفضل ممارسة!

١٦. هوَس الأداء

التحسين السابق لأوانه هو أساسُ كل الشرور (أو على الأقل مُعظمها) في البرمجة.
دونالد كنوث (Donald Knuth) ١٩٧٤

بالرغم من أنّ أن البرمجة اختلفت كثيرًا منذ أن قال دونالد كنوث (Donald Knuth) مقالته، إلا أني أعتقد أنّها لا تظلّ نصيحة قيِّمة حتّى اليوم.

القاعِدة الجيدة التي عليك تذكرها: إذا لم تكن قادرًا على قياسِ المشتبه به في فاعلية الأداء، فلا تحاول تحسين الأداء.

إذا كنت تحسِّن حتّى قبل كتابة الترميز، محتملٌ أنّك تحسن تحسينًا قبل أوانهِ.

أكيدٌ أنّ هناك بعض التحسينات الواضحة التي عليك دائمًا مراعاتها قبل كتابة ترميزٍ جديد. على سبيل المثال، في Node.js من المهمّ جدًا عدمُ إغراق حلقة تكرار الحدث (event loop) أو إعاقة مُكدِّس الاستدعاء (call stack) هذا مثال على التحسين المبكر الذي ينبغي عليك الاحتفاظ به في ذهنك دائمًا. اسأل نفسك: هل الترميز الذي سأكتبه يُعيق مكدِّس الاستدعاء؟

مع ذلك، هناك نوع أكثر شرًا من التحسينات التي ينفذها المبتدئون: تحسينات غير ضرورية.

أي تحسين غير واضِح يُطبق على أي ترميز دون قياسات يعتبرُ ضارًا ولا بد من تفاديه. ما تظنّه مكسبًا للأداء قد يصير مصدر أخطاءٍ جديدة غير متوقّعة.

لا تضيِّع وقتك في تحسين مشاكل الأداء غير المُقاسَه.

١٧. عدم استهداف تجربةِ المستخدم

ماهي أسهل طريقةٍ لإضافة خاصّية جديدة للتطبيق؟ النّظر لها من منظورِك الشخصي، أو كيفية تناسبها في الواجهة الحالية. إذا كانت الخاصية تتطلب نوعًا من مُدخلات المستخدم، إلحاقها بالنّموذج المُعَدّ مسبقًا. إذا كانت الخاصية إضافة رابطٍ للصفحة، إضافتها لقائمة الروابط المتداخلة الموجودة من قبل.

لا تكن ذلك المطوِّر. كن أحد المطوِّرين المحترفين الذين يضعون أنفسهم في محلِّ المستخدِم نفسه. يتخيلون ما الذي يريده في هذه الخاصية وما تصرفهم المحتمل حيالها. إنّهم يفكِّرون في طرقٍ لجعلِ الخاصية سهلة العثور والاستعمال للمستخدم، لا يفكِّرون في أسهل وسيلة لإضافة الخاصية في التطبيق بأي طريقةٍ كانت دون أدنى تفكيرٍ في إمكانية اكتشافها وسهولة استخدامها.

١٨. عدم اختيار الأداة الصحيحة للعمل

كلنا لديهِ قائمة الأدوات المفضلة التي تساعِده في النشاطات البرمجية. بعض الأدوات رائعة وبعضها سيء، لكنّ معظمها رائع لشيء واحِد جزئي وليس كذلك لأشياء أخرى.

المِطرقة أداة رائعة لطرقِ المسمار في الجِدار ولكنّها أسوأ أداة مع البُرغيّ. لا تستعمل المطرقة مع البرغيّ لمجرّد أنّك «تُحبُّها». ولا تستعملها مع البرغيّ لأنّها أكثر شيوعًا على متجر أمازون (Amazon) وتقييمُها ٥.٠.

الاعتماد على أداةٍ لشيوعها بدلًا من مدى ملاءمتها للمشكلة هي علامة مبتدئٍ حقيقي.

أحد مشاكِل هذه النّقطة هي أنّك ربّما لا تعرف الأدوات «الأفضل» لوظيفةٍ معيَّنة. في ظلّ معرِفتِك الحالية، الأداة ربّما تكون أفضل ما تعرِف. مع ذلك، مقارنةً بالخيارات الأخرى، ربما ليست من ضمن أفضل عشرَة. تعرَّف على الأدوات المتاحةِ لك وابق مطّلِعًا على الأدوات الجديدة التي يمكنك استعمالها.

بعض المبرمجين يرفضون الأدوات الجديدة. هم مرتاحون مع الأدوات الموجودة ولا يودّون تعلم الجديدة. أنا أتفهّم ذلك، لكنّه خطأ ببساطة.

يمكنك بناءُ منزلٍ بأدواتٍ بدائية وهذا سيستغرق وقتَك الجميل أو يمكنك استثمار بعض الوقت والمال في أدواتٍ جديدة فائقة لبناءٍ أسرع ومنزلٍ أفضل. الأدوات تتحسن باستمرار وتحتاج لمعرفتها واستعمالها.

١٩. عدم فِهم أنّ مشاكل الترميز ستؤدي لمشاكل البيانات

من الجوانب المهمّة في البرمجة هو إدارة بعض هياكل البيانات. البرنامج سيكون واجهةً لإضافة بيانات جديدة، حذف القديمة، وتعديل بعضها.

حتّى أصغر الأخطاء في البرمجية ستؤدي إلى حالة غير متوقّعة في البيانات التي تديرها. وخصوصًا إذا كانت التحقُقَات (لاختبار صحّة البيانات من عدمها) تُجرَى بنفس البرمجية المُصابة بالخطأ.

المبتدئون قد يربطون النقاط فورًا عندما يكون الترميز متعلَّقًا بالبيانات. لكنّهم قد يشعرون أنّه من العاديّ استعمال الترميز المُعتلّ في الإنتاج ما دام أنّ الجزء المعتلّ ليس مهمًا جدًا. المشكلة هنا أنّ الترميز المعتلّ قد يستمر في إحداث مشاكِل متعلقة بالبيانات تكون غير واضِحة في البِداية.

الأسوأ أنّه عند نشرِ ترميزٍ لإصلاح الخلل، دون إصلاح خلل البيانات الدقيق الذي حصل سابقًا، ستتراكم مشاكل البيانات أكثر وتنتقل إلى حالة «غير قابلٍ للاسترداد».

كيف تحمي نفسك من مشاكل كهذه؟ يمكنك ببساطة استعمال طبقاتٍ متعددة لتحققات سلامةِ البيانات. لا تعتمِد على واجهةِ المستخدِم البسيطة. أنشِئ تحققاتٍ في الواجهة، والخلفية، واتصالات الشبكة، وقواعد البيانات. إذا لم يكن هذا متاحًا، يمكنك على الأقل استعمال قيود على مستوى قواعِد البيانات.

اِعتَد على قيود قواعِد البيانات واستعملها عند إضافة أعمِدة وجداول جديدة:

  • غير فارغ (NOT NULL) قيد على العمود يعني أن القِيَم الفارِغة ستُرفض في العمود. إذا كان تطبيقك يفترض وجود قيمةٍ في الحقل هذا، يجب أن يقيَّد العمود بهذا القيد.
  • فرِيد (UNIQUE) قيد على العمود يعني أنّ العمود لا يمكن أن تتكرر فيه القيَم. على سبيل المثال: نافعٌ لحقل اسمِ المستخدم، والبريد الإلكترونيّ في جدولِ المستخدِمين.
  • تحقّق (CHECK) قيد عبارة يحمل تعبيرًا مخصصًا تُقبل البيانات ما دامت مطابقةً لهُ. على سبيل المثال: إذا كان لديك حقلٌ سيحمِل نسبةً مئوية فستكون قيَمُه بين 0 و100، فيمكنك استعمال هذا القيد للتحقق.
  • مفتاح رئيسي (PRIMARY KEY) قيد يعني أن الحقل غير فارغ وفريد كذلك. محتملٌ أنّك تستعمله. كلّ جدول في قواعد البيانات يجب أن يحمل مفتاحًا رئيسيًا لتعرِيف سجلّاته.
  • مفتاح خارجيّ (FOREIGN KEY) قيد يعني أن قيَم العمود يجب أن تُطابق قيمةَ عمود جدولٍ آخر، والذي هو غالبًا مفتاح رئيسي.

أحد المشاكل الأخرى للمبتدئين المتعلقة بسلامةِ البيانات: نقص التفكير من ناحية المعاملات. إذا كانت هناك عدّة عمليّات تحتاج لتعديل نفسِ البيانات وتعتمِدُ على بعضها، يجب أن تُضمَّن في معاملاتٍ قابلة للاستعادة عِند فشِل إحداها.

٢٠. إعادة اختراع العجلة

هذه نقطة صعبة. في البرمجة: بعض العجلات تستحق ببساطة إعادة الاختراع. البرمجة ليست نطاقًا مُعرّفا بدقة. كثيرٌ من الأمور تتغير بسرعة والمتطلبات الجديدة تُقدم بسرعة لا يستطيع أي فريقٍ مجاراتها.

على سبيل المثال: إذا كنت تريد عجلةً تدور بسرعات متفاوتة وِفقا للوقت، بدلًا من تعديل العجلة المعروفة المحبوبة، ربّما علينا إعادة التفكير فيها.

مع ذلك، ما لم تحتَج إلى عجلةٍ غيرِ المعرُوفة، لا تخترع. استعمل الموجودة.

لا تضيِّع وقتك الثمني باحثًا عن العجلةِ الأفضل. ابحث بإختصار واستعمل التي وجدتها. استبدل العجلات فقط عندما تجد بوضوح أنّها لا تؤدي الأداء المطلوب.

الجميل في البرمجة أن أغلب العجلات مجانية ومفتوحة لك لترى تصميمها الداخليّ. يمكنك بسهولة تقييمُ جودة الشِّفرة الداخلية.

إذا استطعت، استعمل عجلات مفتوحة المصدر! الحِزم مفتوحة المصدر هذه يمكنك اختبارها وإصلاحها بسهولة. وقابلة للاستبدال كذلك بسهولة. وإضافة إلى ذلك، يمكنك دعمها من المنزل.

وكذلك: إذا كنت تريد عجلة، فلا تشتري سيارةً جديدة وتضع فوقها السيارة الحالية. لا تُضمِّن كامِل المكتبة لاستعمال دالَّةٍ (وظيفة) واحدة أو اثنتين!

أفضل مثالٍ على ذلك مكتبةُ لوداش (lodash) في جافاسكربت (JavaScript). إذا كنت تريد فقط خلط المصفوفة، استورِد دالَّة الخلطِ فقط. لا تستورِد المكتبة بأكملها.

٢١. اتخاذ موقفٍ خاطئ تجاهِ مراجعة الترميز

أحد علامات مبتدئيِّ البرمجة هو أنّهم ينظرون لمراجعات الترميز كنَقد. وهم لا يحبونها، ولا يُقدِّرونها، حتّى أنّهم يخشَونَها.

هذا خطأ. إذا كنت تشعر بهذا فأنت بحاجةٍ لتغيير موقِفك فورًا. انظر لكل مراجعةٍ على أنّها فرصةٌ للتعلم. رحِّب بها وقدِّرها وتعلم منها. والأكثر أهميةً، اشكُر المراجعين كلما علموك شيئًا.

أنت مُتعلِّم في البرمجة باستمرار. عليك تقبّل هذا. أغلب مراجعات التّرميز ستعلِّمك شيئًا. صنّفها كمصدرٍ للتعلم.

أحيانًا، يكون المراجِع مخطئًا ويكون دورَك لتعليمه شيئًا. مع ذلك، فإنّه إن لم يكن واضِحًا بسبب ترميزِك، إذن ربّما تحتاج لتعديل ترميزك. وإذا علمتَ المراجع أي شيء، اِعلم أنّ التعليم هذا أحد أكثر الأنشطة المجزية التي يمكنك فعلها كمبرمج. انظر إليّ! لقد كرّست أكثر من نصف وقتي للتعليم. هل تظنّ أني أعلِّم فقط من أجلِ المال؟

٢٢. عدم استعمال مُدير الترميز

أحيانًا، يقلل المبتدئون من قوة نظام إدارة المصدرِ / المراجعة الجيِّد (source/revision control system)، وأعني بالجيِّد هنا Git.

إدارة المصدر ليس فقط دفعُ التغييرات للآخرين ليَبنُوا بِها. إنّهُ أكبر من ذلك.

إدارة المصدر هي تارخ واضِح. الترميز سيكون مستجوَبًا وتاريخ التقدُّم للترميز سيساعد على إجابة بعض الأسئلة الصعبة. ولهذا نحن نعتني برسائل التسليم (commit). إنّها قناة أخرى لإيصال تنفيذِك وتطبيقك واستعمالها مع تسليماتٍ صغيرة تساعِد عامليّ الصيانة في المستقبل على معرفةِ كيفية وصول البرمجية لما هي عليهِ الآن.

سلِّم كثيرًا، وسلِّم مبكّرًا ولمحبّة الثبات استعمل المضارع في عناوين التسليم. كن تفصيليًا في الرسالة لكنّ ضع في الحسبان جعلها ملخصّة. إذا احتجت أكثر من بضعة أسطر في الرسالة، فهناك احتمال أن تكون الرسالة طويلة. أعدِها.

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

إدارة المصدر هو أيضا كشّاف. إذا وجدت دالَة، وتساءلت عن حاجتها وتصميمها، يمكنك العثور على الجواب بسهولة في عملية التسليم التي قدّمت الدالة، ورؤية سياقها. التسليماتُ يمكنها مساعدتك في تحديد الترميز المسبب للمشكلة في التطبيق. Git يوفِّر لك بحثًا ثنائيًا مع التسليمات لتحديد مكانِ التسليم الخاطئ الذي سبب الخطأ.

إدارة المصدر يمكِّن من التّحكم بطرقٍ رائعة حتى قبل جعل التغييرات تسليمًا رسميًا. استعمال ميزات كالتغيير المرحليّ (staging changes)، الترقيع الانتقائي (patching selectively)، إعادة الضبط (resetting)، التّخبئة (stashing)، التعديل (amending)، التطبيق (applying)، المقارنة (diffing)، الاستعادة (reversing)، وعددٌ من الأدوات الأخرى التي تُغنِي تدفّق وسير تطبيقك. افهمها وتعلمها واستعملها وقدِّرها.

كلما كنت أقل معرفةً بميزات Git، اعتبرتك مبتدئًا في كتابي.

٢٣. فرطُ استخدام القِيم المشتركة

هذه مجددًا ليست نقطةً عن البرمجة الدالّية مقابل النماذج الأخرى. هذا موضوع لكتاب آخر.

هذه معلومة أنّ القيمة المشتركة هي مصدر للمشاكل ويجب تجنبها ما أمكن. إن كان لا بدّ، فاستعمالها ينبغي أن يكون أقلّ ما يُمكن.

ما لا يدركه المبتدئون هو أنّ كل متغير تُعرِّفه يمثّل قيمةً مشتركة. إنّه يحمل قيمةً يمكن لجميع العناصر في نطاقِه تغييرها. كلما كان النطاق أوسَع كان أسوأ. حاوِل جعل القيم المشتركة في نطاقاتٍ ضيقة وتأكّد أنّها لا تتسرب لنطاقٍ أعلى.

المشكلة الكبيرة تحدث في القيم المشتركة عندما تحتاج عدّة أطراف إلى تعديلها معًا في نفس الجزئية (في البيئات المُعتمِدة على حلقة تكرار الحَدث event-loop-based environments)

سيُحدِث ذلك حالة التَّهَافُتْ (Race condition).

والمشكلة أنّ المبتدئ قد يميل إلى استخدام مؤقِّتٍ كحل بديل لمشكلة التّهافُتْ، خصوصًا عندما يكون عليهم التّعامل مع مشكلة قُفل البيانات (data lock). هنا إشارة خطر. لا تفعلها. راقبها وعلِّم عليهَا أثناء مراجعات التّرميز، ولا تقبل بها أبدًا.

٢٤. اِتخاذ موقفٍ خاطئ تجاه الأخطاء

الأخطاء جيِّدة. إنّها تعنِي أنّك تتقدَّم، ولديك تغييرات متتابعة سهلة للتقدُّم أكثر.

المبرمجون الخبراء يحبونها. المبتدئون يكرهونها.

إذا كانت الرسائل الحمراء الصغيرة تُزعِجك، فأنت بحاجةٍ لتغييرِ هذا الموقِف. تحتاجُ للنظر إليها كمُساعِدات، وللتعامل معها، والاستفادة منها للتقدُّم.

بعض الأخطاء تحتاج التّرقية إلى استثناءات. الاستثناءات هي أخطاءٌ مُعرَّفة منك ينبغي عليك التخطيط لها. بعض الأخطاء تُترَك لوحِدها. وبعض الأخطاء ينبغي أن تُعطِّل التطبيق وتُوقِفه.

٢٥. عدم الاستراحة

أنت إنسان وعقلك يحتاج للاستراحة، جسمك يحتاج للاستراحة. غالبا ستكون في عملٍ وتنسى الاستراحةٍ. وأراها علامة أخرى عند المبتدئين. الاستراحة غيرُ قابلةٍ للنقاش. أضف شيئا مّا في سير عملك يُلزمك على الاِستراحات. استرِح عدة استراحاتٍ قصيرة. غادر مقعدك وتجول قليلا وفكر فيما ستفعله. عُد للبرمجة بنظرةٍ جديدة.

كانت هذه قراءة طويلة، تستحقُّ الآن استراحة.

اترك تعليقاً

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *