आप बड़े कोड बेस में कैसे गोता लगाते हैं?

Question

अज्ञात कोड आधार की खोज और सीखने के लिए आप किन उपकरणों और तकनीकों का उपयोग करते हैं?

मैं जैसे उपकरणों की सोच रहा हूँ grep, ctags, यूनिट-परीक्षण, कार्यात्मक परीक्षण, वर्ग आरेख जनरेटर, रेखांकन फोन की तरह कोड मैट्रिक्स sloccount, और इतने पर। मैं आपके अनुभवों, आपके द्वारा उपयोग किए गए या आपके द्वारा लिखे गए कोड आधार के आकार और आपके द्वारा लिखे गए सहायकों में दिलचस्पी लूंगा।

मुझे पता है कि एक कोड आधार से परिचित होना एक ऐसी प्रक्रिया है जो समय के साथ होती है, और परिचित का मतलब "मैं कोड को संक्षेप में प्रस्तुत करने में सक्षम हूं" से "मैं इसे 30% कर सकता हूं और इसे आकार के 30% तक सिकोड़ सकता हूं"। लेकिन कैसे भी शुरू करें?

Comments

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

— जेफरी स्वीनी

के संभावित डुप्लिकेट क्या अपरिचित, संरचनात्मक रूप से अस्वस्थ कोड में कार्यक्षमता जोड़ने के लिए सबसे प्रभावी तरीका है?

— gnat

Answer 1

जो मैंने हमेशा किया है वह निम्नलिखित है:

मेरे संपादक (दृश्य स्टूडियो / ग्रहण / जो भी हो) की कई प्रतियां खोलें और फिर डिबग करें और कोड के माध्यम से लाइन ब्रेक स्टेप करें। कोड के प्रवाह का पता लगाएं, ट्रेस ट्रेस के माध्यम से यह देखने के लिए कि मुख्य बिंदु कहाँ हैं और वहां से जाएं।

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

Comments

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

— जोएरी सेब्रेट्स

+1 हाँ, यह वही है जो मैं भी करता हूँ, लेकिन मुझे काम आसान करने का कोई तरीका नहीं पता है। मेरे अनुभव में, मुझे कोई भी बदलाव करने में सुरक्षित महसूस करने से पहले हफ्तों लग सकते हैं, और महीनों पहले "घर पर" कोड में। यदि आप डेवलपर्स के प्रश्न पूछ सकते हैं तो यह निश्चित रूप से मदद करता है।

— माइक डनलेवी

इसके अलावा: मैं आमतौर पर एक सुविधा से शुरू करता हूं। कहो मैं जानना चाहता हूं कि यह ईमेल कैसे भेजता है? इसलिए मैं "सेंड इमेल" की तलाश करता हूं, वहां ब्रेकपॉइंट करता हूं, और फिर वर्णित रूप में करता हूं। तब आपको कुछ जादुई घटक का पता चलता है जो कुछ करता है, और उस में जाता है, और देखता है कि कैसे काम करता है

— लैक्रोमोलॉजी

+1, लेकिन कभी-कभी ब्रेकपॉइंट्स स्थापित करने से पहले, मैं फ़ंक्शन पदानुक्रम को देखने के लिए लगभग सभी फ़ंक्शन की पहली पंक्ति में मुद्रण फ़ंक्शन जोड़ता हूं।

— mrz

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

— smwikipedia

Answer 2

आप हाथी कैसे खा करते हैं?

एक समय में एक काटने :)

गंभीरता से, मैं पहले कोड के लेखकों से बात करने की कोशिश करता हूं।

Comments

आप एक हाथी को कैसे कोड करते हैं? एक बार में एक बाइट!

— मेसन व्हीलर

संचार की शक्ति को अक्सर कम करके आंका जाता है

— poseid

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

— पीटर एलेनवेब

यह निश्चित रूप से मानता है कि कोड का लेखक उपलब्ध है।

— एरिक रॉबर्टसन

