विरासत कोड सौंपने के लिए सर्वोत्तम अभ्यास


66

कुछ महीनों में एक सहकर्मी एक नई परियोजना के लिए आगे बढ़ेगा और मुझे उसकी एक परियोजना विरासत में मिलेगी। तैयार करने के लिए, मैंने पहले से ही माइकल फेदर्स की वर्किंग इफेक्टिवली लिगेसी कोड के साथ ऑर्डर कर दिया है ।

लेकिन इस पुस्तकों के साथ-साथ अब तक मिली विरासत कोड पर अधिकांश प्रश्न, जैसा कि कोड विरासत में मिला है, के मामले से चिंतित हैं। लेकिन इस मामले में मेरे पास वास्तव में मूल डेवलपर तक पहुंच है और हमारे पास एक अर्दली के लिए कुछ समय है।

कोड के टुकड़े पर कुछ पृष्ठभूमि मुझे विरासत में मिलेगी:

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

मैं सोच रहा था कि जब तक उसकी विदाई का समय सबसे अच्छा नहीं होगा। यहाँ विचारों की एक जोड़ी है:

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

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

अपडेट: जैसा कि हाथ से ओवर प्रोजेक्ट खत्म हो गया है, मैंने नीचे इस उत्तर में अपने स्वयं के अनुभवों के साथ इस सूची का विस्तार किया है ।


2
अनुकूलित कार्यों के क्यों दस्तावेजीकरण पर ध्यान दें !

मुझे उम्मीद है कि कोड स्रोत नियंत्रण में है। यदि हां, तो आपको प्रत्येक परिवर्तन (यदि कोई हो) के लिए दर्ज की गई टिप्पणियों से लाभ होगा।
बर्नार्ड

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

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

जवाबों:


25

जैसे ही आप डेवलपर के पास पहुँचते हैं आप पूछते हैं: -

  • कोड / लागू करने के लिए कौन से मॉड्यूल सबसे कठिन थे। क्या समस्याएं थीं और उन्हें कैसे दूर किया गया।

  • किस मॉड्यूल ने सबसे अधिक कीड़े उत्पन्न किए हैं।

  • बग्स को हल करने के लिए कौन से मॉड्यूल सबसे कठिन हैं।

  • कोड का कौन सा बिट वह सबसे अधिक गर्व है।

  • कोड के कौन से बिट्स वह वास्तव में रिफ्लेक्टर करना चाहेंगे, लेकिन, समय नहीं दिया गया है।

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


मुझे आपके द्वारा बताए गए भागों को चुनने का विचार पसंद है। सहज रूप से, मैंने एक टॉप-डाउन का अनुसरण किया होगा लेकिन इस तरह से कोड में सबसे गहरे दफन भागों को बहुत देर तक नहीं आया होगा, शायद इस प्रक्रिया में बहुत देर हो सकती है। आपका तरीका अधिक समझ में आता है, मुझे लगता है। क्या आपके पास "दस्तावेज़ कैसे करें" भाग के लिए कोई सुझाव है? यूएमएल? पाठ?
PersonalNexus

@PersonalNexus। आप इस दृष्टिकोण को प्रलेखन तक भी ले जा सकते हैं। पूछें कि कौन से दस्तावेज़ सबसे उपयोगी हैं, और, कौन से दस्तावेज़ अविश्वसनीय हैं या पुराने हैं (मेरा मानना ​​है कि दस्तावेज़ का 95% अंतिम श्रेणी में आता है!)।
जेम्स एंडरसन

