एक विरासत जावा सिस्टम सीखना

Question

मुझे विरासत जावा सिस्टम को बनाए रखने और पुन: सक्रिय करने के लिए काम सौंपा गया है। मैं वर्तमान में सी # और .NET करता हूं, हालांकि मैं जावा से परिचित हूं।

विरासत प्रणाली आरएमआई, क्लाइंट/सर्वर आर्किटेक्चर का उपयोग करती है और 1.4 जेवीएम के लिए डिज़ाइन की गई थी। यह यूआई के लिए उपयोग कर रहा है (जहां तक ​​मैं कह सकता हूं), स्विंग और एडब्ल्यूटी।

मेरा प्रश्न यह है: कोडबेज के साथ आने के लिए सबसे अच्छा तरीका क्या है जिसे मैंने अभी सौंप दिया है? मैं स्क्रीन के फ्लोचार्ट्स, आरएमआई कॉल के बीच सीमाओं को परिभाषित करने और यूनिट परीक्षण लिखने (टेस्ट करने योग्य बिट्स के लिए) सोच रहा हूं।

जब आप एक अपरिचित कोडबेस सौंपे जाते हैं तो स्थिति में आप क्या करते हैं?

धन्यवाद!

-Jarrod

Answer 1

पहली बात मैं किसी भी नए कोड मैं हाथ कर रहा हूँ के साथ क्या मौजूदा इकाई परीक्षण को देखने के लिए है। नए परीक्षण लिखना आम तौर पर दूसरी बात है।

Answer 2

आरएमआई के साथ जावा 1.4 विरासत नहीं है, यह कुछ मानकों से व्यावहारिक रूप से नया है!

क्या आप जो कुछ भी है, जहां चीजें हैं के साथ परिचित कर सकते हैं -, इकाई परीक्षण अनुरेखण कोड/कॉल, कुछ यूएमएल चित्र ऊपर काम कर रहा है, आदि

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

Answer 3

यह कोडबेस की गुणवत्ता पर निर्भर करता है। दरअसल, आप इसे और भी संकीर्ण रूप से परिभाषित कर सकते हैं - यह इस बात पर निर्भर करता है कि कोड कितना स्पष्ट है, और यह कितनी अच्छी तरह से टिप्पणी की गई है (और मैं इसे किसी ऐसे व्यक्ति के रूप में लिखता हूं जिसका बार-बार खराब दस्तावेज वाली विरासत कोडबेस को विरासत में रखने की स्थिति में होता है)।

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

यदि कोडबेस वास्तव में खराब यूनिट परीक्षण आपकी मदद करने की संभावना नहीं है, क्योंकि आप सही तरीके से लागू होने पर भी गलत कुछ परीक्षण कर रहे हैं। अंत में मैं विरासत में मिला से एक उदाहरण: (नाम और विवरण जानबूझकर हटा दिया - वे किसी भी मामले में मूल में मददगार नहीं थे) के रूप में यह पता चला

public static int[] a (List<int[]> input){ 

    ... lots of opaque rubbish 
    return b(input); 
} 

public static List<int[]> b{ List<int[]> input) 
{ 
    ... more crap.... 
    return some horribly mangled list of int[]; 
} 

, क्या एक पूरा सॉर्ट करने के लिए था उनके दूसरे तत्व के मूल्य से सरणी। परीक्षण करने के लिए बी सही तरीके से व्यवहार करने के लिए इस मामले में बेकार होगा।

• निकालें कोड स्पष्ट रूप से उपयोग में नहीं है कि:

  सुझाव है कि आप अपने विवेक को बनाए रखने में मदद करेगा।

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

बेशक यह अधिकतर अनावश्यक है यदि कोडबेस अच्छी तरह लिखा गया है, लेकिन फिर किसी भी मामले में आपका काम अधिक आसान होगा। और शुभकामनाएं।

Answer 4

नया कोड प्राप्त करते समय मैं पहली चीज करता हूं "इसे काम करने का प्रयास करें"! इस से मेरा मतलब है:

• पहले इसे स्थापित (अनुसार नोट्स स्थापित अगर कोई है)

