Clean Code

تخيل انك بتبني عمارة علي اساس ضعيف و حبيت تضيف دور جديد للمبني هتلاقي ان المبني كله بدأ ينهار و دا بسبب الاساس الضعيف من الاول ، ف زي ما بنقول الاهم من الشغل تظبيط الشغل ، هنتعرف النهاردة عن ازاي نخلي السوفتوير بتاعنا الكواليتي بتاعته كويسة

الـ Seam هو عبارة عن مكان نقدر من خلاله اننا نغير في الـ Behavior يعني السلوك بتاع البرنامج بتاعنا في المكان ده من غير منغير اي حاجة في المكان ذات نفسه.

مش دايما بيكون السبب الوحيد لاننا نكسر الاعتمادية هو اننا نعمل Testing للـ Class , وده لان احيانا كتير الـ Class اللي عاوزين نعملها Testing بيكون ليها تأثير على Classes تانية , والـ Tests بتاعتنا محتاجة تعرف اكتر عن التأثير ده كويس.

التغييرات اللي بتتم في أي نظام ممكن تتم بطريقتين أساسيتين , ممكن نقول عليهم Edit and Pray أو Cover and Modify .. ولسوء الحظ الـ Edit and Pray هي نوعا ما الـ Standard , طب ايه هم الطريقتين دول , ده اللي هنتكلم عنه في الـ Chapter ده بشكل أساسي ..

كتير مننا بيتعامل مع Legacy Code ولكن ما بنكونش عارفين ازاي نتصرف ونتعامل معاه بشكل فعال , وده لإن زي ماحنا عارفين أغلب الـ Legacy Code بتكون ضخمة وفيها تعقيدات كتير جدا, وكون الـ Code Legacy مش بالضرورة انه يكون كود سيء

الـ Observer Design Pattern واحد من أهم الـ Behavioral Design Patterns اللي بتسمحلك انك تحدد زي طريقة Subscription تسمحلك انك تـ Notify بعض الـ Objects بأي نوع من الـ Events اللي ممكن يكونوا مهتمين بيها.

حيث أن الـ Java من لغات البرمجة الرائدة واللي بتشتهر بقوتها ومرونتها ومستمرة في سعيها لتحسين تجربة المبرمجين وانها تخلي الـ Code أكثر اتقان، ومن ضمن المميزات الكتيرة اللي ضافتها وخصوصًا في الـ Java 8 هي الـ Optional.

يبدأ الكتاب وقبل أي شيء لعرض مثال واقعي لكود مكتوب، حتى يريك كيف أنه بعد تحسينه من خلال الـ Refactoring أصبح قادرًا أن يكون Resilient ومرن لأي تغييرات من الممكن أن تطرأ عليه.

تعد مراجعة الكود خطوة مهمة للتحسين من جودة الكود، بالإضافة لميزات أخرى كانخفاض تكلفة التطوير عند اكتشاف الأخطاء في وقت مبكر من دورة حياة التطوير،