اذهب إلى المحتوى

السؤال

Recommended Posts

  • 0
نشر

هو الكود الذي يتم برمجته بشكل منطقي ويمكن فهمه من قبل كاتبه و مبرمجين آخرين من بعده ويسهل استخدامه والتعامل معه.

ما يجب عليك فعله حتى يكون الكود نظيف: 

  • حاول جعل أسماء الملفات والمجلدات ذات أسماء لها علاقة بمحتوها 
  • عند إنشاء Classes اجعل اسمه منطقياً 
  • لا تكرر من أسماء  الدوال function أو إضافة رموز وحروف ليس لها معنى في الاسم 
  • حاول جعل أسماء المتغيرات Variables منطقية 
  • قم بتقسم الكود إلى أجزاء 
  • اهتم بالأسطر والفراغات وابتعد عن كتابة كود طويل بنفس السطر
  • حاول التقليل من استعلامات قواعد البيانات
  • قم بترك ملاحظاتك داخل الكود تخبرك لماذا تمت كتابة هذا للكود
  • 0
نشر

الكود النظيف clean code بإختصار هو الشفرة البرمجية السهل قرائتها والتعديل عليها, ولها عدد من الخصائص يمكن كتابتها على الشكل الأتي

  1. من السهل عند قرائته أن تفهم كيف يتم تنفيذه بشكل واضح
  2. من السهل أن تفهم عﻻقة الكائنات ببعضها البعض, فإذا كان لديناclass يسمى user و اخر يسمى bookفمن السهل معرفة ما العﻻقة بين المستخدم والكتاب
  3. من السهل معرفة وظيفة كل class وكل دالة, حيث يتم تقسيم الدوال والclasses بحيث يكون لكل فرد منهم وظيفة محدد ﻻ أكثر
  4. من السهل معرفة غرض كل متغير وكل سطر في الشيفرة البرمجية فﻻ يكون لديك متغيرات بأسامي مبهمة أو في مواضع عشوائية تصعب عملية الفهم على من يقرأ الشفرة
  5. الدوال تكون صغيرة ولكل class او دالة مسؤلية فﻻ يمكن أن تكون دالة مسؤلة عن الجمع وطباعة الناتج في نفس الوقت, بل تقسيمها إلى دالتين , واحدة للجمع والأخرى من أجل الطباعة
  6. وجود توثيق للدوال والclasses للرجوع إليه وقت الحاجة ليسهل الفهم
  7. يمكن توقع سلوك الدوال والclasses بسهولة
  8. سهل التعديل عليه

 

  • 2
نشر

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

اقتباس

عملية جعل الكود قابلة للفهم و التعديل

و لنأخذ المفهوم بشكل أعمق كالتالي : 

سهولة الفهم تعني سهولة قراءة الكود ، سواء كان ذلك القارئ هو المؤلف الأصلي للكود أو أي شخص آخر . لذا فهو يقلل من الحاجة إلى التخمين وإمكانية حدوث سوء فهم . من السهل أن نفهمه على كل المستويات ، وعلى وجه التحديد : 

  •  منطق العمل للتطبيق بأكمله .
  • كيفية تعاون الكائنات و الأصناف المختلفة مع بعضها البعض .
  • دور ومسؤولية كل فئة و كائن .
  • ما تفعله كل دالة و تابع . 
  • الغرض من كل تعبير يتم تعريفه , سواء متغير , ثابت أو خاصية .  

أما سهولة التعديل تعني أن الشيفرة سهلة التوسيع , التطوير وإعادة البناء . كما أنه من السهل إصلاح و تشخيص الأخطاء فيها , و نفس الأمر ينطبق أيضا : سواء كان ذلك القارئ هو المؤلف الأصلي للكود أو أي شخص آخر . و يشمل ذلك النقاط : 

  • الكائنات و التوابع صغيرة الحجم ولا تتحمل سوى مسؤولية واحدة (و ذلك احتراما لمبدأ فصل المهام ) .
  • تتوفر الكائنات على واجهات برمجية عامة واضحة و موجزة .
  • يمكن التنبؤ بكبفية عمل الكائنات و توابعها .
  • الكود قابل للاختبار بسهولة ولديه اختبارات وحدة (أو على الأقل من السهل كتابة الاختبارات) .
  • الاختبارات - إن توفرت- فهي سهلة الفهم والتغيير بسهولة . 

و لكن لما نحتاج الإهتمام أصلا بالكود النظيف ؟ 

لنقم بتلخيص أهمية الأمر في النقاط التالية : 

  • يجب أن تهتم لأن الشفرة (في الغالب ) لا تتم كتابتها مرة واحدة و فقط . و إنما في معظم الأوقات ، تحتاج أنت أو أي شخص آخر إلى العمل على الكود. ولكي تكون قادرًا على العمل عليه بكفاءة ، فأنت بحاجة إلى فهمه بالدرجة الأولى . 
  • مبادئ كتابة كود نظيف تمنحك الثقة أثناء كتابة شيفرتك . 
  • تكون الأخطاء أسهل للتشخيص و الحل . 
  • تجعل الكود سهل للصيانة و التطوير .