17

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

  • संस्करण नियंत्रण के तहत सब कुछ प्राप्त करें: यह सुनिश्चित करने के बाद कि मुझे जो कुछ भी बनाने की ज़रूरत थी वह संस्करण नियंत्रण के तहत था, मैंने पुराने डेवलपर की हार्ड ड्राइव पर भी खोज की, अतिरिक्त स्क्रिप्ट या उपयोगिताओं की तलाश करने के लिए जो एप्लिकेशन को तैनात करने और / या परीक्षण करने में सहायक होंगे, लेकिन थे में जाँच नहीं की गई
  • टॉप-डाउन: मैं मुख्य कक्षाओं के उच्च स्तरीय लुक और मुख्य क्षेत्रों के पुराने डेवलपर के साथ एक निर्देशित दौरे के साथ शुरुआत करूंगा। फिर मैं अपने दम पर बाकी हिस्सों में गहरी खुदाई करूंगा, उन चीजों को चिह्नित करूंगा जो मुझे //TODOमार्करों से कोई मतलब नहीं था ।
  • सभी दस्तावेज स्वयं लिखें: जबकि मेरे पास यह सुनिश्चित करने के लिए कि मेरे पास यह लिखने के लिए पुराना डेवलपर है, मैंने इसे सब कुछ लिखने के लिए जोर दिया। इस तरह मुझे यकीन है कि लेखन ने मुझे और पुराने डेवलपर को ही नहीं बनाया।
  • हर जगह टिप्पणियाँ: मैंने हर वर्ग और हर विधि में XML प्रलेखन सारांश जोड़े । इस तरह से मैंने यह सुनिश्चित किया कि मैंने कम से कम कोड के हर टुकड़े को देखा और एक वाक्य में यह समझने के लिए पर्याप्त समझ है कि यह क्या किया। इसने उन तरीकों को समझना भी आसान बना दिया है, जो इंटेलीजेंसी इस जानकारी को उठाते हैं। मैं आसानी से कोड के क्षेत्रों की पहचान कर सकता हूं जिन्हें मुझे अभी भी देखना था।
  • स्रोत के करीब दस्तावेज़: स्रोत कोड और दस्तावेज़ के बीच संबंध को आसान बनाने के लिए, मैंने अपना अधिकांश दस्तावेज़ स्रोत कोड में डाला। उच्च-स्तरीय प्रलेखन के लिए जो विभिन्न उप-प्रणालियों के बीच बातचीत का वर्णन करता है, मैंने एक विकी का उपयोग किया, क्योंकि इस जानकारी को कोड में सिर्फ एक जगह पर रखने से काम नहीं चला। डॉक्यूमेंटेशन के सभी इलेक्ट्रॉनिक और पूर्ण-पाठ योग्य होने चाहिए।
  • आरेख: एक बुनियादी अवलोकन के लिए मैंने विभिन्न उप-प्रणालियों के लिए विभिन्न ग्रैन्युलैरिटी के वर्ग आरेखों का उपयोग किया। समवर्ती भागों के लिए, ऑब्जेक्ट और इंटरैक्शन आरेख वास्तव में सहायक रहे हैं; विषय पर मेरे अन्य प्रश्न भी देखें ।
  • एक जोड़ी के रूप में परावर्तन: जबकि मैंने कोड को महसूस करने और चीजों को अधिक बनाए रखने के लिए पुराने डेवलपर के साथ कुछ रीफैक्टरिंग किया, यह एक अच्छा समय लेने वाली और जोखिम भरा प्रक्रिया थी, क्योंकि अच्छे रिफ्लेक्टरिंग टूल की कमी और बुरा होने का एक गुच्छा। विभिन्न भागों के बीच निर्भरता। माइकल फेदर के लिगेसी कोड के साथ प्रभावी ढंग से काम करना इसके लिए एक बहुत अच्छी मदद है, भले ही उचित उपकरण समर्थन के बिना रिफैक्टिंग अभी भी दर्दनाक है। रिफ्लेक्ट करने के दौरान मैं उसे माउस और कीबोर्ड पर नियंत्रण करने देता, क्योंकि यह उसके लिए अधिक मजेदार था (यह भी कि मेरा आखिरी बुलेट पॉइंट देखें) और मैं जो कुछ भी सीख रहा था उसे लिखने के लिए स्वतंत्र था।
  • टिप्पणियों और परिवर्तनों के लिए अलग-अलग चेक-इन्स: गलती से मैंने एक टिप्पणी लिखकर बग की शुरुआत की override, मैं अलग-अलग चेक-इन में टिप्पणी और परिवर्तन करने के लिए सावधान रहा। मैंने कुछ कोड की जांच करने से पहले स्रोत कोड से सभी टिप्पणियों को पट्टी करने के लिए एक छोटी सी उपयोगिता का उपयोग किया है, इसलिए टिप्पणी-केवल चेक-इन का एक अंतर 0 अंतर दिखाएगा। सभी परिवर्तन (जैसे अप्रयुक्त क्षेत्रों को हटाना) ध्यान से सहकर्मी की समीक्षा पुराने डेवलपर के साथ की गई थी ताकि मैं यह सुनिश्चित कर सकूं कि मैं अभी भी उन चीजों को नहीं हटा रहा हूं जिनकी जरूरत थी।
  • महत्वपूर्ण मार्ग के लाइन-बाय-लाइन वॉकथ्रू: सबसे अनुकूलित / जटिल मार्ग के लिए, मैं पुराने डेवलपर के साथ कोड लाइन-बाय-लाइन पर जाऊंगा और कभी-कभी तीसरे सहयोगी के साथ भी। इस तरह मुझे कोड की पूरी समझ हो गई और अधिक लोगों ने कोड को वीटो कर दिया, हमने वास्तव में कुछ बग्स के साथ-साथ कुछ चीजों की पहचान की, जिन्हें आगे भी अनुकूलित किया जा सकता है।
  • त्वरित रहें और पुराने डेवलपर को प्रेरित रखें: मैंने देखा कि पुराने डेवलपर कम और कम रुचि रखते थे क्योंकि उनका आखिरी दिन करीब आ रहा था (आश्चर्य की बात नहीं)। इसलिए मुझे यकीन है कि सबसे महत्वपूर्ण भागों को पहले सौंप दिया गया था, बाकी को छोड़कर मुझे अपने दम पर पता लगाने के लिए, यदि आवश्यक हो। मैंने उसे और भी मजेदार चीजें छोड़ने का प्रयास किया (जैसे कि जोड़ी-प्रोग्रामिंग के समय कीबोर्ड का नियंत्रण)।
  • फ़ीचर अनुरोधों को पहचानें: मैंने पुराने डेवलपर से उन विशेषताओं की सूची के लिए पूछना उपयोगी पाया, जो लोगों ने मांगे थे, लेकिन अभी तक जोड़े नहीं गए थे। कुछ चीजें थीं जो मुझे जोड़ने के लिए सरल दिखती थीं, लेकिन जहां एक अच्छा कारण था उन्हें जोड़ा नहीं गया था क्योंकि वे लागू होने पर अन्य चीजों को तोड़ देंगे, जैसा कि मैंने पहले सोचा था।

