ما هو الكود القديم وكيفية العمل معه
المصدر: Dou عاجلاً أم آجلاً، من المحتمل أن يواجه المبرمج كودًا قديمًا. ولتخفيف عواقب هذا التعارف، اخترت بعض النصائح والأمثلة العملية من تجربتي الخاصة - على وجه الخصوص، العمل مع نظام جافا القديم.الميزات القديمة
Legacy هو رمز شخص آخر، وهو غالبًا ما يكون فظيعًا لدرجة أنه ليس من الواضح بشكل عام كيفية التعامل معه. وإذا كان عليك العمل مع نظام قديم، فبالإضافة إلى الكود القديم، ستواجه أيضًا ما يلي:- مع التكنولوجيا التي عفا عليها الزمن.
- بنية غير متجانسة
- نقص أو حتى الغياب التام للوثائق.
-
لا يمكننا عدم احترام النظام الذي يجني الملايين أو يصل إليه آلاف الأشخاص يوميًا. بغض النظر عن مدى سوء كتابته، فقد نجح هذا الكود المثير للاشمئزاز في الإنتاج ويعمل على مدار الساعة طوال أيام الأسبوع.
-
وبما أن هذا النظام يجلب أموالاً حقيقية، فإن العمل معه يأتي بمسؤولية كبيرة. هذه ليست شركة ناشئة، ولكنها شيء سيعمل عليه المستخدمون غدًا. وهذا يعني أيضًا تكلفة عالية جدًا للخطأ، والنقطة هنا ليست في مطالبات العميل، ولكن في الوضع الحقيقي للأمور.
الهندسة العكسية
للعمل بنجاح مع التعليمات البرمجية القديمة، سيتعين عليك استخدام تقنيات الهندسة العكسية. أولاً، تحتاج إلى قراءة التعليمات البرمجية بعناية لفهم كيفية عملها بالضبط. وهذا أمر إلزامي، لأننا على الأرجح لن يكون لدينا وثائق. إذا لم نفهم سلسلة أفكار المؤلف، فسوف نقوم بإجراء تغييرات ذات عواقب غير متوقعة. لحماية نفسك من هذا، تحتاج أيضًا إلى الخوض في الكود المجاور. وفي الوقت نفسه، لا تتحرك فقط في العرض، ولكن أيضا في العمق. أين يتم استدعاء الطريقة مع الخطأ؟ ومن أين يأتي الكود الذي يستدعيه؟ في المشروع القديم، يتم استخدام "التسلسل الهرمي للمكالمات" و"التسلسل الهرمي للأنواع" أكثر من أي شيء آخر. سيتعين عليك قضاء الكثير من الوقت مع مصحح الأخطاء: أولاً، للعثور على الأخطاء، وثانيًا، لفهم كيفية عمل كل شيء. أما بالنسبة للتوثيق، فلن يكون اللجوء إلى علم الآثار الصناعية فكرة سيئة. قد يكون من المفيد جدًا البحث عن الوثائق القديمة في مكان ما والتحدث مع أولئك الذين يتذكرون كيفية كتابة الكود الذي ورثته. باستخدام هذه التقنيات، ستبدأ عاجلاً أم آجلاً في فهم الكود بشكل أو بآخر. ولكن لكي لا تذهب جهودك هباءً، يجب عليك توثيق نتائج بحثك على الفور. للقيام بذلك، أوصي برسم المخططات الكتلية أو المخططات التسلسلية. بالطبع، سوف تكون كسولًا، لكنك بالتأكيد بحاجة إلى القيام بذلك، وإلا خلال ستة أشهر بدون توثيق، سوف تقوم بالتنقيب في هذا الرمز كما لو كانت المرة الأولى.لا تعيد كتابة الكود
أهم شيء في عملية التطوير هو التغلب على نفسك في الوقت المحدد وعدم محاولة إعادة كتابة الكود بالكامل من الصفر. قم بتقدير عدد سنوات العمل التي سيتطلبها ذلك. من غير المحتمل أن يرغب العميل في إنفاق الكثير من المال على إعادة عمل شيء يعمل بالفعل. وهذا لا ينطبق فقط على النظام ككل، ولكن أيضًا على أي جزء منه. بالطبع، قد يعطونك أسبوعًا لمعرفة كل شيء، وأسبوعًا آخر لإصلاح شيء ما. لكن من غير المرجح أن يمنحك شهرين لكتابة جزء من النظام مرة أخرى. بدلاً من ذلك، قم بتنفيذ الوظيفة الجديدة بنفس نمط بقية التعليمات البرمجية. بمعنى آخر، إذا كان الكود قديمًا، فلا يجب أن تميل إلى استخدام تقنيات جميلة جديدة: سيكون من الصعب جدًا قراءة مثل هذا الكود. على سبيل المثال، قد تواجه موقفًا مثل ما واجهناه: جزء من النظام مكتوب في Spring MVC، وجزء مكتوب في servlets العارية. وإذا كان هناك حاجة إلى إضافة شيء آخر إلى جزء مكتوب في servlets، فإننا نضيفه بنفس الطريقة - في servlets.احترام المصالح التجارية
يجب أن نتذكر أن أي مهام يتم تحديدها أولاً وقبل كل شيء حسب القيمة بالنسبة للعمل. إذا لم تثبت للعميل الحاجة إلى تغييرات معينة من وجهة نظر العمل، فلن تحدث هذه التغييرات. وحتى تقنع العميل عليك أن تحاول الوقوف مكانه وتفهم اهتماماته. على وجه الخصوص، إذا كنت تريد إعادة البناء لمجرد صعوبة قراءة الكود، فلن يُسمح لك بذلك، وسيتعين عليك التعايش معه. إذا كنت لا تستطيع تحمل ذلك حقًا، فيمكنك إعادة تنظيم الكود بهدوء وشيئًا فشيئًا، ونشر العمل عبر تذاكر العمل. أو إقناع العميل بأن هذا، على سبيل المثال، سوف يقلل من الوقت اللازم للعثور على الأخطاء، وبالتالي يقلل التكاليف في النهاية.امتحان
من الواضح أن الاختبار ضروري في أي مشروع. ولكن عند العمل مع الأنظمة القديمة، يجب إيلاء اهتمام خاص للاختبار أيضًا لأن تأثير التغييرات التي يتم إجراؤها لا يمكن التنبؤ به دائمًا. ستحتاج إلى عدد من المختبرين على الأقل مثل عدد المطورين، وإلا فيجب أن تكون جيدًا بشكل لا يصدق في الأتمتة. في مشروعنا، يتكون الاختبار من المراحل التالية:- التحقق، عندما يتم فحص الوظيفة المنفذة لميزة ما في فرع منفصل.
- التثبيت، عندما يتم التحقق من فرع الإصدار الذي يتم فيه دمج جميع الميزات معًا.
- الشهادة، عندما يتم تشغيل نفس الشيء مرة أخرى في حالات اختبار مختلفة قليلاً في بيئة اعتماد تكون أقرب ما يمكن إلى الإنتاج من حيث خصائص الأجهزة وتكوينها.
إضفاء الطابع الرسمي على DevOps والإصدار
يمكن أن تكون إجراءات الإصدار، على سبيل المثال، على النحو التالي. عند اكتمال التطوير واستكمال مرحلتين أو ثلاث مراحل اختبار، نكتب بريدًا إلكترونيًا إلى فريق DevOps قبل 36 ساعة من وقت الإصدار المتوقع. بعد ذلك، نتصل بفريق المطورين ونناقش جميع التغييرات في البيئات (نبلغهم بجميع التغييرات في قاعدة البيانات والتكوين). لكل تغيير لدينا وثيقة (تذكرة في جيرا). بعد ذلك، أثناء الإصدار، يجتمع جميع المشاركين في هذا معًا، ويقول الجميع ما يفعلونه الآن: "لقد قمنا بتحميل قاعدة البيانات"، "لقد أعدنا تشغيل خوادم كذا وكذا"، "لقد ذهبنا لإجراء اختبارات الانحدار في بيئة الإنتاج. " إذا حدث خطأ ما، فسيتم إطلاق إجراء التراجع عن الإصدار، الموصوف بدقة في مستند الإصدار الأصلي - بدون مثل هذا المستند، سننسى بالتأكيد شيئًا ما أو نشعر بالارتباك.التحكم في جودة الكود
وأخيرًا، تعد مراجعة التعليمات البرمجية ممارسة لا يتم استخدامها لسبب ما في جميع المشاريع. من الرائع أن تتم مراجعة كل جزء من التعليمات البرمجية بواسطة أكثر من شخص واحد. حتى في فريق قوي جدًا، يتم اكتشاف بعض الأخطاء دائمًا أثناء عملية مراجعة التعليمات البرمجية، وإذا نظر إليها العديد من الأشخاص، يزداد عدد الأخطاء التي تم تحديدها. علاوة على ذلك، في بعض الأحيان يجد المراجع الثالث أو الرابع أسوأ شيء.الأدوات التي تجعل كتابة الوثائق الفنية أسهل
المصدر: Dzone لا يحب معظم المبرمجين كتابة الوثائق الفنية. حتى أن خبير علم النفس جيرالد واينبرج وصف التوثيق بأنه "زيت الخروع للبرمجة": يحب المطورون قراءته، لكنهم ببساطة يكرهون كتابته بأنفسهم.![استراحة القهوة رقم 20. ما هو الكود القديم وكيفية العمل معه. الأدوات التي تسهل كتابة الوثائق الفنية - 2](https://cdn.javarush.com/images/article/16851fcd-a74b-4626-bd47-0abf38e559be/800.webp)
GO TO FULL VERSION