في هذه الصفحة
المقدمة
التغييرات اللي بتتم في أي نظام ممكن تتم بطريقتين أساسيتين , ممكن نقول عليهم Edit and Pray أو Cover and Modify .. ولسوء الحظ الـ Edit and Pray هي نوعا ما الـ Standard , طب ايه هم الطريقتين دول , ده اللي هنتكلم عنه في الـ Chapter ده بشكل أساسي ..
Edit and Pray
الطريقة الأولى اللي هي Edit and Pray بكل بساطة معناها , ان قبل ما بتعمل تغييرات في الـ System بتعمل خطة كويسة بعناية للتغييرات دي وبتتأكد انك فهمت الـ Code كويس اللي محتاج تغير وتعدل فيه , وبتبدأ بعد كده تعمل التغييرات بتاعتك.
ولما بتخلص، بتدعي ربنا ان ما يكونش فيه مشاكل وانت بتراقب التغييرات بتاعتك والسلوك بتاعها بقى عامل ازاي .. وبالتأكيد بتاخد وقت اضافي لانك بتتأكد انك اللي عملته صح وتم بشكل مظبوط.
وبالتأكيد لو جينا عملنا اسقاط للمثال اللي قولناه على الجراح , فبالتاكيد مش هنحب اننا نختار الجراح اللي يعملنا العملية انه يكون شغال بسكينة زبدة بدل المشرط
ونقول ان معلش اصل هو بيشتغل بعناية , فالعناية لوحدها في الشغل مش هتكون كفاية لو ما استعملناش الـ Tools والـ Techniques الصح.
Cover and Modify
اما بالنسبة للطريقة التانية اللي هي Cover and Modify , فهي طريقة مختلفة لعمل التغييرات , والفكرة هنا بتكمن انه ممكن نشتغل بشكل آمن عادي جدًا واحنا بنغير في الـ Software.
فعملية الـ Covering في الـ Software بكل تاكيد معناها اننا نعمل Cover ليه بالـ Tests , فلو احنا عندنا مجموعة من الـ Tests الكويسة اللي بتحيط بالـ Code اللي عاوزين نغيره او نعدل فيه , ممكن بكل تأكيد وبسرعة جدًا نعمل التغييرات اللي عاوزينها وكمان نكتشف تأثيرها بالايجاب والسلب بسرعة , مع العلم اننا برضو لسه بنعمل ده بعناية ولكن هنا الفرق ان بيجيلنا Feedback.
فلو عملنا التغيير وكان كويس هنلاقي ان الـ Tests شغالة كويسة , ولكن لو فيه Test واحدة ما ادتش نفس النتيجة اذن هنعرف من الـ Feedback ده ان فيه مشكلة.
تعالوا نشوف مع بعض المثال ده : وليكن احنا عاوزين نعمل تغيير في Function طويلة جدا ومعقدة , ومن حسن الحظ كان فيه Unit Tests موجودة , وآخر ناس لمست الـ Function دي كانوا كاتبين مجموعة من الـ Tests وليكن 20 Unit Test واهتموا بيها جدًا.
لما بنيجي نشغلهم بنلاقي ان هم كلهم بيعملوا Pass وبالتالي بنبدأ نشوف الـ Unit Tests دي ونفهم السلوك بتاع الـ Function دي .. ولما بيجي الوقت اننا نعمل التغيير بتاعنا بندرك وقتها ان الموضوع نوعا ما صعب , وده لان الـ Code مش واضح.
تقدروا دلوقتي تشتركوا في النشرة الأسبوعية لاقرأ-تِك بشكل مجاني تمامًا عشان يجيلكوا كل جديد بشكل أسبوعي فيما يخص مواضيع متنوعة وبشروحات بسيطة وسهلة وبجودة عالية 🚀
النشرة هيكون ليها شكل جديد ومختلف عن شكلها القديم وهنحاول انها تكون مميزة ومختلفة وخليط بين المحتوى الأساسي اللي بينزل ومفاجآت تانية كتير 🎉
Eqraatech - اقرأ-تِك
ومحتاجين نفهمه أكتر وبشكل أفضل قبل ما نعمل أي تعديل او تغيير عليه, وده متوقع لان الـ Unit Tests طبيعي متبقاش مغطية تفاصيل التفاصيل , بس احنا برضو محتاجين نفهم الـ Code كويس اوي بحيث يكون عندنا ثقة بالتغييرات اللي هنعملها ..
وبرضو محتاجين اننا ما نخليش أي حد بعدنا يجي يتعامل مع الـ Code يقع في نفس المشكلة اللي احنا واقعين فيها دلوقتي , ولا حتى احنا بنفسنا بعدين لان ده هيضيع وقتنا ووقت أي حد تاني هيجي يغير او يعدل في الجزء ده.
طب نعمل ايه ؟ بنبدأ هنا نعمل Refactor للـ Code واحدة واحدة , بنبدأ نعمل مثلا Extract لبعض الـ Methods وننقل بعض الـ Conditional Logic وبعد كل تغيير طفيف بنروح نعمل Run للـ Unit Tests عشان نتأكد اننا ماشيين مظبوط.
ولما بنخلص Refactoring , بيكون الـ Code وقتها أفضل كتير و Cleaner وبنكون فهمنا هو بيعمل ايه , فبالتالي وقتها اما نيجي نعمل تغيير بنكون واثقين بنسبة كبيرة من التغييرات بتاعتنا , وبرضو بنزود Unit Tests عشان نتاكد ان السلوك بتاعنا شغال مظبوط بالإضافة لاننا بنعرف من الـ Unit Tests القديمة اذا كنا غيرنا في السلوك القديم ولا لا .. وبالتالي هنا موضوع الـ Feedback اللي بيجيلنا بيكون مهم جدًا.
