Changing Software: Legacy Code #01

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

في هذه الصفحة

المقدمة

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

عشان كده في السلسلة دي ان شاء الله هنعمل مراجعة لكتاب Working Effectively with Legacy Code وهنتناقش في كل شابتر من الكتاب بحيث نشجع بعض اننا نخلصه سوا باذن الله , طب مين ممكن الكتاب ده يفيده الكتاب ده هيكون مفيد جدا لأي حد بيتعامل مع Legacy Code بشكل فعال ده في المقام الأول ولكن هيكون مفيد للجميع كذلك برضو ولكن ممكن ما يلمسوش مدى أثرى وجدواه لو ماحتكوش بـ Legacy Systems قبل كده ..


Chapter 1: Changing Software

تغيير الكود حاجة عظيمة جدًا , وكمان ده شغلنا اللي بناكل بيه عيش .. ولكن فيه طرق تغيير الكود فيها بيخلي الحياة صعبة علينا وعلى غيرنا , وفيه طرق تانية بتخلي الحياة سهلة , واحنا في الكتاب تركيزنا هيكون على الجزء الصعب شوية وازاي نتعامل معاه .. وعشان نعمل ده محتاجين نفهم آليات التغيير في الـ Software

فيه أربع أسباب للتغيير في أي Software :

  • أول سبب بيدعونا للتغيير في الـ Software هو ان احنا نضيف Feature جديدة زي مثلا لو انطلب مننا نزود حاجة في التطبيق بتاعنا
  • تاني سبب هو ان احنا نـ Fix Bug موجودة فده هيتطلب حدوث تغيير في الـ Software
  • اما بالنسبة لتالت سبب فهو ان احنا نحسن من التصميم والهيكل بتاع الـ Software
  • ورابع سبب وهو الأخير هو ان احنا نعمل Optimisation للـ Resources زي مثلا نحسن من اداء الـ CPU / Memory

خلونا ناخد كل سبب من دول ونتعمق فيه شوية.


Adding Features and Fixing Bugs

هنبدأ بأول سببين وهم ان احنا نضيف Feature جديدة , ونـ Fix Bugs ,
اضافة خاصية جديدة في الـ Software من الحاجات الواضحة والـ Straightforward للتغير من الـ Software فبيكون عندنا Software ليه سلوك معين , بيتصرف بسلوك معين , والـ Users أو الـ Customers عاوزين يزودوا سلوك اضافي ..

فلو تخيلنا ان عندنا Web Application زي مثلا Eqraatech والمدير طلب مننا اننا نخلي الـ Logo ميبقاش ناحية اليمين يبقى الناحية التانية من الصفحة , ولما جينا نتكلم معاه اكتشفنا انه مش بالسهولة دي , ده كمان عاوز تغييرات تانية وهي انه يكون بيتحرك في الـ Release الجاية ..

طب هل يا ترى ده يعتبر اضافة Feature جديدة ؟ ولا يعتبر اننا بنـ Fix Bug ؟ .. الموضوع ده فيه تباين في وجهات النظر وضروري هنا نفهم عقلية الـ Business بتكون عاملة ازاي .. فمن وجهة نظر الـ Customer , هم عاوزين يحلوا المشكلة دي فدي بالنسبالهم مشكلة .. ولكن من منظور الـ Developer فالتغيير ده بالنسباله Feature جديدة

والموضوع مش بيكون بالوضوح والسهولة دي في بعض الأحيان في الشركات ولازم يكون فيه حد فاصل بين هو الـ Task اللي شغالين عليها دي يعتبر New Feature ولا Bug Fix لان بيتعملهم Tracking بشكل مستقل

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

أو بمعنى أصح ان السلوك بتاع الـ Software هيتغير , وفيه فرق كبير جدا بين اضافة سلوك جديد أو تغيير وتعديل سلوك قديم ..

فالسلوك بتاع الـ Software هي أكتر حاجة مهمة في الـ Software , فده اللي بيعتمد عليه الـ Users اصلا من البداية .. فالـ Users بيكونوا مبسوطين لما نضيف السلوك اللي هم محتاجينه , ولكن لو غيرنا من السلوك أو حذفنا سلوك قديم كانوا متعودين عليه وبدأ ده يعمل مشاكل فساعتها هيبطلوا يثقوا فينا ..

فلو جينا نرجع لمثال الـ Logo , نقدر هنا نوصل لحد فاصل من ناحية السلوك , لو احنا هنعدل ونغير في الـ Code فوارد جدًا التغيير ده يؤدي لتغيير في السلوك , ولكن لو احنا بنزود Code جديد والـ Code ده بيتنادى عليه في مكان معين , فاحنا غالبًا كده بنزود سلوك جديد .. فانا لو زودت Function في الـ Codebase ده ميعتبرش تغيير من السلوك أو اضافة سلوك طالما مفيش Caller ليها بيعمل Affect على السلوك الحالي


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

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

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

فلو جينا نبص على المثال ده هنلاقي ان عندنا Class اسمها CD Player وفيه Method واحدة بس اسمها addTrackingListing والـ Method دي بتتيح لينا ان احنا نضيف Track Listing.

ولكن تعالوا نبص كده على التغيير ده:

باه فيه دلوقتي Method تانية كمان اسمها replaceTrackListing .. طب هل اضافة الـ Method دي يعتبر سلوك جديد للتطبيق ؟ ولا تغيير فيه ؟ في الحقيقة لا ده ولا ده .. ولان زي ماوضحنا اضافة الـ Method ملوش أي تأثير طالما الـ Method دي ملهاش Caller نقدر نفهم منه ايه اللي بيحصل ..

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

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

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