14

एक समान स्थिति में होने के बाद, मेरा मानना ​​है कि निम्नलिखित भी ध्यान देने योग्य होगा:

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

    (यह आपके लिए प्रासंगिक नहीं हो सकता है, उदाहरण के लिए यदि आप पहले से ही निरंतर एकीकरण या निरंतर तैनाती करते हैं, लेकिन यह ध्यान देने योग्य है, बस मामले में ...)

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

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

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

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


+1 अधिक परीक्षण। पर्याप्त परीक्षण कभी नहीं होते हैं।
सरदारथियन

10

आपके सवालों के जवाब के लिए +1!


कोड का निर्देशित टूर 10k लाइन बहुत है, लेकिन मुझे लगता है कि यह अभी भी असंभव नहीं है कि दूसरा लड़का आपको 'गाइडेड टूर' दे। आप कोड के सामने एक साथ बैठते हैं और वह आपको 'परतों' के नीचे काम करते हुए ऊपर से नीचे तक की यात्रा पर ले जाता है। आपको इसे कम फटने की आवश्यकता होगी - एक बार में सभी आप दोनों को मार देंगे।

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

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

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

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


+1 कुछ पुराने कीड़े को ठीक करने की कोशिश करने के लिए कोड की मेरी समझ का परीक्षण करने के लिए
PersonalNexus

1
"इससे कोई फर्क नहीं पड़ता कि वह आपसे नफरत करता है" - सावधान, "यह एक छोटी सी दुनिया है";)
पूर्वव्यापी

