Sensing and Separation: Legacy Code #03

مش دايما بيكون السبب الوحيد لاننا نكسر الاعتمادية هو اننا نعمل Testing للـ Class , وده لان احيانا كتير الـ Class اللي عاوزين نعملها Testing بيكون ليها تأثير على Classes تانية , والـ Tests بتاعتنا محتاجة تعرف اكتر عن التأثير ده كويس.
Sensing and Separation: Legacy Code #03
Sensing and Separation: Legacy Code #03

في هذه الصفحة

المقدمة

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

طب ازاي نـ Sense او نحس بالتأثير اللي بيعمله الـ Class اللي محتاجين نعمله Testing على الـ Classes التانية وهل في اسباب تانية تخلينا نفكر اصلا نكسر الاعتمادية ؟ ده اللي هنتكلم عنه في الـ Chapter ده.


Sensing and Separation

احيانا ممكن نعرف ونحس بالتأثيرات اللي الـ Classes اللي عاوزين نعملها Testing بتأثر بيها على Classes تانية من خلال الـ Interface للـ Classes التانية , ولكن احيانا برضو مش بنقدر نعمل ده , والخيار الوحيد اللي قدامنا هو اننا نحاكي الـ Classes التانية دي أو بتعبير ادق نـ Impersonate الـ Classes التانية عشان نقدر نستشعر التأثير اللي بيقع عليها بشكل مباشر.

وعلى العموم اما بنكون عاوزين نبدأ نعمل Testing ومحتاجين نكسر الاعتمادية ففيه عندنا سببنا أساسيين لكسر الاعتمادية الا وهم : الـ Sensing والـ Separation.

  1. أول حاجة هي الـ Sensing ودي معناها اننا بنكسر الاعتمادية عشان نستشعر ونشوف ايه الـ Values اللي الكود بتاعنا بيعملها Computing ومش عارفين نعملها Access
  2. تاني حاجة هي الـ Separation ودي معناها اننا بنكسر الاعتمادية عشان نفصل الاجزاء اللي في الـ Code اللي مش عارفين نعملها Testing بشكل كويس ..

وعشان نفهم الموضوع اكتر خلونا دلوقتي نشوف مع بعض المثال ده:

عندنا Class اسمها NetworkBridge والـ Class دي موجودة في Network Management Application , هنلاحظ هنا ان الـ Constructor بياخد List من الـ Endpoints اللي عاوز يعملها Configuration ويديرها بشكل كويس باستعمال Local Hardware.

والـ Users اللي بيستعملوا الـ Network Bridge ممكن يستعملوا الـ Methods بتاعتها انهم يعملوا Route للـ Traffic من Endpoint للتانية.

فالسؤال هنا لو احنا عاوزين نعمل Testing للـ Network Bridge هنعمل ده ازاي ؟ الـ Class ممكن تكون معتمدة على Calls مباشرة على Hardware حقيقي في الـ Constructor , فهل احنا عاوزين الـ Hardware يكون متاح عشان نـ Create Objects من الـ Class دي ؟ واللي اسوا من كده احنا اصلا ازاي هنعرف اللي الـ Bridge بتعمله او بتأثر بيه على الـ Hardware أو الـ Endpoints ؟ فاحنا بالنسبالنا حاليا الـ Class دي عبارة عن Black Box

ولكن في الحقيقة فيه بعض الحلول اللي ممكن متخليش الموضوع سيء للدرجة دي , زي اننا ممكن نكتب Code يكون غرضه انه يعمل Sniff للـ Packets من خلال الـ Network , وممكن برضو اننا نجيب بعض الـ Hardware للـ Network Bridge ونخليها تكلمهم , وبالتالي نقدر نـ Create Object بسهولة ونشوف تأثير ده على الـ Hardware .. كل دي حلول ممكن تشتغل , ولكن هي من أسوأ أسوأ الحلول وهتتطلب شغل كتير جدا ..

وربما الشغل اللي محتاجين نغيره اصلا في الاساس في الـ Class دي مش محتاج اي حاجة من دول ..


فزي ما حنا شايفين دلوقتي احنا في المثال ده واقعين قدام الـ Sensing والـ Separation مع بعض, فاحنا مش قادرين نـ Sense التأثير اللي الـ Calls بتاعتنا هتعمله للـ Methods اللي موجودة في الـ Class , وبرضو مش قادرين نعملها Run بشكل منفصل ومستقل عن باقي الـ Application ..

طب انهي اكتر مشكلة فيهم محتاجة تركيز او اصعب ؟ في الحقيقة مفيش اجابة واضحة لده , لاننا محتاجين الاتنين وزي ما شوفنا هم الاتنين اسباب تدفعنا لاننا نكسر الاعتمادية ..

وفيه شيء واضح جدا على الرغم من كل ده الا وهو ان فيه طرق كتيرة لفصل الـ Software , وفي الحقيقة في الكتاب هنتناول بعض الـ Techniques المهمة اللي هتساعدنا في حاجة زي كده , ولكن فيه واحد من الـ Techniques المهيمنة في موضوع الـ Sensing وهو الـ Faking Collaborators.


تقدروا دلوقتي تشتركوا في النشرة الأسبوعية لاقرأ-تِك بشكل مجاني تمامًا عشان يجيلكوا كل جديد بشكل أسبوعي فيما يخص مواضيع متنوعة وبشروحات بسيطة وسهلة وبجودة عالية 🚀

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

Eqraatech Newsletter | Eqraatech - اقرأ-تِك | Substack
محتوى تقني متميز في مختلف مجالات هندسة البرمجيات باللغة العربية عن طريق تبسيط المفاهيم البرمجية المعقدة بشكل سلس وباستخدام صور توضيحية مذهلة. Click to read Eqraatech Newsletter, a Substack publication with hundreds of subscribers.

Legacy Code and Dependencies

فزي ما شوفنا خلونا نعيد الجزء ده تاني , في الـ Legacy Code هنلاقي اكبر مخاوفنا واكبر التحديات هي الاعتمادية والتعامل معاها , ولو احنا عاوزين نعمل Execute لجزء من الـ Code لوحده ونشوف هو بيعمل ايه , فهنضطر اننا نكسر الاعتمادية عشان نشوف ده, بس الكلام بيكون اسهل من الفعل , وده لان عادة الجزء اللي محتاجين نفصله بنسبة كبيرة بيكون الجزء الوحيد اللي بيدينا Sense لتأثير الـ Actions بتاعتنا ..

فلو نقدر نحط Code معين في المكان ده وبالتالي الـ Test بتاعتنا تعدي عليه , هنقدر وقتها نكتب الـ Tests بتاعتنا , والجزء ده هيتنادى عليه فهنشوف التأثير ايه، والكلام اللي قولناه ده بنسميه Fake Objects ..


Fake Objects

هذا المقال مخصص للأعضاء المنتسبين لخطط الاشتراك المدفوعة فقط

اشترك الآن بنشرة اقرأ-تِك الأسبوعية

لا تدع أي شيء يفوتك. واحصل على أحدث المقالات المميزة مباشرة إلى بريدك الإلكتروني وبشكل مجاني!