كيفية التغلب على التعليمات البرمجية القديمة

في مرحلة ما من حياتك المهنية كمطور ، سوف يسلمك رئيسك في العمل جزءًا من التعليمات البرمجية القديمة - رمز كتبه شخص آخر منذ فترة طويلة. سيخبرك رئيسك في العمل بتعلم هذا الرمز القديم وإصلاحه وإضافة ميزات جديدة إليه.

لقد كنت في هذا الموقف عدة مرات خلال العقدين الماضيين. يمكنني المساعدة.

كيف نفهم الكود القديم

إذا كنت محظوظًا ، فستحصل على وثائق ، أو على الأقل تعليقات مضمنة. ربما سيظل واحد أو اثنان من المؤلفين الأصليين موجودين للمساعدة. لكن في معظم الأوقات ، لن تكون محظوظًا جدًا.

لنتحدث عما ستفعله في تلك الحالات غير المحظوظة.

أولا ، عليك أن تكون متواضعا. احترم الكود والمطورين الذين كتبوه.

من السهل النظر إلى العمل الذي سبقك وتقرر أنه ليس جيدًا وأنه يمكنك القيام بعمل أفضل. هذا هو الموقف الخاطئ. سوف يقودك إلى طريق خطير للغاية.

إذا اتبعت هذا المسار الخطير ، فستبدأ في إجراء تغييرات قبل فهم تأثير هذه التغييرات بشكل صحيح. ستقوم "بإصلاح" الأشياء التي لم يتم كسرها ، لأنها مكتوبة بأسلوب لا تحبه ، أو تستند إلى طريقة قديمة للقيام بالأشياء. في النهاية ، سوف تضيع وقتًا لا يُصدق مع هذا الموقف.

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

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

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

لا تقم بإفراغ قاعدة التعليمات البرمجية الخاصة بك.

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

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

أثناء تقدمك ، ارسم مخطط تسلسل للمساعدة في توضيح ما يحدث. إذا لم تكن متأكدًا من ماهية مخطط التسلسل ، أو كيفية رسمه ، فراجع هذا البرنامج التعليمي المجاني. إذا لم يكن لديك أداة جيدة لرسم UML ، فإليك أداة مجانية.

بمجرد إكمال مخطط التسلسل الأول ، باستخدام نسخة محلية من قاعدة التعليمات البرمجية التي يمكنك استعادتها بسهولة ، ابدأ في إجراء تغييرات طفيفة على بعض المكونات التي واجهتها. تعرف على ما إذا كان يمكنك التنبؤ بآثار تغييراتك على التطبيق. هذه طريقة جيدة لاختبار فهمك.

استمر في تكرار هذه العملية ، مع الإضافة إلى المخططات الخاصة بك حتى تحصل على صورة كاملة للتطبيق بأكمله (أو على الأقل جميع الأجزاء التي تكون مسؤولاً عنها).

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

بشكل عام ، الشيء الأكثر أهمية هو التحلي بالصبر ، وتجنب ضرب نفسك. الكود شيء معقد. يستغرق فهم الكود القديم وقتًا. ابق هادئا.

كيفية إصلاح التعليمات البرمجية القديمة

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

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

بمجرد تشغيل التعليمات البرمجية الخاصة بك ، إذا كان لا يزال لديك متسع من الوقت ، يمكنك البدء في إجراء تحسينات صغيرة تدريجية.

لقد وضع Martin Fowler كتالوجًا لإعادة البناء سيعطيك فكرة جيدة عن أنواع التغييرات التي يمكنك إجراؤها لتحسين قاعدة الكود تدريجيًا. تحقق من ذلك هنا. الفكرة هي ترك الشفرة دائمًا في حالة أفضل مما كانت عليه عندما وجدتها.

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

هذا هو المكان الذي تصبح فيه الأشياء مشعرة. عليك أن تكون صادقًا مع نفسك بشكل وحشي بشأن الحد الأدنى من التغيير القابل للتطبيق. سيريد كل جزء من كيانك فصل الشفرة وإعادة كتابة كل شيء. لا تفعل ذلك!

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

لجعل هذا النهج يعمل حقًا ، تأكد من أنك دائمًا تضع تقديراتك لإتاحة الوقت لقليل من إعادة البناء.

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

مرة أخرى ، عليك أن تكون صادقًا جدًا مع نفسك بشأن تكلفة / فائدة إعادة الكتابة أو إعادة التصميم. عليك أن تقبل أنه ، في النهاية ، سيكون هذا قرارًا تجاريًا وليس قرارًا تقنيًا.

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

تذكر: إذا كنت تقوم بإصلاح شامل ، فتأكد أولاً من وجود دعم للتغيير وميزانية معقولة لمواكبة ذلك. لا تحاول أن تطير تحت الرادار بهذا. ما لم تكن ، بالطبع ، تستمتع بالمحادثات المحرجة مع الإدارة عندما تبدأ في كسر الأشياء وتفويت المواعيد النهائية.

كيفية إضافة ميزات جديدة إلى التعليمات البرمجية القديمة

أخيرًا ، ستتم مطالبتك في النهاية بإضافة ميزات إلى الكود القديم. في هذه المرحلة ، لديك قرار مهم عليك اتخاذه. هل "تسير مع تدفق" قاعدة الكود الحالية ، أم تأخذ الأمور في اتجاه جديد؟

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

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

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

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

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

لدى DO Factory شرح جيد لنمط المحول:

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

فيما يلي بعض الروابط لشروحات وأمثلة بلغات مختلفة.

  • مثال JavaScript لنمط المحول
  • C # مثال على نمط المحول
  • مثال جافا لنمط المحول

الماخذ الرئيسية

باختصار ، إليك النقاط الأساسية التي ستساعدك في معالجة أي قاعدة بيانات وقهرها في النهاية:

  1. لا تحكم مطلقًا على الكود القديم أو تغيره حتى تأخذ الوقت الكافي لفهمه تمامًا.
  2. مخططات التسلسل هي صديقك.
  3. تفضل التحسينات الصغيرة المتزايدة على عمليات إعادة الكتابة أو التغييرات بالجملة.
  4. يجب أن يحاول كل تغيير ترك الرمز أفضل قليلاً مما كان عليه عندما وجدته.
  5. إذا كنت بحاجة إلى إجراء تغييرات كبيرة ، فقم بإعداد دراسة جدوى واحصل على الموافقة أولاً.
  6. عند إضافة ميزات جديدة ، حاول "مواكبة التدفق".
  7. إذا كنت بحاجة إلى أخذ الرمز في اتجاه جديد ، فاعزل التغييرات واستخدم نمط المحول للتكامل.

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

تريد البرمجة بشكل أفضل؟ انضم إلى آلاف المطورين الذين يتلقون مقالات ومعلومات قيّمة مثل هذه مني كل أسبوع مجانًا . فقط اضغط هنا.