इसके अलावा, एक शब्द दस्तावेज़ खोलें और स्क्रीनशॉट के एक टन सहित, हर चीज से जीवित बिल्ली को दस्तावेज़ित करें। जब मैं एक सूचना अधिभार में हो, तो यह मुझे बहुत बार बचाता है!
बेन पावर

7

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

एक परियोजना के रूप में हाथ से ओवर का इलाज करें और एक योजना बनाएं और प्रबंधन को शामिल करें।

0 - सुनिश्चित करें कि आप जानते हैं कि सिस्टम का उपयोग कैसे करें।

1 - समाधान घटकों की स्पष्ट सूची बनाएं, प्रत्येक का स्रोत और जहां यह निहित है (अलग-अलग रिपॉजिटरी में)।

2 - प्राप्त करें और यदि संभव हो तो, प्रबंधित करें, अब शुरू होने वाले विभिन्न सर्वरों के लिए पासवर्ड। सुनिश्चित करें कि आपके पास सभी व्यवस्थापक खाता जानकारी है

3 - प्रत्येक बाहरी घटक के लाइसेंस तब तक प्राप्त करें जब तक कि आपके दायरे के बाहर (जैसे विशेष डीएलएस, डेटाबेस, आदि)।

4 - डेवलपर और आपके ग्राहकों से प्रणाली की वर्तमान स्थिति के बारे में एक लिखित रिपोर्ट प्राप्त करें (यदि वे आपकी कंपनी के लिए स्थानीय हैं)

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

6 - अनुसूचित घटनाओं (नौकरियों के मासिक रन, नौकरियों के साप्ताहिक रन) की एक सूची प्राप्त करें जो सॉफ्टवेयर को जवाब देना है

7 - बैकअप / पुनर्स्थापना प्रक्रियाओं को जानें

8 - आवेदन के निर्माण में उपयोग किए गए ढांचे (ओं) को समझें

9 - अनुरोधित / अपेक्षित / नियोजित संशोधनों और किसी भी लंबित उपयोगकर्ता अनुरोध की स्थिति के बारे में जानें। यह पहचानने की कोशिश करना शुरू कर दें कि वे कैसे करें।

10 - सुनिश्चित करें कि आपके परीक्षण और विकास के वातावरण बहुत समान हैं।

11 - प्रमुख निर्भरता (अन्य प्रणालियों पर या घटकों के बीच) की पहचान करने का प्रयास करें जिन्हें आसानी से देखा नहीं जा सकता है।

12 - प्रत्येक सॉफ़्टवेयर उपयोग और उसके विक्रेता संपर्क (यदि आवश्यक हो) के आवश्यक संस्करणों को पहचानें और दस्तावेज करें

13 - किसी भी विशेष उपकरण की पहचान करें जो वह इस्तेमाल कर रहा था जो आपके पास नहीं है, अगर यह आपकी मदद कर सकता है।

14 - एक उच्च स्तरीय प्रणाली प्रवाह प्राप्त करें। और अपने प्रलेखन पुस्तकालय का निर्माण शुरू करें

15 - आवेदन के लिए उपयोगकर्ता सुरक्षा का प्रबंधन करने के तरीके को समझें

16 - बग लॉग प्राप्त करें और क्रियाओं को समझने की कोशिश करें और कार्रवाई पुराने डेटा को कैसे प्रभावित करती है (यदि लागू हो)

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

18 - उत्पादन सर्वर घड़ी की जाँच करें

19 - यह पहचानें कि कॉन्फ़िगरेशन कहाँ हैं और प्रत्येक पर्यावरण कॉन्फ़िगरेशन की तुलना उत्पादन के साथ करते हैं ताकि यह पता चल सके कि क्या पैरामीटर अलग हैं और क्यों

20 - इस आदमी की संपर्क जानकारी प्राप्त करें

21 - यदि सिस्टम आंतरिक है, तो सिस्टम उपयोगकर्ताओं के साथ एक मीटिंग शेड्यूल करें (आपको यह जानने की आवश्यकता है कि वे कौन हैं और प्रत्येक भूमिका क्या है) और उन्हें पेश किया जाए। सुनें कि सिस्टम के बारे में उनका क्या कहना है और यदि कोई है तो उनकी मौजूदा समस्याओं के बारे में। सुनिश्चित करें कि आप जितनी जल्दी हो सके ईमेल में शामिल किए गए हैं (आपके प्रबंधक की स्वीकृति के बाद)