@ErickRobertson ... और वह गधे नहीं हैं।

— 1w पर smwikipedia

Answer 3

क्या मुझे काम पूरा होने तक हैक करना होगा

बहुत हद तक, हाँ (क्षमा करें)।

आप जिन पर विचार कर सकते हैं:

1. यह पता लगाने की कोशिश करें कि व्यावसायिक शब्दों में कोड क्या करना चाहिए।
2. सभी दस्तावेज़ पढ़ें जो मौजूद हैं, चाहे वह कितना भी बुरा क्यों न हो।
3. जिस किसी को भी कोड के बारे में कुछ पता हो सकता है उससे बात करें ।
4. डिबगर में कोड के माध्यम से कदम।
5. छोटे बदलावों का परिचय दें और देखें कि क्या टूटता है।
6. इसे साफ करने के लिए कोड में छोटे बदलाव करें।

कोड स्पष्ट करने के लिए मैं कुछ चीजें कर रहा हूं:

1. कोड को अच्छी तरह से फॉर्मेट करने के लिए एक कोड प्रेटिफ़ायर चलाएं।
2. मुझे लगता है कि यह क्या कर सकता है समझाने के लिए टिप्पणी जोड़ें
3. उन्हें स्पष्ट करने के लिए परिवर्तनशील नाम बदलें (रिफ्लेक्टरिंग टूल का उपयोग करके)
4. एक उपकरण का उपयोग करना जो किसी विशेष प्रतीक के सभी उपयोगों पर प्रकाश डालता है
5. कोड में अव्यवस्था को कम करना - कोड, अर्थहीन टिप्पणी, व्यर्थ चर आरंभीकरण और इसके आगे टिप्पणी की।
6. वर्तमान कोड सम्मेलनों का उपयोग करने के लिए कोड बदलें (फिर से रीफैक्टरिंग उपकरणों का उपयोग करके)
7. कार्यक्षमता को सार्थक दिनचर्या में निकालने के लिए शुरू करें
8. जहां संभव हो वहां परीक्षण जोड़ना शुरू करें (अक्सर संभव नहीं)
9. जादू नंबर से छुटकारा
10. जहां संभव हो, दोहराव कम करना

... और जो भी अन्य सरल सुधार आप कर सकते हैं।

धीरे-धीरे, इसके पीछे का अर्थ सभी स्पष्ट हो जाना चाहिए।

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

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

Comments

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

— मर्फ़

बहुत बढ़िया जवाब। मुझे ऐसी परियोजना में आने की स्थिति मिली जो मेरे लिए अज्ञात थी। मैंने कई सफाई की, जिसमें स्रोत भी शामिल हैं, निर्माण प्रक्रिया आदि। मुझे लगता है कि हर बदलाव नहीं रखा जाएगा, लेकिन इसने मेरे लिए अभिविन्यास प्रक्रिया में मदद की।

— गोर्यगृहम्

फोकस का उल्लेख करने के लिए @Murph +1। यह ध्यान रखना बहुत जरूरी है कि जटिल कोडबेस से निपटने के दौरान आपका ध्यान क्या है। और हां, स्टाइल के लिए उत्सुक होना उतना ही महत्वपूर्ण है।

— smwikipedia

Answer 4

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

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

अगला, मुझे लगता है कि आपका सुझाया दृष्टिकोण निश्चित रूप से एक अच्छा कदम है। आपको उच्च स्तर पर पहले समझना होगा कि कोड का उद्देश्य क्या है।

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

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

Answer 5

जब मुझे एक बहुत बड़ी स्रोत फ़ाइल मिलती है, तो मैं निम्नलिखित करना पसंद करता हूँ:

• क्लिपबोर्ड पर पूरी गड़बड़ कॉपी करें
• जो भी हो वर्ड / टेक्स्टमेट में पेस्ट करें
• फ़ॉन्ट का आकार कम से कम करें।
• कोड में पैटर्न देखकर नीचे स्क्रॉल करें

