ما هو أفضل نهج في تدقيق تطبيق ويب Java/j2ee كبير

Question

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

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

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

• تحقق من الأشياء "الأساسية" - معالجة الاستثناءات والتسجيل
• تحقق من مستوى الطبقات (المشاهدات، وحدات التحكم، طبقة داو)
• قياس التغطية الفعلية لاختبارات الوحدة
• ربما قم بتشغيل بعض Checkstyle وFindbugs وPMD على المشاريع
• ...

لذا فإن السؤال الفعلي هو ما هي الأشياء الأخرى التي يجب أن آخذها في الاعتبار/التحقق/القياس/إلخ؟

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

سأقدر أي فكرة أو اقتراح أو تعليق على هذا.

يحرر:سأضيف اثنين من أجهزة كشف الشفرات الميتة إلى المزيج: UCD و DCD

Answer 1

كان لدي تطبيقان للويب بإعدادات مشابهة لإعداداتك.توقفت عن استخدام FindBugs وCheckstyle حيث أظهروا أكثر من 10.000 نقطة إشكالية.تستخدم التطبيقات الوصول إلى البيانات على مستوى JDBC وJSP للعرض التقديمي وإطار عمل مخصص لإرسال الطلب.ولحسن الحظ بالنسبة لي، سمحت لي هذه الإعدادات ذات المستوى المنخفض بإجراء الإضافات والإصلاحات على مستوى الصعوبة المتوسطة.خلال المشروع الذي دام 3 سنوات، بقي حوالي 20% فقط من الكود الأصلي كما كان.عاجلاً أم آجلاً، يجب تغيير كل شيء آخر أو استبداله أو إزالته (وأخيرًا تمكنت من استخدام FindBugs وCheckstyle).

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

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

إنه يتلخص في ما تريد القيام به في الواقع.

هل تريد إعادة الكتابة رغم التعقيد؟

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

لا تريد إعادة الكتابة؟

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

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

Answer 2

في الواقع، لن يدفعوا مقابل إعادة الكتابة بالكامل، للأسباب التالية:

• إنه الركود، وتكلفة إعادة كتابته من الصفر ستكون مرتفعة

• ربما يحاولون بيع الشركة في أسرع وقت ممكن

• الإدارة لا تفهم أي شيء عن تطوير البرمجيات

أود أولاً أن أذكر بعض الحقائق البسيطة:

• استخدم أداة لعرض SLOC للمشروع
• قم بالتشغيل كما خططت لـ FindBugs وفي النهاية PMD، فقط لتقدير العيوب
• قم بإجراء جلسة تعريف سريعة
• تحقق من الطبقات المختلفة
• معرفة ما إذا كانت الموارد مغلقة بشكل عام (التدفقات، أو السبات، أو اتصالات JDBC، وما إلى ذلك)
• معرفة ما إذا كانت التقنيات تُستخدم في الأماكن التي لا تنطبق عليها (EJBs، خدمات الويب، وما إلى ذلك)
• انظر كيف يتعاملون مع الاستثناءات والتسجيل
• معرفة ما إذا كان هناك الكثير من التجريد أم لا
• معرفة ما إذا كان بإمكانك إضافة بعض الفئات الأساسية لتقليل تكرار التعليمات البرمجية

حاول رسم رسم تخطيطي سريع لبنية التطبيق، إذا لم يعطوك وثيقة حول هذا الموضوع.

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

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

Answer 3

أنت تركز على قابلية الصيانة والتوسعة وهو أمر في محله.

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

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

Answer 4

أنا أحب قائمتك كثيرا.أعتقد أن لديك خطة هجوم ممتازة للبدء.

كنت أتطلع إلى التوحيد القياسي في Spring أو EJB 3.0 ولكن ليس كلاهما.

لم أقرأه بنفسي، لكني أتساءل عما إذا كان كتاب مايكل فيذرز "العمل بفعالية مع التعليمات البرمجية القديمة" لديه أي أفكار جيدة؟

تحديث:

ربما يمكنك مساعدة الأشياء من خلال وضعها في بناء آلي وتكامل مستمر - نظام تثبيت السرعة أو Hudson أو Team City.إذا كان عليك القيام بأي إعادة هيكلة فسوف يساعدك ذلك.