22 - वह छोड़ने से 1 सप्ताह पहले अपनी समझ का आकलन करें और किसी भी समस्या को जोखिम के रूप में देखें

चूंकि आपने उल्लेख किया है कि आपके पास डेटाबेस नहीं है, इसलिए यह सूची छोटी हो गई।

सौभाग्य।


@SSamra: टिप्पणी उठाने के लिए धन्यवाद। मुझे यह चाहिए था। :)
NoChance

बहुत ही थकावट और कुछ महत्वपूर्ण बिंदुओं सहित, जो मुझे याद हो सकते हैं अन्यथा, जैसे प्रबंधन और हमारे (आंतरिक) ग्राहक शामिल हैं।
पर्सनल

5

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

यदि उन को कवर करने के बाद समय है, तो मैं अगले आवेदन के कुछ हिस्सों के साथ इसी तरह की प्रक्रिया से गुजरूंगा, जिन्हें वर्षों के दौरान सबसे अधिक बार बदलाव की आवश्यकता होती है, लेकिन जो दस्तावेज के पहले समूह में नहीं हैं।

फिर जो कुछ भी बचा है उसे दस्तावेज़ दें।


5

मुझे लगता है कि कुछ बड़े कोड को टटोलने का सबसे अच्छा तरीका ऊपर-नीचे दृष्टिकोण है। पहले बड़ी तस्वीर को समझने की कोशिश करें, और फिर धीरे-धीरे एक-एक करके घटकों में गहरी खुदाई करें।

अब खुदाई के प्रत्येक स्तर पर, उसे उन हिस्सों को प्राथमिकता देने के लिए कहें जिन्हें सबसे अधिक ध्यान देने की आवश्यकता है। उसे जितना संभव हो सके समझाएं, लेकिन हमेशा उसे स्वयं दस्तावेजित करें।

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

यह, मुझे लगता है कि आपके "क्या और कैसे दस्तावेज़" मुद्दों को हल करता है। जब वह आपको सब कुछ समझाता है, तो आप अपने आप को यह तय कर सकते हैं कि जब आप कोड में वापस आएंगे तो आप क्या चाहते हैं - और केवल उन हिस्सों को दस्तावेज करें।

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

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

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


आप इसे कैसे प्रलेखित करने वाले हैं? सादे पाठ ? विकी? स्रोत कोड में टिप्पणी?
c69

कुछ भी जो आपके द्वारा डॉक्स लिखते समय कोड की उसी समझ को बहाल करना संभव बनाता है।
ट्रेकरोड 12

5

मुझे आप के लिए महसूस होता है।

कुछ सुझाव:

  1. प्रोग्रामर छोड़ने के साथ आपकी हर बातचीत को टेप करें!
  2. "बड़े" मुद्दों के पीछे प्रेरणा के लिए पूछें। यह अच्छा है कि आप एपीआई को समझें, लेकिन आंतरिक निर्णयों के लिए खुदाई करें - कोड को क्यों विभाजित किया गया था? जिम्मेदारियाँ क्या हैं।
  3. कोड का वास्तव में अध्ययन करने का प्रयास करें। जब आप रखरखाव और समर्थन कर्तव्यों को मानते हैं, तो कभी-कभी "प्रगति करते समय कोड का अध्ययन करने" का दबाव होता है। यदि आप कर सकते हैं, तो विरोध करें और वास्तव में कोड का अध्ययन करें।
  4. परिदृश्यों के लिए देखें। आप एपीआई को जानते हैं - देखें कि कोड कैसे व्यवहार करता है। एक उदाहरण जो दिमाग में आता है वह है फैक्स मॉड्यूल। एपीआई के एक उपयोगकर्ता के रूप में, आपको पहले से ही एक पृष्ठ की छवि को तैयार करना होगा और पेज को प्रसारित करने के लिए कोड को एक कमांड भेजना होगा। यह देखने के लिए प्रोग्रामर को कोड पर अपने साथ ट्रेस करने के लिए कहें कि यह परिदृश्य कैसे चलता है। फिर, निश्चित रूप से, "प्राप्त पृष्ठ" परिदृश्य पर जाएं।
  5. 80/20 - पहले अधिक सामान्य परिदृश्यों को कवर करने का प्रयास करें।
  6. फिर से लिखने पर विचार करें। यदि कोड पुराना है और इंटरफेस अच्छी तरह से परिभाषित हैं, तो शायद इसे सही ठहराने के लिए तकनीक काफी बदल गई है।
  7. मुझे यह कहने से नफरत है, लेकिन एक नई नौकरी की तलाश पर विचार करें।

