هذا هو الجزء الثاني من سلسلة (التعامل بفاعلية مع الكود الموروث). يمكنك الاطلاع على الجزء الأول من هنا. نتحدث في هذه السلسلة عن بعض النصائح التي تُساعد المبرمج لدى التعامل مع الشيفرات المصدرية التي كتبها قبله مبرمجون آخرون.

Changing Software تغيير الكود

في بداية تعلمنا للبرمجة، نبدأ بكتابة برامج قصيرة ينتهي العمل عليها بانتهاء الهدف من كتابتها، مثل تعلم الأساسيات أو تطبيق فكرة لإثبات أنها تعمل – proof of concept. ويمكننا القول بأن الوضع الطبيعي اليومي في حياة أي مبرمج أنه يقوم بالتعديل على الكود، أكثر من الاستمرار في كتابة كود جديد دون تغيير القديم.

هذه المقالة هي الثانية في سلسلة تلخيص كتاب التعامل بفعالية مع الكود الموروث . سنتحدث عن مصطلحات و أسباب تغيير الكود وما الدلالات التي يجلبها تغيير الكود.

أسباب تغيير الكود

يمكننا أن نلخصها بأربع نقاط :

1. إضافة ميزات جديدة للبرنامج – Adding features
2. إصلاح مشكلة –  Fixing bugs
3. تطوير تصميم الكود – Design improvement
4. تحسين في استخدام الموارد – Optimizing resources usage

Adding features – إضافة ميزة جديدة

هو أكثر سبب وارد الحدوث من أسباب تغيير الكود. وطبعا هناك فرق كبير بين إصلاح Bug أو تعديل ميزة قديمة في البرنامج و بين إضافة ميزة جديدة كليا، من يحدد الفرق بينها هو الطريقة التي يعمل بها البرنامج أي ال behaviour بعد هذا التعديل.

Design improvement – تطوير تصميم الكود

من ميزات تطوير تصميم الكود :

• لا يجب أن تتغير الطريقة التي يعمل بها البرنامج
• والنتائج قبل تطوير تصميم الكود و بعده يجب أن تبقى كما هي.

و في حال التغير في عمل البرنامج يعتبر هذا التغير Bug. لذا يعتبر ال Design improvement حالة حرجة التي يحاول أكثر المبرمجون تجنبها لأنها غالبا ما تنتهي بقائمة من ال Bugs إذا كان تصميم الكود ضعيف. 

عملية تطوير تصميم الكود من دون تغيير الطريقة التي يعمل بها البرنامج تسمى بال Refactoring. إذ يكمننا جعل التصميم أسهل للتطوير في المستقبل .

ال refactoring ليس عملية تنظيف للكود، هو تغييرات في تصميم الكود – structure modifications- ولكن كيف نضمن أن الطريقة التي يعمل بها البرنامج  لن تتغير عندما ننتهي من عملية ال Refactoring؟

للعمل باحترافية يجب أن يسبق مرحلة ال Refactoring مرحلة كتابة tests قدر المستطاع. تغطي هذه ال tests أكبر جزء ممكن من الكود القديم ونتأكد من أن هذه ال tests تعكس الطريقة التي يجب أن يعمل بها البرنامج. وبعد عملية ال Refactoring يجب أن تؤكد هذه ال tests لنا أن البرنامج ما زال يعمل كما يجب. تلعب هذه ال tests دور العقد المبرم بين المبرمج و الكود، و كما قلنا في المقال الأول، في هذه النقطة بالذات فإن أكواد التجربة tests هم فعلا أصدقاؤنا الحقيقون.

عملية ال Refactoring بدون كتابة Tests هو تصرف يجلب عواقب. وتذكر دائما تسلق الجبال بدون حبال نجاة وبدون حظ ربما يجلب نتائج خطيرة. الأمر ليس سهل بسهولة سرده في هذه المقالة، لكنه يحمي المبرمج من الوقوع في مشاكل لا مفر منها.

ال Refactoring  هي عملية تطوير تصميم الكود من دون تغيير ال behaviour. 

Optimizing – التحسينات على الكود

تشبه لحد ما عملية Refactoring مع اختلاف الهدف من العملية. إذ أن كلاهما يبقيان البرنامج يعمل بالطريقة نفسها قبل هذه الخطوة. ولكن :

• يتحسن تصميم الكود في الـ Refactoring
• ويتحسن استخدام الموارد في ال optimization كأن يستهلك البرنامج ذاكرة وبطارية أقل.

الصورة العامة

تغيير الكود يجب أن يكون الهدف منه أحد مما يلي : بنية الكود – structure , الطريقة التي يعمل بها الكود – functionality , أو الموارد – resources changes.

ما الهدف مما سبق ؟

الهدف من كل ما سبق هو معرفة أين يجب أن يتجه تركيزنا عند البدء بتغيير الكود. والأهم هو معرفة ما هو الخط الأحمر أي ما الذي يجب أن لا يتغير أبدا, وهذه ليست بالمهمة السهلة.

كما أن فهم ما سبق يعطينا بعض المؤشرات التي تدل على جودة تصميم نظام برمجي أو سوءه. سهولة فهم الكود والشعور بالثقة للقيام بأي تغيير بغض النظر عن كبر الكود و حساسية المهام التي يقوم بها البرنامج دليل على جودة التصميم البرمجي. أما في البرمجيات سيئة التصميم, فإن تغيير جزء من الكود يشبه القفز بين قمم الجبال لتجنب الحيوانات المفترسة ويجد المبرمج نفسه بتجنب هذه التغييرات مخافة الوقوع في الأخطاء.

لربما تبدو كل هذه التعريفات مجرد مصطلحات نظرية. هذا صحيح, ولكن أن تكون كمبرمج على معرفة بالمعنى الصحيح لهذه المصطلحات يساهم بطريقة ما يجعلك مختلف عن باقي المبرمجين الذين يخلطون هذه المفاهيم و هي بعيدة كل البعد عن بعضها. الإلمام بهذه المصطلحات ستسهل عليك محادثاتك مع مبرمجين محترفين اخرين يعرفون فعلا عما يتحدثون.

برأيي الشخصي, كتابة الكود ليس بالأمر الصعب. المهمة الأصعب و الأمتع هي تطوير البرمجيات واحترافها. وهذه  المصطلحات هي أدوات مساعدة.

المصدر: التعامل بفعالية مع الكود الموروث 2 – تغيير الكود