Refactoring

الـ 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 ومرن لأي تغييرات من الممكن أن تطرأ عليه.

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

غالبًا ما تبدأ الـClass بكونها صغيرة ولكن مع الوقت ومع اضافة التغييرات واضافة ميزات جديدة  في التطبيق يزداد حجمها تدريجيًا إلى أن تصبح عملاقة ويصعب التعامل معها بشكل كبير مما يحد من إمكانية إضافة المزيد من التغييرات أو صيانة الـCode