و قد يتعلق مفهوم الكود النظيف بكثير من المفاهيم الأخرى , من مثل أنماط التصميم و مبادئه و غيرها . و لذلك قد تجد بعضهم يستعير بعض مبادئ تصميم البرمجيات ليستعملها كمبادئ للكود النظيف , من مثل مجموعة مبادئ SOLID (سنأتي لإرفاق سلسلة مقالات تخص كل مبدأ) أو DRY (اختصارا لترجمة لا تكرر نفسك Don't Repeat Yourself ) أو YAGNI (اختصارا لترجمة أنت لن تحتاجها You Aren't Gonna Need It) أو غيرها من المبادئ . و لذلك فهي عملية متشعبة جدا . 

و لعل الكود النظيف هو ما يصنع الفارق بين مبرمجي نفس اللغة و نفس إطار العمل , فإن كنت لا توليه أهمية أو أولوية فسيجب عليك ذلك . لأنك لن تلتفت إليه بداية كونك بكامل تركيزك وإستيعابك للكود, و لكنك ستجد نفسك في حاجة إليه عندما تبتعد قليلا عن تطوير تطبيقك ثم تقرر العودة إليه . و أتذكر جيدا إضطرار أحد فرق التطوير لنسف الكود بأكمله (الذي كان بحجم 400 ميغا) و إعادته لمجرد أن مطوريه نفسهم عجزوا عن فهمه بعد أقل من سنة من إنطلاقه . 

يمكنك التعرف أكثر على مبادئ SOLID لتصميم البرمجيات في سلسلة المقالات التالية :

S 

O

L

I

D

تعرف أكثر على الشيفرة النظيفة هنا و هنا

كما يمكنك التعرف أكثر على مفهوم الكود النظيف في HTML , CSS و Sass هنا

 

  • 1
نشر (معدل)