आप इस बात से चकित होंगे कि जब आप अपने सामान्य संपादक से वापस मिलते हैं तो कोड कितना अजीब लगता है।

Comments

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

— जून्की

उदात्त पाठ में एक 'न्यूनतम' है जिसका उपयोग समान उद्देश्य के लिए किया जा सकता है।

— kmoe

Answer 6

इसमें समय लगता है

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

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

"आपने इस भाग को इस तरह क्यों किया"

"मैंने देखा कि ज्यादातर लोग ऑनलाइन इस तरह से कर रहे हैं, और आप सभी ने इसे दूसरे तरीके से किया है। यह क्यों है?"

"क्या आप सभी प्रौद्योगिकी वाई पर प्रौद्योगिकी एक्स का चयन किया?"

इन सवालों के जवाब आपको परियोजना के इतिहास और डिजाइन और कार्यान्वयन निर्णयों के पीछे के तर्क को समझने में मदद करेंगे।

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

Answer 7

cscope C, plus के लिए जो कुछ भी ctags कर सकता है वह कर सकता है, यह भी सूची कर सकता है कि सभी वर्तमान फ़ंक्शन को कहाँ कहा जाता है। साथ ही यह बहुत तेज है। लाखों LOC पर आसानी से स्केल। Emacs और विम को बड़े करीने से एकीकृत करता है।

C और C ++ कोड काउंटर - cccc HTML फॉर्मेट में कोड मेट्रिक्स उत्पन्न कर सकते हैं। मैंने LOC पाने के लिए wc का भी इस्तेमाल किया है।

doxygen html में सिंटैक्स हाइलाइटेड और क्रॉस रेफरेंस कोड उत्पन्न कर सकता है। बड़े कोड बेस ब्राउज़ करने में उपयोगी।

Answer 8

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

Answer 9

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

Comments

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

Answer 10

मुझे एक बार एक बहुत ही शानदार सॉफ्टवेयर इंजीनियर ने बताया था कि कोड विश्लेषण और रखरखाव का सबसे महंगा रूप कोड के माध्यम से चलना था, लाइन से लाइन; बेशक, हम प्रोग्रामर हैं, और यह बहुत काम के साथ आता है। खुश माध्यम, मुझे लगता है, (इस क्रम में) है: 1. नोट को बनाने के लिए एक नोटबुक प्राप्त करें कि आप कोड को काम करने के लिए कैसे समझते हैं, और समय के अनुसार इसे जोड़ते हैं 2. कोड 3 के बारे में प्रलेखन देखें। उन लेखकों या अन्य लोगों से बात करें जिन्होंने कोड आधार का समर्थन किया है। उनसे "ब्रेन डंप" के लिए पूछें 4. यदि आप उस बिंदु पर हैं जहां आप कुछ विस्तार-स्तरीय वर्ग के रिश्तों को समझते हैं, तो कोड के डिबगिंग के माध्यम से कुछ संश्लेषण करने के लिए कुछ कोड करें कि आपने सोचा था कि कोड कैसे काम करता है और कोड वास्तव में कैसे काम करता है।

Answer 11

पहले समझ लें कि इसका क्या मतलब है - इसके बिना यह अस्पष्ट होने की संभावना है। उपयोगकर्ताओं से बात करें, मैनुअल पढ़ें, जो भी हो।

फिर हिट रन और प्रमुख कार्य होने लगते हैं के लिए कोड चलना शुरू करें।

Answer 12

विभाजन और जीत। मैं प्रत्येक कार्यक्षमता और संबंधित कोड को देखता हूं, उनके माध्यम से कदम बढ़ाता हूं और अगले पर जाता हूं, धीरे-धीरे पूरी तस्वीर का निर्माण करता हूं।

यदि परियोजना में यूनिट परीक्षण थे, तो मुझे भी उनके माध्यम से जाना पसंद है, वे हमेशा बहुत खुलासा और ज्ञानवर्धक होते हैं।