मुझे हर बातचीत को टेप करने का विचार पसंद है, इसलिए उसके चले जाने के बाद मैं उसके मूल शब्दों पर वापस जा सकता हूं। सुझाव # 7, हालांकि, एक विकल्प नहीं ;-)
PersonalNexus

3

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

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

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


2

यद्यपि आपने एक बैकएंड डेटाबेस के बारे में उल्लेख नहीं किया है, लेकिन यह मानते हुए कि एक आपको होना चाहिए

  1. विशेष रूप से स्तंभों और पीके-एफके द्वारा प्रलेखित डेटा मॉडल प्राप्त करें
  2. एक sql ट्रेस सेट करें और एप्लिकेशन का उपयोग करते समय सभी प्रश्नों को रिकॉर्ड करें। प्रश्नों के निष्पादन का क्रम आपको आवेदन के प्रवाह के बारे में एक अच्छा विचार देगा और डिबगिंग में भी मदद करेगा।

सामान्य तौर पर अच्छी बात है, लेकिन मेरे विशेष मामले में कोई डेटाबेस नहीं है।
पर्सनल

1
हो सकता है कि यह किसी और की मदद करेगा
NRS

2

मैं उसी स्थिति में हूं, जहां हमारे वास्तुकार ऑस्ट्रेलिया चले गए थे और पिछले 8 वर्षों से कंपनी के साथ होने के कारण बहुत सारी विरासत छोड़ गए थे। उन्होंने खुद को पिछले आर्किटेक्ट से विरासत में मिला सामान जो कि एक ठेकेदार था।

आपने और अन्य लोगों ने पहले से ही अच्छे बिंदुओं का उल्लेख किया है, लेकिन यहां समस्याओं का सामना करना पड़ सकता है जब वह छोड़ देता है तो आप बेहतर तैयारी कर सकते हैं ...

1) (तकनीकी व्यक्ति) वह जिन ग्राहकों के साथ काम कर रहा है उनसे संपर्क विवरण।

2) उनका खाता जिसके तहत उन्होंने सॉफ्टवेयर्स लाइसेंस, चाबियां खरीदी हैं, जिन्हें हर साल नवीनीकृत करने और उन्हें नवीनीकृत करने के लिए प्रक्रियाओं / लागतों की आवश्यकता होती है।

3) तीसरे पक्ष के सॉफ्टवेयर पुस्तकालयों / घटकों और उत्पादों के सेटअप का दस्तावेज जो आपके उत्पादों के साथ एकीकृत है। हम एक मशीन को वापस लाने के लिए 4 दिनों तक संघर्ष करते रहे, जो कि अंतरिक्ष को साफ़ करने में आईटी की वजह से खो गई थी और कुछ गलत निर्देश उन्हें दिए गए थे।

4) दस्तावेज़ों / चरणों का उपयोग वह स्रोत कोड को सॉफ़्टवेयर डिपॉज़िट कंपनियों जैसे एस्क्रो में जमा करने के लिए किया जाता है।

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

इसके अलावा, मुझे नहीं पता कि यह आपके लिए पहली बार है। मेरे लिए मैंने 5/6 नियोक्ताओं के साथ काम किया है और हमेशा खराब प्रलेखन या बिना किसी दस्तावेज के साथ कोड विरासत में मिला है। तो सभी दस्तावेजों के साथ बस सकारात्मक रहें :)

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.