بداية أود أن ألفت الانتباه إلى الكتاب "Clean Code: A Handbook of agile software craftsmanship"  فهو المصدر لأغلب ماسنتناوله الآن: الكود الرديء يعني حرفياً خسارة آلاف الزوار والمغامرة بحركة البيع والشراء والإيرادات وحتى في مسيرة تطور الموقع الإلكتروني والشركة ككل. لهذا لا تقبل الشركات الكبيرة التعامل مع المبتدئين، لأنها تعرف أن التأخير الزمني في فتح صفحة الويب، ليس لثوان معدودة بل لأجزاء من الثانية، تعني خسارة زبون، وخسارة زبون واحد تعني خسارة آلاف الزبائن المحتملين وفق التسلسل الهرمي، وهذا يعني خسارة نسبية في الأرباح السنوية تصل إلى آلاف الدولارات، لذا عليك كتابة أكواد برمجية مفهومة للجميع دون الحاجة إلى تقديم التوضيحات والشروحات لأحد الزملاء إلّا فيما ندر. وليس هذا فحسب حيث تفكر الشركات لأبعد من هذا بكثير، فمن الممكن أن تترك أنت مهمة ما في منتصفها ويتولاها آخر بشكل مفاجئ، ومن الممكن أن تتولى أنت مهمة شخص آخر في العمل، أو أن تترك العمل في تلك الشركة بلا عودة، وهنا نفهم من هذا السيناريو أن الأكواد المبهمة والغامضة مرفوضةٌ تماماً في بيئة العمل حتى يتسنّى لباقي المطوّرين العمل على تطوير المشروع ومتابعة العمل بسلاسة دون الحاجة لساعات من البحث والعمل على فك الشيفرة. لا يقتصر الأمر على الإيضاح فحسب، وإنما على طريقة الكتابة، واستخدام أحدث الأساليب في لغة البرمجة التي تعمل عليها، أو على الأقل الاتفاق بين رفقاء العمل على التعليمات البرمجية التي توافق مجال العمل، لا يمكنك على سبيل المثال كتابة كود برمجي بـ 10 أسطر ويمكنك كتابته بـ 5 أو بـ 8 حتى وذلك باستخدام تعليمات أحدث أو أفضل. يمكننا سرد بعض الخصائص العامة للأكواد النظيفة وتلخيصها بالنقاط التالية: 1.عدد متغيرات أقل ما يمكن ولا يختلف اثنان على ضرورة تخفيض عدد المتغيرات والدوال والـ classes… إلخ، للوصول إلى كود أسهل وذي أفكار أبسط. 2. عدم التكرار
وهذا شيء معروف عند الجميع، علينا أن نلغي كل الأسطر المتفرقة التي تؤدي نفس المهمة، ونحاول جمعها في سطر واحد أو في دالة واحدة نستدعيها عند اللزوم. 3. اجتياز كافة الاختبارات: هناك بيئات عمل معروفة أو ما تسمى Test-driven development TDD لاختبار الأكواد البرمجية، وهي عبارة عن أكواد برمجية عادية تقوم بفحص الكود البرمجي والهدف منها هو وضع معايير عامة للمشروع. 4. وضوح الهدف والبساطة: يجب أن تكون مهمة كل دالة واضحة، وألا تتشعب فيها المهام لأداء كثير من الأفكار فإن كانت دالة ما لها وظيفة عداد على سبيل المثال، فلا يجب تضمين مهام أخرى فيها حتى لو كانت الأمور تسير بدون أخطاء وهذا ينطبق على الكود ككل. 5.المحافظة على السياق: إذا كتبت دالة ما باستخدام طريقة ما، وكان عليك كتابة دالة مشابهة ولكن لغرض آخر، فاستخدم نفس الطريقة التي استخدمتها في الدالة الأولى.
إن كنت ترغب بكتابة كود نظيف Clean Code التزم الخطوات التالية: 1. اجعل الأسماء ذات معنى: يجب أن تكون أسماء المتغيرات والدوال وكل شيء في الكود البرمجي يشير إلى عمله، فالمتغير الذي يعبر عن سيارة يجب أن يكون اسمه car وليس x، وإن كنت تريد إنشاء دالة تقوم بالعد فسمها count وليس c مثلاً. 2. لا تستخدم الاختصارات: وكما قلنا عن وجوب استخدام الأسماء المعبرة، فبالتأكيد يجب عدم استخدام الاختصارات، يجب أن يكون الكود مقروء للجميع، فمتغير اسمه name لا يجب أن يُختصر إلى nm، ومتغير اسمه lastName لا يجب أن يُختصر إلى ln.
3.اختر الأسماء البسيطة: هذا الأمر بديهي، إلا أنك قد تشعر بالحيرة بعض الأحيان عند تسمية بعض الدوال، وستتخلص من هذه الحيرة إذا اتبعت قاعدة المَهمّة الواحدة للدالة .
لا تستخدم مهاراتك اللغوية في كتابة الأسماء، فدالة وظيفتها الحذف يمكن تسميتها بكل بساطة delete وليس kill.
4. طريقة التسمية: اختر صيغة الفعل لتسمية الدوال أي بدلاً من taxCalculator قم بتسميتها calculateTax، أما فيما يتعلّق بتسمية classes فعلى العكس أي استخدم معها صيغة الوصف أو الاسم بدلاً من الفعل. 5.كما لا تنس القواعد المعروفة باستخدام أسلوب camelCase في التسمية المركبة والتي تبدأ فيها أول كلمة بحرف صغير والكلمة الثانية بحرف كبير وذلك لسهولة القراءة. كما يجب أن تبدأ التسمية بحرف صغير للدوال والمتغيرات بشكل عام، أما classes فيجب أن تبدأ بحرف كبير. 5.التعليقات: ومع أني أحب كتابة التعليقات، إلا أن قواعد الكود النظيف تقول أنه يجب أن يشرح نفسه بنفسه وهو لا يحتاج إلى التعليقات مطلقاً! بل وعلى العكس لو كان الكود مفهوماً فما احتاج إلى تعليقات بالأصل! طبعاً باستثناء التعليقات حول حقوق التأليف والاستخدام أو التعريف بالبرنامج ككل.6.الدوال: حاول أن تتصف الدوال بالصفات التالية: ذات حجم صغير. حاول أن لا يكون طول الدالة أكثر من 10 أو 15 أو 20 سطراً هذه أمثلة عليك جعلها أقصر ما يمكن. ذات اسم معبر عن مهمتها. 7. عدد الـ arguments أقل ما يمكن. ثلاثة على الأكثر، وإلا عليك التفكير بكتابتها على شكل class. لها مهمة واحدة محدد. حاول أن يكون للدالة مهمة واحدة حتى يستطيع الأصدقاء فهم ما يحصل. 8. اجعل الأسطر قصيرة قدر الإمكان ولا تجعل القارئ مضطراً لتمرير النافذة أفقياً ليقرأ سطراً طويلاً. .9. في الحقيقة الموضوع يطول ويطول وتبقى الخطوات السابقة جزءاً من كم لا بأس به من القواعد العامة لكتابة الكود النظيف، ربما ستتعلمها بشكل عملي من المجتمع الخاص بلغة البرمجة التي تعمل بها ولكن كبداية يمكنك الاستعانة بكتاب Clean Code: A Handbook of agile software craftsmanship الذي يعتبر أحد أبرز الكتب في هذا المجال.

تم التعديل في بواسطة Ali Haidar Ahmad

انضم إلى النقاش

يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.

زائر
أجب على هذا السؤال...

×   لقد أضفت محتوى بخط أو تنسيق مختلف.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   جرى استعادة المحتوى السابق..   امسح المحرر

×   You cannot paste images directly. Upload or insert images from URL.

  • إعلانات

  • تابعنا على



×
×
  • أضف...