Answer 13

1. सभी परीक्षण चलाएं, यदि आपके पास कोई है, और देखें कि कौन सा कोड कवर किया गया है और कौन सा नहीं है।
2. यदि कोड जिसे आपको बदलने की आवश्यकता है, वह कवर नहीं है, तो इसे कवर करने के लिए परीक्षण लिखने का प्रयास करें।
3. कोड बदलें। परीक्षणों को न तोड़ें।

विरासत कोड के साथ प्रभावी रूप से माइकल फेदर्स देखें

Answer 14

यहाँ मेरी छोटी सूची है:

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

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

3. मूल दस्तावेज के परीक्षण और अन्य संकेतक देखें जो कोड के आंतरिक मानसिक मॉडल के निर्माण में सहायता कर सकते हैं। यह वह जगह है जहां मैं शायद कम से कम कुछ दिनों का सुझाव दूंगा जब तक कि बहुत कम प्रलेखन और परीक्षण न हों।

4. मैं इस परियोजना में प्रयुक्त भाषाओं और रूपरेखाओं को कितनी अच्छी तरह जानता हूँ? यहाँ कुछ चीजों को देखने और जाने के बीच का अंतर है, "हाँ, देखा कि एक दर्जन बार पहले और इसे काफी अच्छी तरह से जानते हैं," और "दुनिया में क्या यहाँ प्रयास किया जा रहा है? किसने सोचा कि यह एक अच्छा विचार था?" इस तरह के सवाल जो मैं उन्हें ज़ोर से नहीं कहूँगा, मैं उन्हें सोच रहा हूँ खासकर अगर मैं विरासत कोड को देख रहा हूँ जो काफी नाजुक हो सकता है और जिन लोगों ने इसे लिखा है वे अनुपलब्ध हैं या बस याद नहीं है कि क्यों चीजों को जिस तरह से किया गया था। नए क्षेत्रों के लिए, यह जानने के लिए कुछ अतिरिक्त समय बिताना सार्थक हो सकता है कि संरचना क्या है और इस कोड में मुझे कौन से पैटर्न मिल सकते हैं।

अंतिम लेकिन कम से कम नहीं: जो आप उम्मीद कर सकते हैं कि निम्नलिखित कुछ विचारों को देखते हुए समय पर प्रत्येक बिंदु पर आपको क्या करना चाहिए, इस संदर्भ में परियोजना चलाने वालों की अपेक्षाओं को जानें:

• क्या आप नई सुविधाओं में डाल रहे हैं?
• क्या आप कीड़े ठीक कर रहे हैं?
• क्या आप कोड को रीफ़्लैक्ट कर रहे हैं? क्या मानक आपके लिए नए हैं या वे बहुत परिचित हैं?
• क्या आप केवल कोड आधार के साथ खुद को परिचित करने वाले हैं?

Answer 15

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

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

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

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

Answer 16

मैं प्रलेखन आदि के साथ शुरू करने के लिए कहूंगा, लेकिन मेरे अनुभव में, प्रलेखन और स्थानीय ज्ञान की गहराई अक्सर एक प्रणाली की आयु, आकार और जटिलता के विपरीत आनुपातिक होती है।

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

मुझे लगता है कि यह बिना कहे चला जाता है, लेकिन मेरी राय में, तकनीकी दृष्टिकोण से प्रणाली को कार्यात्मक दृष्टिकोण से समझना बेहतर है। मैं आम तौर पर उन उपकरणों के बारे में बहुत अधिक चिंता नहीं करता, जिनका उपयोग किया जा रहा है (ORMs, लॉगिंग लाइब्रेरी आदि) और उपयोग किए जा रहे पैटर्न (MVP, आदि) पर अधिक ध्यान केंद्रित करें। मेरे अनुभव में, उपकरण आम तौर पर अधिक तरल पदार्थ होते हैं जो पैटर्न।

Answer 17

मैंने बहुत किया ...

