एक बड़ा जावा/जे 2 ई वेब एप्लिकेशन ऑडिट करने में सबसे अच्छा तरीका क्या है

Question

मुझे एक बड़े वेब जावा/जे 2ee एप्लिकेशन का ऑडिट करना है जो कई वर्षों में विकसित हुआ है। यह किसी अन्य कंपनी द्वारा लिखा गया है, जिसे मैं काम नहीं कर रहा हूं। में यह वर्तमान स्थिति विकसित करना और बनाए रखना मुश्किल हो गया है, नया कार्यक्षमताओं को जोड़ना कठिन होता है और अक्सर उत्पादन में दिखाई देने वाली बग का कारण बनता है। ऐसा लगता है कि कुछ प्रतिलिपि/चिपका हुआ कोड है जिसके परिणामस्वरूप कोड डुप्लिकेशन है। वर्तमान ऐप कुछ प्रकार की ऑनलाइन शॉपिंग है जिसमें कुछ सीएमएस जैसी सामग्री है और वहां। यह ज्यादातर स्ट्रैट्स और कोड के नए हिस्सों में कुछ वसंत है, शायद अच्छे उपाय के लिए कुछ ejbs फेंक दिया गया है। कुछ यूनिट परीक्षण उपलब्ध हैं, लेकिन उनमें से बहुत कुछ नहीं। ये बातें हैं जिन्हें मैंने बताया है, मैंने अभी तक वास्तविक कोड नहीं देखा है।

मेरी कंपनी आदेश, जटिलता को कम गुणवत्ता और प्रतिरूपकता में सुधार, और यह प्रतिगमन के बिना आसान नई कार्यक्षमताओं जोड़ने के लिए संभव बनाने के लिए में इस एप्लिकेशन के कुछ हिस्सों के पुनर्लेखन के लिए एक प्रस्ताव कर देगा। कोई प्रतिबद्धता करने से पहले, वे मौजूदा कोड की गुणवत्ता के की कुछ तरह की प्रशंसा करना चाहते हैं और यह मानने के लिए कि क्रम में इसका अनुमान लगाने के लिए कितना अनुमान लगाया जा सकता है, किया - पूर्ण पुनर्लेखन या आंशिक फिर से लिखें।

पकड़ यह है कि मुझे इसे बहुत ही कम अवधि (कुछ दिनों) में करना होगा, इसलिए मैं इतनी कम समय में क्या किया जा सकता है, इसके लिए एक योजना तैयार करने की कोशिश कर रहा हूं। क्या मैं कर रहा हूँ thiking है:

• जांच "बुनियादी" बातें - अपवाद उपचार, प्रवेश करने
• जांच लेयरिंग (विचारों, नियंत्रक, दाव परत) के स्तर
• की वास्तविक कवरेज को मापने इकाई
• शायद परियोजनाओं
• पर कुछ Checkstyle, FindBugs और PMD चलाने का परीक्षण करती है ...

तो वास्तविक सवाल क्या अन्य बातों के श है क्या मैं खाता/चेक/उपाय/आदि ले सकता हूं?

मुझे यकीन नहीं है कि मैं किस प्रकार की संख्या से बाहर निकल सकता हूं और यदि इसका मतलब वास्तव में कुछ होगा, तो मुझे यह महसूस हो रहा है कि प्रबंधन क्या पूछ रहा है यह गलत है दृष्टिकोण, तो दूसरा प्रश्न होगा: क्या किसी के पास एक बेहतर विचार है?

मैं इस पर किसी भी विचार, सुझाव, टिप्पणी की सराहना करता हूं।

संपादित करें: मैं मिश्रण करने के लिए दो मृत कोड डिटेक्टरों जोड़ने होंगे: UCD और DCD

Answer 1

