في هذه الصفحة
ربما لم تقرأ كتاب “Clean Code” أو قرأت جزءًا صغيرًا من صفحاته التي تتعدى ال400 ولكن بالتأكيد سمعت عنه!
اشتهر هذا الكتاب في أوساط صانعي البرمجيات لسببين مهمين:
- يعطي نصائح بسيطة وعملية جدًا
- الكل يعاني مع الأكواد السيئة سواء كتبها الآخرون أو كتبتها أنت في مشاريعك القديمة!
والسبب في كتابتنا لأكواد سيئة هو أننا نعتقد أننا نكتب الاكواد لتفهمها الآلات وتُنفذها لا لكي يفهمها البشر!
والواقع أنه مهما كانت أكوادك ذكية ومناسبة فإنك ستحتاج لتعديلها في وقت ما أو أن يٌعدلها غيرك , ومع كود مكتوب بطريقة سيئة وفوضوية هذه العملية تصبح مكلفة جدًا للوقت والعقل.
وهنا تأتي نصائح كتاب Clean Code لترسيخ مبدأ “الوقاية خيرُ من العلاج”, وننصح بعد قراءة هذه النصائح أن تختار واحدًا لكل يوم وتقوم بتطبيقه في عملك اليومي أو مشاريعك الجانبية كي تصبح مهارة عملية تقوم بتطبيقها بشكل تلقائي في كل مشاريعك.
اختر أسماء مٌعبرة وذات معنى
يجب أن تكون أكوادك مقروءة، فعندما تقوم بتعريف أي شيء في البرنامج أعطه اسمًا يٌعبر عنه أو عن وظيفته وابتعد عن الأسماء المبهمة التي لا توضح ماهية ما تشير إليه مثل “x = 5”. يجب عليك ان تستطيع قراءة سطور برنامجك كما تقرأ الجريدة “سطور مقروءة ومنطقية”
تبدو نصيحة تافهة, أليس كذلك؟
في الواقع إنها من أهم وأكثر النصائح فاعلية والتي ستستخدمها طوال حياتك البرمجية, وتطبيقها ليس بهذه السهولة فستأخذ منك وقتًا حتي تستطيع اختيار الأسماء المناسبة للأجزاء المختلفة من الكود. ولكن عندما يكبر حجم برنامجك التي تطوره وتجد نفسك تنتقل بسهولة بين سطوره وتشرحها لغيرك بسلاسة تتيقن أن النتيجة استحقت المجهود.
ففي المثال الموضح بالصورة ادناه, كلا قطعتي الكود تنفذ المهمة ذاتها ولكنك إذا قرأت التي علي اليسار سيكون من الصعب جدًا أن تفهم أن هذا الكود يجمع أسعار القطع التي طلبها العميل, بينما يكاد يكون تلقائيًا استنتاجك لهذه المعلومة من الصورة الثانية
اكتب أكوادك بمبدأ “قل ودّل”
هذا المبدأ مهم في الأكواد بشكل عام لأكثر من اعتبار, ولكنه بالغ الأهمية حينما تكتب Functions وذلك لأن هذه القطعة البرمجية يتم مُنادتها في أماكن كثيرة متفرقة من برنامجك وإذا قمت بحشوها بسطور كثيرة وأردت تعديلها في وقت لاحق فلك أن تتخيل المعاناة!
ولهذا فالكاتب يضع معيارين مهمين لكتابة ال Functions:
- متوسط طولها لا يزيد عن 10 سطور وأطولها لا يزيد عن 20 سطرًا.
- يجب أن تستقبل أقل عدد ممكن من المتغيرات الخارجية.
بهذا تضمن انها تقوم بمهمة واحدة فقط وتقلل احتمالات تغييرك لها في المستقبل سواء في مهمتها أو في المتغيرات التي تستقبلها.
ونستفيد بهذه النصيحة أيضًا في تعريفنا للـ Classes فكذلك يجب أن يقوم الـ Class بمهمة واحدة فقط وأن لا يحتوي علي Functions طويلة أو لا تخدم هدفه الرئيسي.
اجعل أكوادك تشرح نفسها بنفسها
لم نكتشف صوتُا للأكواد الي الآن ولكننا بالتأكيد نعلم أن هناك أكواد تشرح نفسها بنفسها!
ولا هذه الاكواد ليست محملة بأطنان من التعليقات تشرح كل جزئية منها.
في الواقع إذا وجدت نفسك تكتب تعليقات كثيرة حول سطورك البرمجية فأنت غالبًا تٌبرمج بشكل خاطئ. توقف وعالج هذه المشكلة فورًا لأن كتابة التعليقات لها الكثير من العيوب:
- هي دليل على سوء تسمية المتغيرات وال Functions فالأفضل مسحها واختيار أسماء مٌعبرة.
- تٌصبح قديمة ومٌضللة مع الوقت لأننا ننسى تحديثها مع تحديثنا للكود التي تشرحه.
وعلى نفس مثالنا السابق فإن المبرمج إذا أراد أن يتذكر ما الذي ينفذه هذا الكود سيقوم بكتابة تعليق طويل فوق الـ Function وهذا يزيد الطين بلة, بينما علي اليمين تجد أن المبرمج الجيد جعل الكود مٌعبر عن نفسه بدون الحاجة لتعليق.
اجعل أكوادك جميلة
وهذه ليست نكتة بل إن جمال الكود من الأساسيات لا الكماليات, فلماذا هذا؟
ج: لأن تنسيق سطور الكود على نهج واحد يجعلها سلسة في القراءة ومن ثم في التعديل والصيانة.
فعلى سبيل المثال Facebook مُكون من 62 مليون سطرًا من الكود, إن لم يكونوا مُنظمين ومٌنسقين على نفس النهج فهذه فوضى لا يمكن احتوائها!
وبالرغم انه الموقع انطلق منذ عام 2004 إلا إنه وحتى الآن يتم التعديل فيه بشكل مستمر. فالشاهد هنا أنه من الضروري أن يكون الكود مٌنسق على نهج واحد بغض النظر عن مدى كبره أو عدد المطورين الذين يعملون عليه.
ويُنصح باستخدام أي Linter -مٌنسق- لمشاريعك وهي عبارة عن Packages تُحدد لها قواعد معينة للتنسيق وهي تقوم بلفت نظرك عندما تغفل عنها أو تٌعدلها بنفسها لك.
ومن قواعد التنسيق المهمة:
- تحديد طول معين للسطور, ويفضل بقاءها قصيرة.
- تحديد طول ثابت للمسافات الفارغة بين الكلمات وبين الأجزاء المختلفة من الكود.
- اختيار نهج تسمية واحد لكل البرنامج مثل camelCase, PascalCase, or snake_case.
عالج الأخطاء بطريقة فعالة
مهما كانت أكوادك ذكية فهي حتمًا ستفشل في سيناريو ما, ولذلك معالجة الأخطاء أو ما يٌعرف بالـ “Error Handling” جزء لا يتجزأ من حياتنا اليوم كمبرمجين, لا نكتب سطورًا تقوم بمهمة ما إلا وكتبنا معها سطورًا أخرى تعالج احتمالات فشل الأولى.
وكي تعالج الأخطاء بفعالية احرص على الآتي:
- عّرف Exceptional Classes ذات معنى وتوفر معلومات كافية عن الخطأ كي تستطيع معرفة سببه الحقيقي ومعالجته.
- اجعل رسائل التنبيه عن الخطأ مٌعبرة وتحمل معلومات مفيدة ولا تنسى أن تكتبها في الLog الخاص بالبرنامج.
- استخدم استراتيجية محددة ومتناسقة خلال البرنامج كله في معالجة الأخطاء فلا تعالج خطأ 404 مرة بطريقة ما وفي مكان آخر بطريقة أخرى.
- اختبر كل السيناريوهات التي تستحث كود معالجة الخطأ الخاص بك للتأكد من إنه يعمل بالطريقة الصحيحة.
البرمجة حرفة أو صنعة
في النهاية البرمجة حرفة أو صنعة كما نوه الكاتب في بداية الكتاب, ولذلك جزء كبير من إتقانها يكمن في ممارستها ومحاولات تحسينك لما تٌنتج وتتطور من أكواد. كما ننصح دومًا بأن تطلب مراجعات لأكوادك من زملائك الأكثر خبرة وتستخدم هذه المراجعات لتفادى أخطائك في المشاريع الأخرى.
في هذا المقال حاولنا ان نعرض عليك الأساسيات بشكل مُختصر وبالتأكيد لا يٌغني عن قرائتك للكتاب ولكن نعتبره تحفيزًا لك على ممارسة هذه النصائح ويمكنك الرجوع للكتاب لتٌحسن من طريقة تطبيقها أو لتعميق فهمك لها.