यहां स्थितियों के लिए मेरा वर्तमान दृष्टिकोण है जब "कुछ काम कर रहा है", और आपको इसे "किसी अन्य तरीके से काम करने" की आवश्यकता है।

1. लक्ष्य प्राप्त करें, उस प्रणाली को हल करना चाहिए (यदि वे नहीं लिखे गए हैं) - इसे लिखें। प्रबंधक, अन्य कर्मचारियों से पूछें, भले ही वे उपलब्ध हों। ग्राहक से पूछें या प्रलेखन के किसी भी टुकड़े को खोजें।
2. विशिष्टता प्राप्त करें। यदि यह मौजूद नहीं है - इसे लिखें। यह इसके लिए किसी से पूछने के लायक नहीं है, जैसे कि यह मौजूद नहीं है, तो आप उस स्थिति में हैं जब अन्य बहुत परवाह नहीं करते हैं। तो केवल खुद को लिखने का तरीका (बाद में इसे संदर्भित करना बहुत आसान होगा)।
3. डिजाइन प्राप्त करें। मौजूद नहीं है - इसे लिखें। यथासंभव किसी भी दस्तावेज़ और स्रोत कोड को संदर्भित करने का प्रयास करें।
4. उस हिस्से को विस्तृत डिज़ाइन लिखें जिसे आपको बदलने की आवश्यकता है।
5. परिभाषित करें कि आप इसे कैसे परखते हैं। तो आप सुनिश्चित हो सकते हैं कि पुराने और नए कोड एक ही तरह से काम करते हैं।
6. सिस्टम को एक चरण में बनाने में सक्षम होना चाहिए। और पुराने कोड के साथ परीक्षण करें। यदि यह पहले से ही नहीं है तो इसे SVC में डाल दें।
7. परिवर्तन लागू करें। पहले नहीं।
8. एक या दो महीने के बाद सत्यापित करें कि कुछ भी नहीं टूटा है।

प्रत्येक चरण के बीच एक और वैकल्पिक टूडू की आवश्यकता हो सकती है: f ऑफ मैनेजर (प्रोजेक्ट मालिक) जो आपको बताता है कि "ये परिवर्तन पहले ही कल हो जाना चाहिए"। कुछ परियोजनाओं के बाद, वह पहले से चश्मा और डॉक्स प्राप्त करने में मदद करना शुरू कर सकता है।

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

पुनश्च: मुझे एक कोड याद है जो 5 ग्राहकों के लिए विभिन्न सेटिंग्स के साथ उपयोग किया गया था। और प्रत्येक परिवर्तन (नई सुविधा) के लिए "क्या भागों का उपयोग किया जाता है", और "क्या कॉन्फ़िगरेशन ग्राहकों के पास" ऐसा कुछ भी ब्रेक करने के लिए नहीं, और कोड को कॉपी करने के लिए नहीं की आवश्यकता थी। Cvs, और ऐनक लिखने के लिए अपनी सेटिंग्स को रखना, इस सोच समय को लगभग 0 तक कम कर देता है।

Comments

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

— andre

इसे विनम्रता से करने के कई तरीके हैं। उदा। अनुमान लिखें कि प्रत्यक्ष परिवर्तन में 30 घंटे लगेंगे, और इस योजना के अनुसार दूसरा अनुमान: 50 घंटे। दूसरे मामले में, लक्ष्य, कल्पना और डिजाइन भविष्य के परिवर्तनों के लिए बहुत समय बचाएगा। अगर प्रबंधक समझने को तैयार नहीं है, तो संभवतः आप भविष्य में इसे बदल नहीं पाएंगे, और आप स्थायी रूप से मिट्टी की गेंदों के साथ काम करेंगे। यह अन्य नौकरी खोजने के लिए अच्छा संकेतक हो सकता है? यदि वह योजना को स्वीकार करता है, तो बस उसे दिखाएं कि आप कहां हैं, जब वह "परिणाम, परिणाम, परिणाम" मांगता है।