• तो इसके साथ अपने आप को परिचित (उपयोगकर्ता के मैनुअल पढ़ने और कुछ महत्वपूर्ण उपयोग के मामलों चलाकर)

• फिर मुख्य परतों को खोजने के लिए कुछ रिवर्स इंजीनियरिंग। वर्गों और निर्भरता

• फिर मैं नया परीक्षण मामलों लिखने के बारे में सोच सकते हैं (स्वीकृति के स्तर का पहली बार में, कि प्रतिगमन परीक्षण बाद में करने के लिए उपयोगी हो जाएगा)

• तो मैं अपने आप को देने के कुछ "चुनौतियों" इस सुविधा जोड़ने के बारे में (भले ही इसकी आवश्यकता नहीं है) या उस मौजूदा सुविधा के प्रदर्शन में सुधार: मौजूदा कोडबेस

• निश्चित रूप से कुछ ज्ञात लंबित बग/आरएफई में काम करने के लिए यह एक अच्छा तरीका है, मैं काम करूंगा ये पहले

आपके विशिष्ट मामले में, मैं आरएमआई कॉल, कॉल करने के लिए कॉल या अनुक्रम को दस्तावेज करने का प्रयास करता हूं, और जब संभव हो तो इसे उपयोग-स्तर सुविधाओं से संबंधित करता हूं।

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

Answer 5

बिल्ड और रन करें यह मेरी पहली बात होगी। उस समस्या के लिए एक समझ प्राप्त करना शुरू करें जिसे वह संबोधित करने का प्रयास कर रहा था।

शायद आप इसे यूयूएलएल टूल जैसे आयात कर सकते हैं और कक्षाओं के साथ बातचीत करने की तस्वीर प्राप्त कर सकते हैं।

लेखन JUnit परीक्षण एक उत्कृष्ट सुझाव है। मैं देखना चाहता हूं कि ऐप कितना स्तरित था। यदि परीक्षण करना मुश्किल है, तो शायद यह भी युग्मित है। यूनिट परीक्षण आपको बताएंगे। यदि आप कुछ रिफैक्टरिंग तय करते हैं तो वे आपको सुरक्षा नेट भी देंगे।

जेडीके 1.4? यह अपने समर्थन जीवन के अंत से पहले है। मैं यह भी देखना चाहता हूं कि कोड जेडीके 5 के तहत न्यूनतम, अधिमानतः जेडीके 6 के तहत बनाया जाएगा और चलाएगा। हो सकता है कि आप उन जेयूनीट परीक्षणों में से कुछ को जेएमटर में थप्पड़ मार सकें और 5 साथ-साथ उपयोगकर्ताओं के साथ एक त्वरित गरीब व्यक्ति का लोड टेस्ट कर सकें।

यदि आपके पास डेटा मॉडल है, तो उसे ERWin में खींचें और यह देखना शुरू करें कि टेबल, ऑब्जेक्ट्स और स्क्रीन एक साथ कैसे बहती हैं।

Answer 6

एक चीज जो मुझे मेरे साथ नया कोड के साथ काम करने में मदद करती है - यह अच्छी तरह लिखित कोड के लिए बहुत कम आवश्यक है - इसे एक या दो दिन के लिए बड़े पैमाने पर दोबारा प्रतिक्रिया देना है और फिर मेरे सभी परिवर्तनों को त्यागना है। यह प्रक्रिया मुझे समझने में मदद करती है कि कोड क्या करता है; कोड के साथ काम करने से मुझे समझने में मदद मिलती है। यह मुझे सिखाता है कि कोड के कौन से हिस्से नाजुक हैं।

यदि आपके पास जावा की एक नई रिलीज में माइग्रेट करने का अवसर है, तो सभी संग्रह जेनरेट करने से यह समझने में मदद मिलेगी कि डेटा प्रकार किस प्रकार पारित हो जाते हैं।

बेशक, मैं परीक्षण प्रयोगशाला में सॉफ़्टवेयर स्थापित करने के बाद ऐसा करता हूं और यह समझने के लिए थोड़ा सा खेलता हूं कि यह क्या करता है।

