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

1. وثّقوا الكود دائمًا

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

type <em>ParserOptionType</em> = {
   /**
    * Capitalized your attribute name.
    * @example
    * ```
    * const data = parser("{ 'name': 'Hello World' }", { useCapitalize: true });
    * console.log(data); // { 'Name': 'Hello World' }
    * ```
    */
   useCapitalize?: <em>boolean</em>;

   /**
    * Using UTC Date String if specified as True, otherwise showing the timezone.
    * @example
    * ```
    * const data = parser("{ 'dob': '2022-01-31' }", { showJSONDate: true });
    * console.log(data); // { 'dob': '2022-01-31T00:00:00.000Z' }
    * 
    * const data = parser("{ 'dob': '2022-01-31' }", { showJSONDate: false });
    * console.log(data); // { 'dob': '2022-01-31T00:00:00.000+0700' }
    * ```
    */
   useUTCDate?: <em>boolean</em>;
}

/**
* Parse the JSON Object from the plain text.
* @params text The text that you want to parse.
* @params options Additional options for customize your returned object.
* @returns The parsed JSON object from the provided options.

*/
function parser(<em>text</em>: <em>string</em>, <em>options</em>: <em>ParserOptionType</em>) {
    return <em>Object</em>.assign({});
}

حين يمرّر مطوّرون آخرون المعامل options، سيفهمون طريقة استخدامه بسهولة بمجرد تمرير مؤشر الفأرة فوق المعامل الذي يريدونه. وكما ترون، يصبح استخدام الدالة أسهل بكثير على زملائكم. وإذا لم تكونوا على دراية بـ JSDoc، يمكنكم الاطلاع عليه من هنا.

2. اكتبوا كودًا نظيفًا والتزموا بأفضل الممارسات

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

[language] best practices github

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

3. تجنّبوا الكود المهجور (deprecated) والقديم قدر الإمكان

حين تبتعدون عن الكود القديم أو المهجور، فإنكم تُظهرون أنكم تواكبون آخر المستجدات في مجتمع JavaScript. كما يمكنكم شرح كود زملائكم أو مراجعته إذا كنتم تعرفون أي الأكواد أو الدوال أصبحت مهجورة.

4. تعاملوا مع الأخطاء دائمًا

لا أحد يفخر بكود يصل إلى بيئة الإنتاج (production) ثم ينهار. وأسوأ سيناريو أن يكتشف المستخدمون الأخطاء قبلكم، وهذا يحدث كل يوم. وكلما قلّت الأخطاء التي تصل إلى بيئة الإنتاج، زادت ثقة الآخرين بكم كمطوّرين.

5. اجمعوا كل المتطلبات أو اسألوا قبل البدء

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

6. التزموا بأسلوب كتابة موحّد

ليكون المطوّر عضوًا جيدًا في الفريق، ينبغي أن تكون هناك قواعد أو سياسات لكتابة الكود بأسلوب موحّد، تمنع التعارضات وتحسّن قابلية قراءة قاعدة الكود. فالأمر أسهل حين يكتب الجميع بالأسلوب نفسه. وسيلاحظ الجميع بسهولة أي "رائحة كود" (code smell) غريبة إذا لم يلتزم أحدهم بالأسلوب المتفق عليه. وهذا يسهّل عملية مراجعة الكود. والطريقة الأكثر عملية هي دمج أداة Linter في المشروع. ويمكنكم ضبط القواعد أو التحذيرات وفق ما اتفقتم عليه مع فريقكم.

الخلاصة

البرمجة تشبه الفن، فقد تكون تحفة فنية أو لوحة قبيحة بحسب الفنان الذي رسمها. فلماذا لا تمنحون من يقرأ كودكم تجربة ممتعة؟ في OOZOU نواكب المستجدات ونساعد بعضنا في مراجعة الكود. ولدينا مجتمع رائع يتشارك أفضل الممارسات والنصائح والحيل عبر مشاريع متعددة كل شهر!