— कॉन्स्टेंटिन पेट्रूख्नोव

Answer 18

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

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

यदि आप ऑब्जेक्ट-ओरिएंटेड भाषा का उपयोग कर रहे हैं, तो सामान्य वर्ग आरेख बनाने का प्रयास करें। यह आपको एक अच्छा उच्च-स्तरीय अवलोकन देगा।

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

Answer 19

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

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

Answer 20

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

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

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

छोटे कदम उठाएं, यहां तक ​​कि सबसे छोटे कोड परिवर्तन का बड़ा प्रभाव हो सकता है।

मुझे लगता है कि यह प्रोग्राम कोड फ़्लो के साथ आने में मददगार है, इसलिए यदि मैं बदलाव कर रहा हूं, तो मैं यह देखने के लिए निर्भरता खोज कर सकता हूं कि कौन से तरीके / तरीके कॉल करते हैं। मान लीजिए मैं विधि C बदल रहा हूं।

यदि केवल 1 विधि / फ़ंक्शन सी कॉल करता है, तो यह एक बहुत ही सुरक्षित बदलाव है। यदि 100 विधियाँ / कार्य C को बुलाते हैं, तो यह अधिक प्रभाव वाला होगा।

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

यदि यह कीचड़ की एक बड़ी गेंद है, तो आप इसके आंतरिक कामकाज को कभी नहीं समझ सकते (या समझना चाहते हैं)।

Answer 21

कुछ चीजें जो मैं करता हूं ...

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

2) ग्रहण में कोड के ऊपर से नीचे तक ड्रिल करें (एक संपादक के लिए अच्छा है जो संदर्भों को ब्राउज़ कर सकता है, आदि) जब तक मुझे पता नहीं चलेगा कि कोड आधार में क्या चल रहा है और कहां है।

3) कभी कभी, मैं चित्र में आकर्षित Visio वास्तुकला का एक बेहतर तस्वीर प्राप्त करने के लिए। यह प्रोजेक्ट पर दूसरों के लिए भी मददगार हो सकता है।

Answer 22

ऐसा बहुत होता है। जब तक मैंने एक ओपन सोर्स प्लेटफ़ॉर्म पर काम करना शुरू नहीं किया, मुझे नहीं लगता कि मैंने कभी भी एक नौकरी शुरू की जो एक एडमिशन के साथ शुरू नहीं हुई थी कि कोड में कुछ 'quirks' थे।

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

Answer 23

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

क्या जोड़ी प्रोग्रामिंग एक विकल्प है? विचारों को उछालने के लिए किसी अन्य व्यक्ति के पास होने से उस राशि का बुरा व्यवहार करने के लिए एक महान विचार है।

Comments

बिग बॉल ऑफ मड की समस्याओं में से एक यह है कि इकाई परीक्षणों को लिखने के लिए इसकी कोई उचित सीमा नहीं है। एक बार जब आप उस बिंदु पर पहुंच जाते हैं, जहां आप ठीक से परीक्षण कर सकते हैं, तो आप बहुत अधिक जीत गए हैं।

— डोनाल्ड फेलो

लेकिन, यदि आप कोड को संशोधित करने की शुरुआत कर रहे हैं, तो आपके पास अभी भी यूनिट परीक्षण होना चाहिए ताकि, आपको पता चले कि आपने कब फिक्स पूरा किया है।

— डेविड वीसर

Answer 24

यहाँ एक प्रक्रिया है जिसका उपयोग हम डुप्लिकेट को समाप्त करने के लिए करते हैं।