मेरे पास आपके जैसी समान सेटिंग्स वाले दो वेब एप्लिकेशन थे। मैंने FindBugs और Checkstyle का उपयोग करना बंद कर दिया क्योंकि उन्होंने 10.000 से अधिक समस्याग्रस्त बिंदु दिखाए। आवेदन जेडीबीसी स्तर डेटा उपयोग, प्रस्तुति के लिए जेएसपी और अनुरोध प्रेषण के लिए एक कस्टम ढांचे का इस्तेमाल किया। सौभाग्य से मेरे लिए, इन निम्न स्तर की सेटिंग्स ने मुझे मध्यम कठिनाई पर एक्सटेंशन और फिक्स करने की अनुमति दी। 3 साल की परियोजना के दौरान, मूल कोड का लगभग 20% ही बना रहा। जल्द या बाद में सब कुछ बदलना, प्रतिस्थापित या हटाया जाना चाहिए (और अंततः मैं FindBugs और Checkstyle का उपयोग करने में सक्षम था)।

हमें भी पूरी तरह से पुनर्लेखन की दुविधा का सामना करना पड़ा। हालांकि, इसके खिलाफ कई कारक थे:

• सुनिश्चित नहीं है कि ग्राहक एक पूर्ण पुनर्लेखन के लिए भुगतान करेगा।
• कार्यात्मक और तकनीकी दस्तावेज़ीकरण की कमी पूरी तरह से पुनर्लेखन करने के लिए जोखिम भरा बनाता है।
• मैनहोर पूरी तरह से पूर्ण आवेदन को समझने के लिए बहुत अधिक था। ग्राहक जल्द ही अनुरोधित परिवर्तन चाहता था।
• उपयोगकर्ता जहां प्रस्तुति और पृष्ठ व्यवहार के लिए अनुकूलित किया गया है। पुराने कार्यों के लिए उपयोगकर्ताओं को एक नया इंटरफेस उपयोग करने के लिए मनाने के लिए मुश्किल लग रहा था।
• यदि हम एक पूर्ण पुनर्लेखन करते हैं, तो हमें पूर्ण दस्तावेज प्रदान करने की आवश्यकता है। अपडेट के लिए, हमें केवल हमारे हिस्से को दस्तावेज करने की आवश्यकता थी।
• यदि प्रोग्राम काम करता है (अधिक या कम)
• कंपनी के अपने पीएमडी नियम थे और कोड पास नहीं हुआ था, तो प्रबंधन को (स्वयं और ग्राहक) को पुनर्लेखन करना मुश्किल है। यह तर्क देना आसान था कि नए हिस्सों में परीक्षण पास हो गया है।

यह वास्तव में आप जो करना चाहते हैं उसे उबालता है।

क्या आप जटिलता के बावजूद फिर से लिखना चाहते हैं?

• कोड कीड़े पर जोर दें। बहुत सारे लाल रंग के साथ बड़े पाई चार्ट दृढ़ विश्वास रखते हैं।
• कार्यक्रम गुणों को समझाएं और वे कॉर्पोरेट दृष्टि में कैसे फिट नहीं होते हैं।
• वर्तमान आवश्यकताओं से परे वृद्धि विकल्प दिखाएं और वर्णन करें कि वर्तमान संस्करण चुनौती तक कैसे नहीं है।
• असली उपयोगकर्ताओं के साथ साक्षात्कार करें। वे वर्तमान संस्करण के साथ महत्वपूर्ण समस्याओं को इंगित कर सकते हैं।
• सस्ते बनें लेकिन एक अच्छा अनुमानक बनें। रखरखाव चरण तक आप कुछ लागतों में देरी कर सकते हैं।

आप फिर से लिखना नहीं चाहते हैं?

• लागत पर जोर दें, विशेष रूप से ग्राहक से सबकुछ फिर से जांचने के लिए आवश्यक मैनहोर।
• कार्यक्षमता तोड़ने की संभावित परेशानी को इंगित करें।
• एक पूर्णकालिक दस्तावेज़ लेखक के लिए पूछें।

यदि आप कोड का स्वाद लेना चाहते हैं, तो हैलो वर्ल्ड जोड़ने का प्रयास करें! आवेदन के लिए समारोह/स्क्रीन। यह बताता है कि आप नई चीजों को कितनी मेहनत कर सकते हैं और कितनी तेजी से लागू कर सकते हैं।

Answer 2

मैं अपनी सूची काफी बहुत पसंद है। मुझे लगता है कि आपके पास शुरू करने के लिए हमले की एक उत्कृष्ट योजना है।

