أهم النقاط
1. التعقيد هو أصل تحديات تصميم البرمجيات
ينبع التعقيد من تراكم التبعيات والغموض.
يتراكم التعقيد تدريجيًا. مع نمو أنظمة البرمجيات، تميل إلى التعقيد بسبب التراكم التدريجي للتبعيات بين المكونات وأجزاء الكود الغامضة. ويتجلى هذا التعقيد في ثلاثة أشكال رئيسية:
- تضخيم التغيير: التعديلات الصغيرة تتطلب تغييرات في أماكن متعددة
- العبء المعرفي: يحتاج المطورون لفهم كميات كبيرة من المعلومات لإجراء التعديلات
- المجهولات المجهولة: عدم وضوح ما هو الكود الذي يجب تعديله أو المعلومات ذات الصلة
البساطة هي العلاج. لمواجهة التعقيد، يجب على مصممي البرمجيات التركيز على إنشاء تصاميم بسيطة وواضحة تقلل من التبعيات والغموض. ويتضمن ذلك:
- التصميم المعياري: تقسيم النظام إلى وحدات مستقلة
- إخفاء المعلومات: تغليف تفاصيل التنفيذ داخل الوحدات
- التجريد الواضح: توفير واجهات بسيطة تخفي التعقيد الكامن
2. البرمجة الاستراتيجية تتفوق على الأساليب التكتيكية
أفضل نهج هو القيام بالعديد من الاستثمارات الصغيرة بشكل مستمر.
التفكير طويل الأمد يحقق نتائج أفضل. تركز البرمجة الاستراتيجية على إنشاء تصميم ممتاز يعمل بشكل فعّال، بدلاً من مجرد جعل الكود يعمل. ويشمل هذا النهج:
- استثمار الوقت في التصميم مقدمًا
- إجراء تحسينات صغيرة مستمرة
- إعادة هيكلة الكود للحفاظ على تصميم نظيف
البرمجة التكتيكية تؤدي إلى ديون تقنية. رغم أن الأساليب التكتيكية قد تبدو أسرع على المدى القصير، إلا أنها غالبًا ما تؤدي إلى:
- تراكم الحلول السريعة والاختراقات
- صعوبة متزايدة في إجراء التعديلات مع مرور الوقت
- ارتفاع تكاليف التطوير على المدى الطويل
من خلال تبني عقلية استراتيجية، يمكن للمطورين إنشاء أنظمة أسهل في الصيانة والتطوير، مما يوفر الوقت والجهد على المدى البعيد.
3. يجب أن تكون الوحدات عميقة، لا سطحية
أفضل الوحدات هي التي تقدم وظائف قوية مع واجهات بسيطة.
العمق يخلق التجريد. تخفي الوحدات العميقة تعقيد التنفيذ الكبير خلف واجهات بسيطة. وهذا النهج:
- يقلل العبء المعرفي على مستخدمي الوحدة
- يسهل تعديل التنفيذ
- يعزز إخفاء المعلومات والتغليف
الوحدات السطحية تزيد التعقيد. الوحدات التي تمتلك واجهات معقدة مقارنة بوظيفتها تعتبر سطحية. وهذه الوحدات:
- تزيد من تعقيد النظام الكلي
- تكشف عن تفاصيل تنفيذ غير ضرورية
- تجعل النظام أصعب في الفهم والتعديل
لإنشاء وحدات عميقة، ركز على تصميم واجهات بسيطة وبديهية تخفي التعقيد الكامن. اسعَ لتعظيم نسبة الوظيفة إلى تعقيد الواجهة.
4. الواجهات الجيدة هي مفتاح إدارة التعقيد
تحتوي واجهة الوحدة على نوعين من المعلومات: رسمية وغير رسمية.
الواجهات المصممة جيدًا تبسط الأنظمة. توفر الواجهات الجيدة تجريدًا واضحًا لوظائف الوحدة دون كشف تفاصيل غير ضرورية. ويجب أن تكون:
- بسيطة وبديهية في الاستخدام
- تخفي تعقيدات التنفيذ
- تقدم معلومات رسمية (مثل توقيعات الدوال) وغير رسمية (مثل وصف السلوك العام)
يجب أن تتطور الواجهات بحذر. عند تعديل الكود الموجود:
- ضع في اعتبارك تأثير التغييرات على واجهة الوحدة
- تجنب كشف تفاصيل التنفيذ
- اسعَ للحفاظ على التجريد أو تحسينه
من خلال التركيز على إنشاء وصيانة واجهات جيدة، يمكن للمطورين إدارة التعقيد وجعل أنظمتهم أكثر معيارية وأسهل في الفهم.
5. التعليقات ضرورية لإنشاء التجريدات
التعليقات هي الوسيلة الوحيدة لالتقاط التجريدات بشكل كامل، والتجريدات الجيدة أساسية لتصميم نظام جيد.
التعليقات تكمل التجريدات. بينما يعبر الكود عن تفاصيل التنفيذ، فإن التعليقات ضرورية لالتقاط:
- قرارات التصميم عالية المستوى
- الأسباب وراء الاختيارات
- التوقعات والقيود
- التجريدات التي لا تظهر بوضوح من الكود وحده
اكتب التعليقات أولاً. بكتابة التعليقات قبل تنفيذ الكود:
- توضح تفكيرك حول التصميم
- تتيح تقييم وتحسين التجريدات مبكرًا
- تضمن تحديث الوثائق دائمًا
ركز على ماذا ولماذا، لا على كيف. يجب أن:
- تصف الأمور غير الواضحة من الكود
- تشرح الهدف والسلوك العام للكود
- تتجنب تكرار ما يفعله الكود فقط
من خلال إعطاء الأولوية لتعليقات واضحة ومفيدة، يمكن للمطورين إنشاء تجريدات أفضل وتحسين التصميم العام لأنظمتهم.
6. التسمية والتنسيق المتسقان يعززان قابلية القراءة
الأسماء الجيدة هي شكل من أشكال التوثيق: تجعل الكود أسهل للفهم.
الاتساق يقلل العبء المعرفي. من خلال وضع واتباع قواعد للتسمية والتنسيق، يمكن للمطورين:
- جعل الكود أكثر توقعًا وأسهل قراءة
- تقليل الجهد الذهني المطلوب لفهم الكود
- إبراز التناقضات التي قد تشير إلى أخطاء أو مشاكل تصميم
اختر الأسماء بعناية. يجب أن تكون الأسماء:
- دقيقة وواضحة
- تخلق صورة واضحة للكيان المسمى
- مستخدمة بشكل متسق في جميع أنحاء قاعدة الكود
التنسيق مهم. يساعد التنسيق المتسق على:
- إظهار هيكل الكود بوضوح
- تجميع العناصر ذات الصلة بصريًا
- إبراز المعلومات المهمة
من خلال الاهتمام بالتسمية والتنسيق، يمكن للمطورين تحسين قابلية قراءة وصيانة الكود بشكل كبير.
7. التحسين المستمر ضروري للحفاظ على تصميم نظيف
إذا أردت هيكل برمجي نظيفًا يسمح لك بالعمل بكفاءة على المدى الطويل، فعليك تخصيص وقت إضافي في البداية لإنشاء هذا الهيكل.
التصميم عملية مستمرة. يتطلب التصميم النظيف للبرمجيات:
- إعادة هيكلة منتظمة لتحسين الكود الحالي
- تقييم مستمر لقرارات التصميم
- الاستعداد لإجراء تغييرات مع تطور النظام
استثمر في التحسين. للحفاظ على تصميم نظيف:
- خصص وقتًا للتنظيف وإعادة الهيكلة
- عالج مشاكل التصميم بسرعة قبل تفاقمها
- اعتبر كل تغيير في الكود فرصة لتحسين التصميم العام
وازن بين الكمال والتقدم. أثناء السعي للتصميم النظيف:
- اعترف بأن بعض التنازلات قد تكون ضرورية
- ركز على تحسينات تدريجية
- أعطِ الأولوية للتغييرات التي تحقق أكبر فوائد
من خلال اعتبار التصميم عملية مستمرة من التحسين، يمكن للمطورين الحفاظ على أنظمتهم نظيفة وقابلة للإدارة مع نموها وتطورها.
8. يجب تبسيط معالجة الأخطاء، لا تكاثرها
أفضل طريقة للقضاء على تعقيد معالجة الاستثناءات هي تصميم واجهات برمجة التطبيقات بحيث لا توجد استثناءات للتعامل معها: عرّف الأخطاء بحيث تختفي.
قلل حالات الاستثناء. لتبسيط معالجة الأخطاء:
- صمم واجهات برمجة التطبيقات لتقليل الحالات الاستثنائية
- استخدم السلوكيات الافتراضية للتعامل مع الحالات الشاذة الشائعة
- فكر فيما إذا كانت الاستثناءات ضرورية حقًا
اجمع معالجة الأخطاء. عندما تكون الاستثناءات لا مفر منها:
- تعامل مع عدة استثناءات في مكان واحد إن أمكن
- استخدم تسلسلات هرمية للاستثناءات لتبسيط التعامل مع الأخطاء المرتبطة
- تجنب التقاط استثناءات لا يمكنك التعامل معها بشكل فعّال
اجعل الحالات العادية سهلة. ركز على جعل المسار العادي الخالي من الأخطاء في الكود بسيطًا وواضحًا قدر الإمكان. هذا النهج:
- يقلل العبء المعرفي على المطورين
- يقلل فرص ظهور الأخطاء
- يجعل الكود أسهل للفهم والصيانة
من خلال تبسيط معالجة الأخطاء، يمكن للمطورين إنشاء أنظمة أكثر متانة وأسهل في الفهم.
9. الكود العام أفضل عادة من الحلول الخاصة
حتى إذا استخدمت فئة بطريقة خاصة، فإن بناءها بطريقة عامة يتطلب جهدًا أقل.
العمومية تعزز إعادة الاستخدام. الكود العام:
- يمكن تطبيقه على نطاق أوسع من المشكلات
- غالبًا ما يكون أبسط وأكثر تجريدًا
- يميل إلى امتلاك واجهات أنظف
تجنب التخصص المبكر. عند تصميم وظائف جديدة:
- ابدأ بنهج عام إلى حد ما
- قاوم الرغبة في تحسين الاستخدامات الخاصة مبكرًا جدًا
- دع التصميم يتطور بناءً على أنماط الاستخدام الفعلية
وازن بين العمومية والبساطة. أثناء السعي للحلول العامة:
- تجنب الإفراط في الهندسة أو إضافة تعقيد غير ضروري
- تأكد من أن التصميم العام لا يزال سهل الاستخدام للحالات الشائعة
- كن مستعدًا لإنشاء حلول متخصصة عند الضرورة الحقيقية
من خلال تفضيل التصاميم العامة، يمكن للمطورين إنشاء أنظمة أكثر مرونة وقابلية للصيانة، مجهزة بشكل أفضل لمواجهة المتطلبات المستقبلية.
10. اكتب الكود من أجل القراءة، لا من أجل سهولة الكتابة
يجب تصميم البرمجيات لتسهيل القراءة، لا لتسهيل الكتابة.
أعطِ الأولوية للصيانة طويلة الأمد. عند كتابة الكود:
- ركز على جعله سهل الفهم للقراء في المستقبل
- تجنب الاختصارات أو الحيل التي تخفي هدف الكود
- استثمر الوقت في إنشاء تجريدات واضحة وتوثيق جيد
اجعل الكود واضحًا. اسعَ لكتابة كود:
- يمكن فهمه بسرعة وبجهد ذهني قليل
- يستخدم تسميات واضحة ومتسقة
- له هيكل منطقي وسهل المتابعة
أعد الهيكلة من أجل الوضوح. راجع وحسّن الكود الموجود بانتظام:
- ابحث عن فرص لتبسيط الأجزاء المعقدة
- قسم الدوال الطويلة إلى أجزاء أصغر وأكثر تركيزًا
- أزل التكرار والتناقضات
من خلال إعطاء الأولوية لقابلية القراءة على سهولة الكتابة، يمكن للمطورين إنشاء أنظمة أسهل في الصيانة، وتصحيح الأخطاء، والتطوير مع مرور الوقت. قد يتطلب هذا جهدًا أكبر في البداية لكنه يعود بفوائد كبيرة من حيث تقليل التعقيد وتحسين إنتاجية الفريق.
ملخص المراجعات
يحظى كتاب "فلسفة تصميم البرمجيات، الطبعة الثانية" بتقييمات متباينة بين القراء. إذ يشيد الكثيرون بالأفكار العميقة التي يقدمها حول إدارة التعقيد وتصميم الوحدات البرمجية المتقنة، بينما ينتقد البعض تركيزه الكبير على التعليقات البرمجية وقلة العمق في بعض المواضيع. يثمن القراء أسلوبه الواضح ونصائحه العملية، خاصة للمطورين المبتدئين، في حين يرى بعض المبرمجين ذوي الخبرة أنه مبسط للغاية أو يختلفون مع بعض التوصيات المطروحة. كما يُلاحظ أن الكتاب يركز بشكل رئيسي على البرمجة الكائنية التوجه ومنظور أكاديمي، مع رغبة البعض في وجود أمثلة لغوية أكثر تنوعًا وتطبيقات عملية من واقع الحياة.
قرأ الآخرون أيضًا
الأسئلة الشائعة
What's "A Philosophy of Software Design" about?
- Focus on Complexity: The book addresses the core problem of software design, which is managing complexity. It emphasizes that complexity is the primary challenge in building and maintaining software systems.
- Design Principles: John Ousterhout presents a set of high-level design principles aimed at reducing complexity, such as creating deep modules and defining errors out of existence.
- Practical Advice: The book offers practical advice for software developers on how to think strategically about design, rather than just focusing on getting code to work.
- Educational Approach: It is based on Ousterhout's experience teaching a software design course at Stanford, where students learn through iterative design and code reviews.
Why should I read "A Philosophy of Software Design"?
- Improve Design Skills: The book provides insights into improving software design skills, which can lead to more maintainable and efficient code.
- Strategic Mindset: It encourages a strategic approach to programming, focusing on long-term design quality rather than short-term fixes.
- Real-World Examples: The book includes numerous real-world examples and case studies that illustrate the principles in action.
- Philosophical Insights: It offers philosophical insights into the nature of software design, making it valuable for both novice and experienced developers.
What are the key takeaways of "A Philosophy of Software Design"?
- Complexity is Incremental: Complexity builds up in small increments, and managing it requires constant vigilance and strategic thinking.
- Deep Modules: Modules should have simple interfaces but provide significant functionality, hiding complexity from the rest of the system.
- Information Hiding: Effective information hiding reduces dependencies and makes systems easier to modify and understand.
- Design it Twice: Consider multiple design options before settling on one, as the first idea is rarely the best.
What is the "Design it Twice" principle in "A Philosophy of Software Design"?
- Multiple Options: The principle suggests considering multiple design options for each major decision, rather than settling on the first idea.
- Radical Differences: It encourages exploring radically different approaches to understand the strengths and weaknesses of each.
- Improved Design: By comparing alternatives, you can identify the best design or combine features from multiple designs for a superior solution.
- Learning Opportunity: This process also enhances your design skills by teaching you what makes designs better or worse.
How does "A Philosophy of Software Design" define complexity?
- Practical Definition: Complexity is anything in the software structure that makes it hard to understand and modify.
- Symptoms: It manifests as change amplification, cognitive load, and unknown unknowns, making development tasks more difficult.
- Causes: Complexity arises from dependencies and obscurity, which can be minimized through good design practices.
- Incremental Nature: Complexity accumulates in small increments, requiring a zero-tolerance approach to prevent it from becoming overwhelming.
What is the importance of "Deep Modules" in "A Philosophy of Software Design"?
- Simple Interfaces: Deep modules have simple interfaces that hide the complexity of their implementations, reducing the cognitive load on developers.
- Functionality vs. Interface: They provide significant functionality relative to the complexity of their interfaces, offering a high benefit-to-cost ratio.
- Information Hiding: Deep modules effectively hide information, making it easier to evolve the system without affecting other modules.
- Examples: The book uses examples like Unix I/O and garbage collectors to illustrate the concept of deep modules.
How does "A Philosophy of Software Design" suggest handling exceptions?
- Define Errors Out of Existence: Redefine operations to eliminate error conditions, reducing the need for exception handling.
- Mask Exceptions: Handle exceptions at a low level to prevent them from propagating and complicating higher-level code.
- Aggregate Exceptions: Use a single handler to manage multiple exceptions, simplifying the code and reducing duplication.
- Just Crash: For certain errors, it may be more practical to crash the application rather than handle the exception, especially if recovery is complex.
What role do comments play according to "A Philosophy of Software Design"?
- Essential for Abstraction: Comments are crucial for defining abstractions, as they provide information that can't be captured in code.
- Describe Non-Obvious Information: They should describe things that aren't obvious from the code, such as design rationale and usage constraints.
- Part of Design Process: Writing comments early in the design process can improve both the design and the quality of the comments.
- Avoid Repetition: Comments should not repeat the code but instead provide additional insights and context.
What is the "Investment Mindset" in "A Philosophy of Software Design"?
- Long-Term Focus: The investment mindset emphasizes spending time on design improvements that will pay off in the long run.
- Continuous Improvement: It involves making continual small investments in the system's design to prevent complexity from accumulating.
- Strategic Programming: Developers should prioritize creating a great design over just getting code to work, even if it takes longer initially.
- Payback Period: The book suggests that the benefits of a strategic approach will outweigh the initial costs within 6–18 months.
How does "A Philosophy of Software Design" address the issue of naming?
- Create an Image: Names should create a clear image of what the entity represents, providing precise and intuitive information.
- Consistency: Use names consistently across the codebase to reduce cognitive load and prevent misunderstandings.
- Avoid Vague Names: Names should be specific and avoid generic terms that can lead to ambiguity and errors.
- Impact on Complexity: Good naming practices can significantly reduce complexity and improve code readability.
What are some best quotes from "A Philosophy of Software Design" and what do they mean?
- "Complexity is incremental": This quote highlights the idea that complexity builds up gradually, requiring constant attention to manage.
- "Working code isn’t enough": It emphasizes that simply getting code to work is not sufficient; good design is crucial for long-term success.
- "Modules should be deep": This quote underscores the importance of creating modules with simple interfaces that hide complexity.
- "Define errors out of existence": It suggests redefining operations to eliminate error conditions, simplifying exception handling.
How does "A Philosophy of Software Design" suggest dealing with performance concerns?
- Natural Efficiency: Choose design alternatives that are naturally efficient without sacrificing simplicity.
- Measure Performance: Before optimizing, measure the system to identify the true bottlenecks and ensure changes have a measurable impact.
- Critical Path Design: Focus on optimizing the critical path, the smallest amount of code that must be executed in the common case.
- Simplicity and Speed: Simpler code tends to run faster, and clean design often leads to better performance.