• डुप्लिकेट के लिए एक मानक टिप्पणी उपसर्ग का चयन करें (हम [dupe]टिप्पणी मार्कर के बाद सही उपयोग करते हैं ;
• डुप्लिकेट प्रक्रिया के लिए उपयोग करने के लिए नामों के बारे में अपनी टीमों के साथ चश्मा लिखें;
• पहला दौर: हर कोई कुछ फाइलें लेता है, और [dupe][procedure_arbitrary_name]डुप्लिकेट प्रक्रिया से पहले जोड़ता है ;
• दूसरा दौर: हर कोई एक प्रक्रिया, या प्रक्रिया का एक सबसेट लेता है, और अलग-अलग समान उद्देश्य कार्यान्वयनों की समानता के क्रम को दर्शाता हुआ एक मान प्रदान करता है (स्ट्रिंग तब होगा:) [dupe][procedure_arbitrary_name][n];
• तीसरा दौर: प्रत्येक प्रक्रिया के लिए जिम्मेदार इसे संबंधित वर्ग में फिर से लिखता है;
• चौथा दौर: grepखुश!

Answer 25

मुझे लगता है कि सबसे महत्वपूर्ण चीजों में से एक है एक साधारण सुविधा लेना, सबसे सरल जिसे आप सोच सकते हैं उसे चुनें और इसे लागू करें। यदि कोई अनुरक्षित इच्छा सूची का उपयोग होता है या कोड आधार से परिचित किसी व्यक्ति से बात करता है और उन्हें एक सुविधा का सुझाव देने के लिए मिलता है। आमतौर पर मैं यह उम्मीद करूंगा कि यह 5 ~ 20 LOC के साथ एक बदलाव होगा। महत्वपूर्ण बिंदु यह नहीं है कि आप एक बहुत ही फैंसी फीचर जोड़ रहे हैं, बल्कि यह कि आप कोड बेस के साथ काम कर रहे हैं (या बल्कि :)) और पूरे वर्कफ़्लो के माध्यम से जा रहे हैं। आपने ऐसा कर लिया होता

1. उस घटक को समझने के लिए कोड पढ़ें जिसे आप संशोधित कर रहे हैं
2. कोड बदलें और समझें कि यह आसपास के सिस्टम को कैसे प्रभावित करता है।
3. परिवर्तन का परीक्षण करें और इस प्रकार पहचानें कि घटक एक दूसरे के साथ कैसे बातचीत करते हैं
4. परीक्षण के मामले को लिखें और उम्मीद है कि एक या दो परीक्षण मामलों को तोड़ दें ताकि आप उन्हें ठीक कर सकें और सिस्टम के आक्रमणकारियों को समझ सकें।
5. बात का निर्माण करें या देखें सीआई निर्माण करें और फिर इसे शिप करें

सूची आगे बढ़ती है लेकिन बिंदु यह है कि इस तरह की एक मिनी परियोजना आपको सिस्टम के साथ परिचित होने के लिए आपकी चेक सूची में सभी वस्तुओं के माध्यम से ले जाती है और इसके परिणामस्वरूप एक उत्पादक परिवर्तन भी किया जाता है।

Answer 26

एक छोटी सी बात जो मैं जोड़ना चाहता था:

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

मैं मन मानचित्रण विकल्पों की अधिकता के बीच मुक्त विमान का उपयोग करने की सलाह देता हूं ।

Answer 27

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

टीम के लिए भंडार में सब कुछ प्राप्त करें और एक शब्दावली जोड़ें। सभी ठिकानों पर शब्दजाल है; इसे शब्दावली में दस्तावेजित करें। उपकरण, उत्पाद, ग्राहक-विशिष्ट आदि के लिए अनुभाग बनाएं।

एक सॉफ्टवेयर पर्यावरण निर्माण दस्तावेज़ बनाएं / अपडेट करें। सभी उपकरण, quirks, विकल्प स्थापित करें, आदि यहाँ जाते हैं।

फिर "ProductName" दस्तावेज़ या पसंद के साथ एक आरंभ करना अपलोड करें। समय के साथ बस मन प्रवाह और स्वयं को व्यवस्थित होने दें। फिर डेट आउट से गुजरें और उन्हें वापस तारीख पर ले जाएँ। अन्य डेवलपर्स इसकी सराहना करेंगे, आप कोड सीखने के दौरान एक अनोखे तरीके से योगदान देंगे। खासतौर पर ऐसी सभी चीजों का दस्तावेज, जो आपको स्टंप करती हैं या जिनका नाम गलत है या जो प्रति-सहज हैं।

