2010-09-03 14 views
17

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

कक्षाओं में से 80% अधूरा/अनुपलब्ध दस्तावेज है। शेष 20% वे हैं जो टूल के लिए सामान्य उद्देश्य API बनाते हैं। कोड पढ़ने के एक महीने ने मुझे बुनियादी वास्तुकला को समझने में मदद की है। लेकिन मैं अपने प्रोजेक्ट के लिए आवश्यक सटीक परिवर्तनों को समझने में सक्षम नहीं हूं। एक बार, मैंने कोड के एक हिस्से को संशोधित करना शुरू कर दिया और जल्द ही इतने सारे बदलाव किए जिन्हें मैं अब याद नहीं कर सका।

एक दोस्त ने सुझाव दिया कि मैं कक्षा पदानुक्रम लिखने की कोशिश करता हूं। क्या ऐसा करने के लिए कोई बेहतर (मानक?) तरीका है?

+0

आप MaintainJ की तरह ग्रहण ही या कुछ अन्य उपकरणों का उपयोग यूएमएल चित्र में कोड इंजीनियर को बदलने का हो सकता है। चूंकि आपके पास बुनियादी वास्तुकला की उचित समझ है, कक्षा और अनुक्रम आरेख आपको कोड – InSane

+0

में एक अच्छा प्रारंभिक बिंदु प्रदान करेंगे, आपको नौसिखिया प्रोग्रामर के रूप में एक ओपन सोर्स टूल को संशोधित करना क्यों है? यहां तक ​​कि यदि यह खुला स्रोत है, तो अधिकांश समय संशोधित करने से कॉन्फ़िगर करना बेहतर होता है। संस्करण नियंत्रण के लिए – emory

उत्तर

10
  • जांच एक ऐसा एप्लिकेशन है जो इस ओपन सोर्स टूल का उपयोग करता है, बाइनरी निर्भरता को हटाने का प्रयास करें और ग्रहण या किसी अन्य आईडीई में परियोजना निर्भरता पेश करें। अपने कोड चलाने के लिए और कोड है कि आप को समझने के लिए
  • के बाद हर छोटा सा परिवर्तन के लिए प्रतिबद्ध
  • आप अलग अलग विचारों कोड
+4

+1। इसके अलावा, सीवीएस का उपयोग न करें। बस मत करो –

0

कोड को समझने का एकमात्र तरीका इसे पढ़ना है। काम करना जारी रखें मेरी सलाह है।

अन्य लोगों की तुलना में बेहतर दस्तावेज़ीकरण वाली परियोजनाएं हैं। Tomcat, Jetty, Hudson,

आप और अधिक खुला स्रोत परियोजनाओं के लिए java-source की जांच होनी चाहिए: यहाँ परियोजनाओं है कि मैं जानता हूँ कि अच्छी तरह से आयोजित कर रहे हैं की एक जोड़ी है। कुछ स्रोत कोड भंडार में कोड (सबवर्सन, सीवीएस, Git, मर्क्युरियल ...)

  • सुनिश्चित करें कि आप स्रोत से परियोजना का निर्माण और चलाने यह
  • आप पहले से ही है, तो कर सकते हैं में

  • 2

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

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

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

    +0

    और जब दस्तावेज़ीकरण किया जाता है, तो इसे मूल परियोजना में वापस योगदान देने पर विचार करें। – JeremyP

    1

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

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

    4

    दो चीजें जो ग्रहण (और अन्य आईडीई भी) इस 'लड़ाई' की पेशकश करती हैं। मैं उन्हें बहुत बड़ी परियोजनाओं पर उपयोग किया है:

    • कॉल पदानुक्रम - एक विधि राइट क्लिक करें और चुनें "कॉल पदानुक्रम", या CTRL + ALT + एच का उपयोग यह आपको सभी तरीकों कि चयनित विधि कॉल देता है , पेड़ को और नीचे जांचने के विकल्प के साथ। यह सुविधा है वास्तव में बहुत उपयोगी है।

    • टाइप पदानुक्रम - कक्षाओं के विरासत पदानुक्रम देखें। ग्रहण में यह F4 या Ctrl + टी है

    इसके अलावा

    :

    • ताकि परिवर्तन पर बचाने के प्रभावी करने के लिए एक रास्ता खोजने, और आप
    • उपयोग पुनर्वितरित की जरूरत नहीं है एक डीबगर - आईडीई के भीतर डीबग मोड में चलाएं, ताकि आप देख सकें कि प्रवाह
    0

    मेरी राय में किसी परियोजना को समझने के लिए कोई मानक दृष्टिकोण नहीं है। यह बड़ी परियोजनाओं पर आपके पिछले अनुभव के विश्लेषण के लिए कोड/आर्किटेक्चर की समझदारी से कई कारकों पर निर्भर करता है।

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

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

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

    0

    यहां पर कुछ सिफारिशों

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

    एक महान पुस्तक Working Effectively with Legacy Code कहा जाता है, माइकल पंख से नहीं है। एक छोटा लेख संस्करण here है।

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

    लेख जुड़ा हुआ से, अपनी रणनीति के सारांश:

    1. Identify change points 
    2. Find an inflection point 
    3. Cover the inflection point 
        a. Break external dependencies 
        b. Break internal dependencies 
        c. Write tests 
    4. Make changes 
    5. Refactor the covered code. 
    
    संबंधित मुद्दे