संपादित करें: मेरे उत्तर पर विचार करना, सिस्टम का उपयोग करने के लिए, और फिर लॉग का अध्ययन करने के लिए सभी डायग्नोस्टिक ट्रेसिंग और लॉगिंग को सक्षम करना भी उपयोगी है। यदि संचार प्रोटोकॉल ट्रेसिंग मौजूद है, तो इस ट्रेस को देखकर कोड द्वारा उपयोग किए जाने वाले संचार प्रोटोकॉल को समझने में मदद मिलेगी, शायद उसी परीक्षण के वायरशर्क ट्रेस के साथ।

पुरानी Concurrency लाइब्रेरी से नई जावा 5 (और 6) समवर्ती पुस्तकालय में माइग्रेट करना एक और उपयोगी माइग्रेशन है। इससे आपको यह समझने में मदद मिलेगी कि धागे कहाँ हैं और जब वे शुरू होते हैं और जब वे बंद हो जाएंगे।

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

Answer 7

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

आप स्कैनेंजर शिकार दृष्टिकोण को भी आजमा सकते हैं, हर सुविधा की एक सूची बना सकते हैं और इसके लिए कोड खोज सकते हैं ...

Answer 8

अपनी संरचना को समझने के लिए कोड के माध्यम से पहले स्किम करें। फिर, ऐप को डीबग मोड में चलाएं और इसे दो बार चलाएं। यह आपको प्रवाह और संरचना दिखाएगा।

अभियंता वर्ग आरेखों को रिवर्स करने के लिए नेटबीन्स का उपयोग करें।

Answer 9

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

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

इस पर कई मुफ्त संसाधन नहीं हैं, इसलिए मैं लिंक प्रदान नहीं कर रहा हूं। उम्मीद है कि मैंने आपको कुछ विचार देने के लिए पर्याप्त वर्णन करने में कामयाब रहा है।

Answer 10

अनुभव ने मुझे दिखाया है कि विरासत प्रणाली सीखते समय आपके पास 3 प्रमुख लक्ष्य हैं।

• जानें क्या कोड करने के लिए
• जानें कि यह कैसे करता है उन्हें
• (महत्वपूर्ण) जानें माना जाता है यही कारण है कि यह उनके रास्ते करता है यह

उन भागों के सभी तीन बहुत हैं करता है महत्वपूर्ण है, और शुरू करने में आपकी सहायता के लिए कुछ युक्तियां हैं।

सबसे पहले, सब कुछ समझने के लिए कोड के चारों ओर अपने रास्ते पर ctrl-click (या जो भी आपका आईडीई उपयोग करता है) के प्रलोभन का विरोध करें। आप शायद इस तरह अपने मन में परिप्रेक्ष्य में सब कुछ रखने में सक्षम नहीं होंगे, खासकर जब प्रत्येक पंक्ति आपको यह समझने के लिए कई अन्य वर्गों को देखने के लिए मजबूर करती है।

जहां संभव हो वहां दस्तावेज़ पढ़ें; यह आम तौर पर आपको एक मानसिक रूपरेखा प्राप्त करने में मदद करता है जिस पर निम्नानुसार सब कुछ बनाना है।

जहां संभव हो वहां परीक्षण केस चलाएं।

किसी ऐसे व्यक्ति से पूछने से डरो मत जो आपको पता है कि आपके पास कोई प्रश्न है या नहीं। अनुमोदित, आपको अन्य कर्मचारियों के समय को अनावश्यक प्रश्नों से बर्बाद नहीं करना चाहिए, लेकिन अगर ऐसा कुछ है जिसे आप समझ में नहीं आते हैं (यह विशेष रूप से अधिक वैचारिक प्रश्नों के साथ सच है, "क्या इसे इसे लागू करने के लिए और अधिक समझदारी नहीं होगी एक ___ "या कुछ), इससे पहले कि आप गड़बड़ करने से पहले जवाब का पता लगाना संभव हो और क्यों नहीं पता।

जब आप अंततः कोड पढ़ने के लिए नीचे उतरते हैं, तो तार्किक "मुख्य" जगह से शुरू करें और वहां से जाएं। कोड को ऊपर से नीचे या वर्णानुक्रम में, या कुछ भी नहीं (यह शायद स्पष्ट है) को न पढ़ें।