एक बार जब आपका झुकाव वक्र समाप्त हो रहा है, तो दस्तावेज़ को अपडेट करने के बारे में चिंता न करें। अगले नए आदमी को ऐसा करने दो। जब वह आए तो उसे अपने काम की ओर इशारा करें। जब वह लगातार आपको जवाब देता है, तो उसका जवाब न दें। बल्कि, अपने दस्तावेज़ में प्रश्न जोड़ें और फिर उसे url सौंप दें। मछली पकड़ने का डंडा।

एक दुष्परिणाम यह है कि आपने एक ऐसा उपकरण बना लिया है जिसे आप खुद भूल सकते हैं।

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

Answer 28

मैंने इस विषय पर काफी लंबी पोस्ट लिखी है। यहाँ एक अंश है

मैंने इस समस्या के बारे में काफी समय तक सोचा। मैंने एक सामान्य प्रक्रिया के रूप में अपना निजी समाधान लिखने का फैसला किया। मेरे द्वारा प्रलेखित चरण इस प्रकार हैं:

1. शब्दावली शीट बनाएँ
2. एप्लिकेशन जानें
3. उपलब्ध दस्तावेज़ ब्राउज़ करें
4. मान लें
5. थर्ड पार्टी लाइब्रेरी का पता लगाएँ
6. कोड का विश्लेषण करें

यह प्रक्रिया एक बड़े डेस्कटॉप एप्लिकेशन के संदर्भ में लिखी गई है, लेकिन सामान्य तकनीक अभी भी वेब एप्लिकेशन और छोटे मॉड्यूल पर लागू होती है।

से लिया गया: एक नया कोडबेस सीखने के लिए एक प्रक्रिया

Answer 29

कुछ छोटे-छोटे टिप्स हैं जिन्हें मैं साझा कर सकता हूं।

मौजूदा उत्पाद के लिए, मैं उनका गहन परीक्षण करना शुरू करता हूं। यदि कोई कार्य सौंपा / प्राप्त किया जाता है, तो मैं विशेष सुविधा पर अधिक ध्यान केंद्रित करूंगा।

• अगला चरण वह कोड ढूंढना होगा जहां मैं टूट सकता हूं और खोज शुरू कर सकता हूं जिस तरह से मैं निर्भर मॉड्यूल, लाइब्रेरी, फ्रेमवर्क आदि ढूंढूंगा।

• अगला कदम जिम्मेदारियों के साथ सरल वर्ग आरेख बनाना होगा (जैसे CRC कार्ड)

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

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

Answer 30

मुझे एक बड़े कोड बेस में गोता लगाने के लिए एक लंबा समय हो गया है। लेकिन हाल के कुछ वर्षों में मैंने नए डेवलपर्स को टीमों में लाने के लिए कई बार कोशिश की, जहां हमारे पास मौजूदा, बल्कि बड़े, कोड आधार थे।

और जिस विधि का हमने सफलतापूर्वक उपयोग किया है, और मैं कहूंगा कि प्रश्न IMHO के बिना सबसे प्रभावी तरीका है, जोड़ी प्रोग्रामिंग है।

पिछले 12 महीनों में, हमारे पास टीम में 4 नए सदस्य हैं, और हर बार, नया सदस्य किसी अन्य सदस्य के साथ कोड आधार से अच्छी तरह से परिचित होगा। शुरुआत में, टीम के पुराने सदस्य के पास कीबोर्ड होगा। लगभग 30 मिनट के बाद हम नए सदस्य को कीबोर्ड देंगे, जो टीम के पुराने सदस्य के मार्गदर्शन में काम करेगा।

यह प्रक्रिया काफी सफल साबित हुई है।

Comments

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

— मिकू