मैं स्प्रिंग या ईजेबी 3.0 पर मानकीकृत करने की आंखों को देखता हूं लेकिन दोनों नहीं।

मैंने इसे खुद नहीं पढ़ा है, लेकिन मुझे आश्चर्य है कि माइकल फेदर्स की पुस्तक "Working Effectively With Legacy Code" में कोई अच्छा विचार है?

अद्यतन:

हो सकता है कि आप एक स्वचालित निर्माण और सतत एकीकरण पर उन्हें रख कर बातें मदद कर सकते हैं - क्रूज नियंत्रण, हडसन, या टीम सिटी। अगर आपको कोई रिफैक्टरिंग करना है तो इससे मदद मिलेगी।

Answer 3

आप रखरखाव और विस्तारशीलता पर ध्यान केंद्रित कर रहे हैं जो स्पॉट पर है।

मैं इस परियोजना को रीबूट करने में कितना समय ले रहा हूं, यह देखकर जोड़ूंगा। क्या वे स्रोत नियंत्रण का उपयोग करते हैं? क्या उनके पास एकीकरण और उपयोगकर्ता स्वीकृति परीक्षण के लिए अलग-अलग वातावरण हैं? क्या कोई बिल्ड सर्वर है?

जब आपको पहले सुधार से दो महीने पहले खर्च करना पड़ता है तो किसी को ग्राहक की उम्मीदों को पहले से प्रबंधित करने की आवश्यकता होती है।

Answer 4

वास्तव में वे एक पूर्ण पुनः लेखन के लिए भुगतान नहीं करेंगे, क्योंकि:

• यह मंदी है, तो आप की लागत खरोंच से यह पुनर्लेखन अधिक होगा

• वे बेचने की कोशिश कर रहा हो सकता है कंपनी जल्द से जल्द

• प्रबंधन सॉफ्टवेयर विकास के बारे में कुछ भी समझ नहीं है

मैं पहली बार कुछ सरल तथ्यों के साथ जाना होगा:

• के रूप में आप FindBugs और अंत में PMD योजना बनाई परियोजना
• रन की SLOC प्रदर्शित करने के लिए एक उपकरण का उपयोग करें, बस दोष अनुमान लगाने के लिए
• एक त्वरित रूपरेखा क्या सत्र
• विभिन्न परतों की जाँच करें
• संसाधनों आम तौर पर बंद हो जाती हैं, तो (स्ट्रीम, हाइबरनेट या JDBC कनेक्शन, आदि) देखें
• देखने के लिए कि प्रौद्योगिकियों का उपयोग किया जाता है कि वे (EJBs, वेब सेवा, आदि जहां लागू नहीं है)
• देखें कि वे किस तरह अपवाद को संभालने और प्रवेश करने
• देखें पर्याप्त अमूर्त
• हो, तो बहुत अधिक या नहीं अगर आप कुछ आधार वर्ग जोड़ सकते हैं कोड दोहराव को कम करने के लिए

कोशिश की एक त्वरित आरेख आकर्षित करने के लिए देखें आवेदन की वास्तुकला, अगर वे आपको इसके बारे में कोई दस्तावेज नहीं देते हैं।

कुछ आंकड़े और कुछ तथ्यों को इकट्ठा करें, एक रिपोर्ट लिखें और उन्हें कंपनी को भेजें। वे लागत को कम करना चाहते हैं और वे आपको फिक्सिंग कोड से बचने के लिए कहेंगे जो टूटा नहीं है। आप आंकड़ों के साथ शुरू करते हैं, फिर तथ्यों और कोड प्रभावित/मूल्य निर्धारण के समय/अनुमानित प्रतिशत के साथ एक प्रस्ताव।

आमतौर पर विरासत स्ट्रेट्स अनुप्रयोग बनाए रखने के लिए एक पिटा होते हैं, ऐसा किया जाता है। अगर यह आपके काम का हिस्सा नहीं था, तो मैं कहूंगा कि इसे जाने दो। यदि आप "स्टैंडअलोन" पृष्ठों पर आते हैं जिनमें कई टेम्पलेट्स शामिल नहीं हैं और कई बदलावों के अधीन हैं, तो उन्हें किसी अन्य तकनीक के साथ फिर से लिखने का प्रस्ताव दें।