أهم النقاط
1. الشيفرة النظيفة يجب أن تكون قابلة للقراءة، بسيطة، ومعبرة
الشيفرة النظيفة تبدو دائمًا كما لو كتبها شخص يهتم حقًا.
الوضوح هو الأساس. تتميز الشيفرة النظيفة بسهولة قراءتها وبساطتها. يجب أن يكون من السهل على المبرمجين الآخرين فهمها، تعديلها، وصيانتها. ويتطلب ذلك استخدام أسماء واضحة وذات معنى، والحفاظ على صغر حجم الدوال والفئات وتركيزها، وتنظيم الشيفرة بطريقة منطقية.
الشيفرة المعبرة تنقل النية بوضوح. يجب أن تعبر الشيفرة النظيفة عن نية المبرمج بوضوح دون الحاجة لتعليقات مطولة. يتحقق ذلك من خلال اختيار أسماء مناسبة، ودوال صغيرة تقوم بمهمة واحدة بشكل جيد، وبنية عامة واضحة. يجب أن تحكي الشيفرة نفسها قصة تجعل من السهل على القارئ متابعة المنطق والغرض من كل مكون.
التحسين المستمر ضروري. كتابة الشيفرة النظيفة عملية مستمرة تتطلب اهتمامًا دائمًا وإعادة هيكلة. على المبرمجين اتباع قاعدة "كشاف الكشافة": "اترك المخيم أنظف مما وجدته". وهذا يعني البحث دائمًا عن فرص لتحسين وضوح وبنية الشيفرة، حتى ولو بطرق صغيرة، مع كل تعديل أو إضافة.
2. الأسماء المعبرة تعزز وضوح الشيفرة وسهولة صيانتها
يجب أن يجيب اسم المتغير أو الدالة أو الفئة على كل الأسئلة المهمة: لماذا وُجد؟ ماذا يفعل؟ وكيف يُستخدم؟
اختر أسماء وصفية. يجب أن تكون الأسماء واضحة بذاتها وتكشف عن النية وراء المتغيرات والدوال والفئات. تجنب استخدام أسماء بحرف واحد، أو اختصارات، أو رموز غامضة تتطلب جهدًا ذهنيًا لفهم غرضها.
استخدم قواعد التسمية بشكل متسق. اعتمد وطبق قواعد التسمية القياسية للغة البرمجة والفريق الذي تعمل معه، مثل:
- CamelCase لأسماء الفئات (مثلاً: CustomerOrder)
- camelCase لأسماء المتغيرات والدوال (مثلاً: totalAmount)
- ALL_CAPS للثوابت (مثلاً: MAX_SIZE)
تجنب الأسماء المضللة أو الزائدة. لا تستخدم أسماء قد تثير اللبس أو الخلط. مثلاً، لا تضع كلمة "list" في اسم متغير إذا لم يكن فعلاً قائمة. كذلك، تجنب الكلمات الزائدة أو عديمة الفائدة مثل "data" أو "info" إذا لم تضف معنى.
3. يجب أن تكون الدوال صغيرة، تقوم بمهمة واحدة، وتعمل على مستوى تجريد واحد
يجب أن تقوم الدوال بمهمة واحدة فقط، وأن تقوم بها بشكل جيد، ولا شيء أكثر.
حافظ على صغر حجم الدوال. الدوال المثالية لا تتجاوز 20 سطرًا. هذا يجعلها أسهل في القراءة والفهم والصيانة. كما أن الدوال الصغيرة أسهل في التسمية بدقة، والاختبار، وإعادة الاستخدام.
مبدأ المسؤولية الواحدة. يجب أن يكون لكل دالة غرض واضح ومحدد. إذا كانت الدالة تقوم بأكثر من مهمة، فيجب تقسيمها إلى دوال أصغر وأكثر تركيزًا. هذا يعزز من وضوح الشيفرة ويجعلها أكثر تنظيمًا وأسهل في التعديل.
مستوى تجريد موحد. داخل الدالة، يجب أن تكون كل العمليات على نفس مستوى التجريد. خلط المنطق عالي المستوى مع التفاصيل منخفضة المستوى يجعل الدوال أصعب في الفهم والصيانة. استخدم تقنية "استخراج الدالة" لفصل مستويات التجريد المختلفة إلى دوال مستقلة.
4. يجب أن تكون التعليقات قليلة وضرورية حقًا
الاستخدام الصحيح للتعليقات هو تعويض عن فشلنا في التعبير عن أنفسنا بالشيفرة.
الشيفرة يجب أن تكون واضحة بذاتها. الشيفرة المكتوبة جيدًا بأسماء وبنية واضحة غالبًا ما تلغي الحاجة إلى التعليقات. قبل إضافة تعليق، فكر إذا كان بإمكانك إعادة هيكلة الشيفرة لجعل نيتها أوضح.
استخدم التعليقات بحكمة. التعليقات الجيدة تشرح لماذا تم فعل شيء ما، وليس كيف تم فعله. يجب أن توفر سياقًا أو توضيحًا لا يمكن التعبير عنه بالشيفرة وحدها. من أنواع التعليقات المفيدة:
- تعليقات قانونية (حقوق النشر، الترخيص)
- شرح النية أو الخوارزميات
- تحذيرات من العواقب
- تعليقات TODO (تستخدم باعتدال)
تجنب التعليقات الزائدة أو المضللة. لا تكتب تعليقات تعيد ما تقوله الشيفرة بوضوح. التعليقات القديمة أو غير الصحيحة أسوأ من عدم وجود تعليقات، لأنها قد تضلل القارئ. راجع التعليقات بانتظام وحدثها مع الشيفرة التي تصفها.
5. التنسيق الصحيح يحسن من قابلية قراءة الشيفرة
تنسيق الشيفرة هو وسيلة للتواصل، والتواصل هو أولى مهام المطور المحترف.
الثبات في الأسلوب مهم. ضع واعتمد أسلوب تنسيق موحد عبر قاعدة الشيفرة الخاصة بك، يشمل:
- التراجع (Indentation)
- فواصل الأسطر
- مواضع الأقواس
- المسافات حول العوامل والكلمات المفتاحية
التنسيق العمودي. نظم الشيفرة عموديًا لتعزيز الوضوح:
- اجمع المفاهيم المرتبطة معًا
- فصل المفاهيم غير المرتبطة
- أعلن المتغيرات بالقرب من مكان استخدامها
- ضع الدوال المعتمدة بجانب بعضها
التنسيق الأفقي. اجعل الأسطر قصيرة نسبيًا (عادة بين 80-120 حرفًا) لتجنب الحاجة للتمرير الأفقي. قسم العبارات الطويلة إلى عدة أسطر بطريقة منطقية. استخدم المساحات البيضاء لفصل الكتل المنطقية داخل السطر.
6. الكائنات وهياكل البيانات تخدم أغراضًا مختلفة
الكائنات تخفي بياناتها خلف التجريدات وتعرض دوالًا تعمل على تلك البيانات. هياكل البيانات تعرض بياناتها ولا تحتوي على دوال ذات معنى.
الكائنات مقابل هياكل البيانات. الكائنات تغلف البيانات وتعرض السلوك من خلال الطرق (methods). هي مناسبة لإضافة أنواع جديدة (فئات) دون تغيير السلوك القائم. أما هياكل البيانات، فهي تعرض البيانات ولا تحتوي على سلوكيات مهمة. هي مناسبة لإضافة سلوكيات جديدة دون تغيير أنواع البيانات.
اختر النهج المناسب. استخدم الكائنات عندما تريد إضافة أنواع جديدة بشكل متكرر مع الحفاظ على ثبات السلوكيات. استخدم هياكل البيانات عندما تريد إضافة سلوكيات جديدة بشكل متكرر مع الحفاظ على ثبات الأنواع. فهم هذا التمييز يساعد في تصميم أنظمة أكثر مرونة وسهولة في الصيانة.
قانون ديميتير. بالنسبة للكائنات، اتبع قانون ديميتير: يجب أن تستدعي الطريقة فقط طرقًا على:
- الكائن نفسه
- معطياته
- أي كائنات ينشئها
- مكوناته المباشرة
هذا المبدأ يساعد في تقليل الترابط بين أجزاء النظام المختلفة.
7. التعامل مع الأخطاء يجب أن يكون نظيفًا ومفيدًا
التعامل مع الأخطاء مهم، لكن إذا كان يعيق وضوح المنطق فهو خاطئ.
استخدم الاستثناءات بدلًا من رموز الخطأ. الاستثناءات توفر طريقة أنظف للتعامل مع الأخطاء مقارنة برموز الخطأ التقليدية. تفصل منطق التعامل مع الأخطاء عن الشيفرة الرئيسية، مما يجعل كلاهما أسهل في الفهم والصيانة.
أنشئ رسائل خطأ مفيدة. يجب أن توفر رسائل الخطأ سياقًا كافيًا لفهم ما حدث وأين. أدرج تفاصيل مثل:
- العملية التي كانت تُجرى
- الخطأ المحدد الذي وقع
- أي قيم أو حالة ذات صلة
اكتب عبارات try-catch-finally أولًا. عند كتابة شيفرة قد ترمي استثناءات، ابدأ بكتابة كتل try-catch-finally. هذا يساعد على ضمان أن الشيفرة مقاومة للأخطاء من البداية وأن حالات الخطأ مدروسة بشكل صحيح.
8. اختبارات الوحدة ضرورية للحفاظ على الشيفرة النظيفة
شيفرة الاختبار لا تقل أهمية عن شيفرة الإنتاج.
اكتب الاختبارات أولًا. اتبع ممارسة تطوير البرمجيات المعتمدة على الاختبار (TDD):
- اكتب اختبارًا يفشل
- اكتب أقل شيفرة لتمرير الاختبار
- أعد هيكلة الشيفرة مع الحفاظ على نجاح الاختبار
هذا النهج يضمن أن شيفرتك قابلة للاختبار من البداية ويساعد في دفع التصميم الجيد.
حافظ على نظافة الاختبارات. طبق نفس معايير النظافة على شيفرة الاختبار كما تفعل مع شيفرة الإنتاج. يجب أن تكون الاختبارات:
- قابلة للقراءة
- سهلة الصيانة
- موثوقة
اتبع مبادئ F.I.R.S.T للاختبارات:
- سريعة: يجب أن تنفذ بسرعة
- مستقلة: لا تعتمد على بعضها البعض
- قابلة للتكرار: يمكن تشغيلها في أي بيئة
- ذات تحقق ذاتي: تعطي نتيجة صحيحة أو خاطئة
- في الوقت المناسب: تكتب قبل شيفرة الإنتاج مباشرة
9. يجب أن تكون الفئات صغيرة، مركزة، وتتبع مبدأ المسؤولية الواحدة
القاعدة الأولى للفئات أنها يجب أن تكون صغيرة. القاعدة الثانية أنها يجب أن تكون أصغر من ذلك.
حافظ على تركيز الفئات. يجب أن تتحمل الفئة مسؤولية واحدة واضحة ومحددة. إذا لم تستطع وصف غرض الفئة في حوالي 25 كلمة دون استخدام "و" أو "أو"، فهي على الأرجح تقوم بأكثر من مهمة.
اسعَ إلى تماسك عالي. يجب أن تكون الدوال والمتغيرات داخل الفئة مرتبطة ارتباطًا وثيقًا وتعمل معًا لتحقيق مسؤولية الفئة. التماسك المنخفض غالبًا ما يشير إلى أن الفئة تحاول القيام بالكثير ويجب تقسيمها.
مبدأ الانفتاح والإغلاق. صمم الفئات بحيث تكون مفتوحة للتمديد ولكن مغلقة للتعديل. غالبًا ما يتطلب ذلك استخدام التجريدات والواجهات للسماح بإضافة وظائف جديدة دون تغيير الشيفرة القائمة.
10. البرمجة المتزامنة تتطلب تصميمًا وتنفيذًا دقيقين
كتابة برامج متزامنة نظيفة أمر صعب—صعب جدًا.
افهم تحديات التزامن. البرمجة المتزامنة تقدم تعقيدات مثل:
- حالات السباق
- الجمود (Deadlocks)
- مشاكل الحيّوية (Liveness)
- تأثيرات الأداء
فصل الشيفرة المتعلقة بالتزامن. عزل الشيفرة التي تتعامل مع التزامن يجعل من الأسهل التفكير فيها، اختبارها، وصيانتها، سواء للأجزاء المتزامنة أو غير المتزامنة من النظام.
استخدم المكتبات والأُطُر الموجودة. استعن بمكتبات وأُطُر التزامن المجربة (مثل java.util.concurrent في جافا) بدلًا من محاولة تنفيذ التحكم بالتزامن منخفض المستوى بنفسك. هذه الأدوات مُحسنة ومختبرة جيدًا لأنماط التزامن الشائعة.
اكتب اختبارات شاملة. اختبار الشيفرة المتزامنة تحدٍ لكنه ضروري. اكتب اختبارات:
- تنشئ عدة خيوط (Threads)
- تغير التوقيت والجدولة
- تُشغل مرات عديدة لزيادة فرصة كشف المشاكل المتقطعة
- تستخدم أدوات مثل منظفات الخيوط والمحللات الثابتة للمساعدة في تحديد الأخطاء المحتملة في التزامن
ملخص المراجعات
يُعتبر كتاب "الشفرة النظيفة" من الكتب الأساسية التي لا غنى عنها لمطوري البرمجيات، حيث يقدم رؤى قيمة حول كيفية كتابة شفرة برمجية سهلة القراءة والصيانة. يشيد الكثيرون بنصائحه العملية المتعلقة بتسمية المتغيرات، وتصميم الدوال، واختبار البرامج، إلا أن بعض القراء يرون أن محتواه يميل بشكل كبير إلى لغة جافا، وأحيانًا تكون توصياته متشددة إلى حد ما. أما دراسات الحالة التي يتضمنها الكتاب فقد لاقت ردود فعل متباينة، حيث وجدها البعض مفيدة بينما لم تكن بنفس القدر من الإعجاب لدى آخرين. ورغم هذه الملاحظات، يظل الكتاب بالنسبة لكثير من المطورين مرجعًا لا بد منه، ساهم بشكل كبير في تحسين ممارساتهم البرمجية وفهمهم لفن صناعة البرمجيات.
قرأ الآخرون أيضًا
الأسئلة الشائعة
What's Clean Code: A Handbook of Agile Software Craftsmanship about?
- Focus on Software Craftsmanship: The book emphasizes the importance of writing clean, maintainable code as a hallmark of professionalism in software development.
- Principles and Practices: It outlines various principles, patterns, and practices that help programmers write code that is not only functional but also easy to read and understand.
- Real-World Examples: Numerous examples of both good and bad code are included, demonstrating how to transform messy code into clean code through refactoring and disciplined practices.
Why should I read Clean Code by Robert C. Martin?
- Improve Coding Skills: Reading the book can significantly enhance your programming skills by teaching you how to write code that is easier to maintain and understand.
- Professional Development: It is a valuable resource for anyone looking to advance their career in software development, instilling a mindset of craftsmanship and quality.
- Practical Advice: The book provides practical advice that can be applied immediately in your coding practices, making it a useful guide for both novice and experienced programmers.
What are the key takeaways of Clean Code?
- Meaningful Names: The book stresses the importance of using intention-revealing names for variables, functions, and classes to enhance code readability and maintainability.
- Small Functions: Functions should be small and focused on a single task, adhering to the principle of "Do One Thing" to improve clarity and reduce complexity.
- Error Handling: Martin advocates for using exceptions rather than return codes for error handling, which helps keep the main logic of the code clean and unobscured.
What are the best quotes from Clean Code and what do they mean?
- "Clean code is a matter of discipline.": This quote emphasizes that writing clean code requires consistent effort and adherence to best practices, rather than relying on luck or talent alone.
- "Comments do not make up for bad code.": This highlights the idea that if code is poorly written, no amount of commenting can compensate for its lack of clarity and structure.
- "Leave the campground cleaner than you found it.": This metaphor encourages developers to improve the codebase with every change, ensuring that the code remains clean and maintainable over time.
How does Clean Code define clean code?
- Readable and Understandable: Clean code is defined as code that is easy to read and understand, allowing other developers to quickly grasp its purpose and functionality.
- Minimal Complexity: It should have minimal complexity, with each function and class focused on a single responsibility, making it easier to test and maintain.
- Well-Structured: Clean code is well-structured, following consistent formatting and naming conventions that enhance its clarity and reduce the cognitive load on the reader.
What is the Boy Scout Rule in Clean Code?
- Continuous Improvement: The Boy Scout Rule states that developers should "leave the campground cleaner than you found it," meaning that every time you work on code, you should strive to improve it.
- Small Changes Matter: This can be as simple as renaming a variable for clarity or refactoring a small function, which contributes to the overall cleanliness of the codebase.
- Professional Responsibility: Adhering to this rule reflects a professional attitude towards code quality and maintenance, fostering a culture of continuous improvement within a team.
What is the Single Responsibility Principle (SRP) in Clean Code?
- Definition of SRP: The SRP states that "a class should have one, and only one, reason to change." This means that each class should focus on a single responsibility or functionality.
- Benefits of SRP: Adhering to SRP leads to better organization of code, making it easier to understand, test, and maintain. It reduces the risk of changes in one area affecting unrelated parts of the code.
- Implementation Guidance: Martin provides practical advice on how to identify responsibilities and refactor classes to adhere to SRP, ensuring that code remains clean and manageable.
How does Clean Code address error handling?
- Use Exceptions: The book advocates for using exceptions rather than return codes for error handling, which helps keep the main logic of the code clean and unobscured.
- Separation of Concerns: Error handling should be separated from the main logic of the code, allowing developers to focus on the primary functionality without being bogged down by error-checking clutter.
- Provide Context: Exceptions should provide enough context to understand the source and nature of the error, making it easier to diagnose and fix issues when they arise.
What role does testing play in Clean Code?
- Foundation of Clean Code: Testing is considered a fundamental discipline in writing clean code. It ensures that the code behaves as expected and helps catch issues early in the development process.
- Fast and Reliable Tests: The book emphasizes that tests should be fast and reliable to encourage frequent execution. This helps maintain a clean codebase and reduces the risk of introducing bugs.
- Self-Validating Tests: Tests should be designed to be self-validating, meaning they should clearly indicate whether the code is functioning correctly. This reduces ambiguity and increases confidence in the code.
How does Clean Code suggest handling dependencies?
- Dependency Inversion Principle (DIP): The book explains that "high-level modules should not depend on low-level modules. Both should depend on abstractions." This principle encourages the use of interfaces and abstract classes to reduce coupling.
- Use of Dependency Injection: Martin recommends using dependency injection to manage dependencies, allowing for more flexible and testable code. This approach decouples the creation of dependencies from their usage.
- Benefits of Managing Dependencies: By managing dependencies effectively, developers can create systems that are easier to maintain and extend, leading to cleaner and more robust code.
What are some common code smells identified in Clean Code?
- Duplicated Code: This is a major code smell that indicates a lack of abstraction. The book advises eliminating duplication to improve maintainability and reduce errors.
- Long Methods: Methods that are too long can be difficult to understand and maintain. The book suggests breaking them down into smaller, more manageable functions.
- Excessive Comments: While comments can be helpful, excessive or redundant comments often indicate that the code itself is not clear. The goal should be to write self-explanatory code that requires minimal comments.
How can I apply the principles from Clean Code in my own projects?
- Start with Small Changes: Begin by applying the principles of clean code to small sections of your codebase. Refactor one class or function at a time to improve readability and maintainability.
- Write Tests First: Adopt Test-Driven Development (TDD) practices by writing tests before implementing new features. This ensures that your code is always covered by tests and helps maintain quality.
- Regularly Refactor: Make refactoring a regular part of your development process. Continuously look for opportunities to improve code structure and eliminate duplication, keeping your codebase clean and efficient.
