मैं एक स्प्रिंट से अधिक समय तक रिफैक्टरिंग को कैसे संभाल सकता हूं?


49

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

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

हम एक स्प्रिंट को बंद या विस्तारित नहीं कर सकते क्योंकि हमारे पास मासिक हॉटफ़िक्स हैं। तो स्प्रिंट के पिछले विस्तार से यह परिवर्तन अन्य कार्य को हॉटफिक्स में जोड़े जाने से नहीं रोक सकता।

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

उत्तर:

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


23
एक साइड नोट के रूप में, यह परिभाषा बड़े पैमाने पर रीडिजाइन द्वारा है, रिफैक्टिंग नहीं । आशा है कि आप इसे नाइटपिटिंग के रूप में नहीं लेंगे - IMHO संचार समस्याओं से बचने के लिए स्पष्ट शब्दावली का उपयोग करना महत्वपूर्ण है :-)
पेटर टॉरक

9
@Charles, "रीफ़ैक्टरिंग आमतौर पर छोटे चरणों में किया जाता है। प्रत्येक छोटे कदम के बाद, आपको एक ऐसी कार्य प्रणाली के साथ छोड़ दिया जाता है जो कार्यात्मक रूप से अपरिवर्तित होती है। " पृष्ठ से उद्धरण जो मैंने ऊपर जोड़ा है।
पीटर टॉर

2
@Charles: सिस्टम को कार्यशील रखते हुए, रिफैक्टरिंग हमेशा बढ़ाई जा सकती है। क्लास / पैकेज / मॉड्यूल के शीर्ष पर एक बड़ी "रिफ़ेक्टिंग इन प्रोग्रेसिंग" टिप्पणी डालें जिसे रिफ़्लेक्ट किया जा रहा है, और भागों को एक बार में करें। यदि आप अंतरिम रिलीज़ को काटते हैं जबकि ऑब्जेक्ट मॉडल संक्रमण में है, तो यह ठीक है।
सीन मैकमिलन

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

5
मुझे पता है कि यह थोड़ा बंद विषय है, लेकिन आपने मुझे इस बात के बारे में जानने के लिए जिज्ञासु बना दिया कि जो हालात हैं, वे छोटे कदमों में रिफैक्टिंग को असंभव बना देते हैं। कृपया इस बारे में कुछ और पृष्ठभूमि साझा करें।
बुहब २०

जवाबों:


14

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


68

मेरा सुझाव:

  1. एक शाखा बनाएँ
  2. अपनी शाखा में ट्रंक से दैनिक विलय करें और संघर्षों को हल करें।
  3. काम पूरा होने तक। आपकी शाखा कई क्षेत्रों के लिए मुख्य विकास से बाहर हो सकती है।
  4. ट्रंक में वापस विलय।

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


1
हमने इस दृष्टिकोण का उपयोग करने पर चर्चा की है, और इससे निपटने से पहले अगर कोई अन्य विचार सामने नहीं आता है, तो हम यही करते हैं।
चार्ल्स लैम्बर्ट

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

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

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

1
@ जियोर्जियो: तो मैं, दैनिक मर्ज थोड़ा पागल लगता है, लेकिन फिर यह वास्तव में टीम के आकार पर निर्भर करता है। जितने अधिक लोग, उतने अधिक परिवर्तन, और उतने अधिक बार आपको विलय करना चाहिए। यदि आप काम करने के लिए समय चाहते हैं तो दैनिक नीचे की सीमा लगता है।
Matthieu M.

40

प्रत्येक कार्य एक (कृत्रिम) 2-सप्ताह के स्प्रिंट में नहीं किया जा सकता है, इसलिए सामान्य ज्ञान के लिए कहा जाता है। यदि इसे और अधिक नहीं तोड़ा जा सकता है, और इसे किया जाना चाहिए, बस इसे प्राप्त करें और करें। यह प्रक्रिया अंतिम परिणाम से अधिक महत्वपूर्ण नहीं है, और इसे एक कभी न टूटने वाले कानून के बजाय एक दिशानिर्देश के रूप में देखा जाना चाहिए।


3
आपका उत्तर विषय पर बहुत अच्छी जानकारी है। मैं यहाँ हूँ "जैसा तुम कहो वैसा करो और करो"। मैंने कुछ जानकारी प्राप्त करने की उम्मीद में सवाल पूछा ताकि मैं या तो अपनी मौजूदा स्थिति के समानांतर चलने की प्रक्रिया के साथ आ सकूं, या किसी तरह अपनी मौजूदा स्थिति को हल करने के लिए वर्तमान प्रक्रिया को संशोधित कर सकूं। मुझे डेवलपर्स को बताने के लिए कुछ चाहिए ताकि उनके पास दिशा-निर्देश हों कि कौन से काम करना है, क्योंकि यह कम से कम 2 बार हो रहा होगा।
चार्ल्स लैम्बर्ट

+1 के लिए "प्रक्रिया अंतिम परिणाम की तुलना में अधिक महत्वपूर्ण नहीं है, और इसे कभी भी न टूटने वाले कानून के बजाय एक दिशानिर्देश के रूप में देखा जाना चाहिए।" - लोग वास्तव में इसे भूल जाते हैं।
Bjarke Freund-Hansen

32

बस एक 3, 4 या 5 सप्ताह स्प्रिंट करते हैं। किसे पड़ी है? आप स्पष्ट रूप से आश्वस्त हैं कि कम समय सीमा में कुछ भी नहीं किया जा सकता है, इसलिए इसे लड़ना बंद करें।

सिर्फ रॉयल सोसाइटी ऑफ ब्लाइंड एजाइल एडहेरेंस में अपने साथियों को न बताएं।


ऐसा लगता है कि संगठनात्मक कारणों (मासिक हॉटफ़िक्स) के लिए, 2 सप्ताह स्प्रिंट बदलने के लिए बहुत कठिन हैं।
स्टीव बेनेट

10

मैं माइकल फेदर द्वारा लिगेसी कोड के साथ वर्किंग इफेक्टिवली बुक शुरू करने की सलाह देता हूं । वह कई तरह की तकनीकों को शामिल करता है ताकि रिफैक्टिंग-स्टाइल में बदलाव की गुंजाइश कम हो सके।


यकीन के लिए एक अच्छी किताब है, लेकिन मुझे नहीं लगता कि यह कई क्षेत्रों में बंटवारे को कवर करती है।
एडम लेअर

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

@ अन्ना - तब आप (२५) अध्याय २५ को पढ़ सकते हैं, जो छोटे-छोटे बदलावों के प्रकारों को तोड़ने के लिए तकनीकों के बारे में बात करता है।
kdgregory

@kdgregory मेला काफी :) इसे और अधिक भयानक बनाने के लिए अपने जवाब में मन जोड़ने?
एडम लेअर

7

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

अधिक संक्षेप में, हम नए नामों का उपयोग करके बड़े कार्यों को तोड़ते हैं या फिर से काम करते हैं। फिर, अंत में, हम पुराने पुराने कोड के बजाय अपने पुनर्नामित, परिशोधित कार्य का उपयोग करते हैं।


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

5

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


यह सब हम पहले ही कर चुके हैं। यही कारण था कि मैंने स्पष्ट रूप से व्यक्त किया कि इसे तोड़ा नहीं जा सकता।
चार्ल्स लैम्बर्ट

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

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

मैंने कहा: "एक स्प्रिंट को समर्पित करना यह पता लगाना कि कोड को ठीक से मध्य-रिफ्लेक्टर को कैसे रखा जाए।" आपने कहा, "हम पहले ही यह सब कर चुके हैं।" क्या अब आप अन्यथा कह रहे हैं? मुझे खेद है अगर यह विवादास्पद लगता है, लेकिन मुझे समझ में नहीं आता है।
कार्ल मैनस्टर

5

कॉर्बिन मार्च के उत्तर पर +1, ठीक वैसा ही जैसा मैं सोच रहा था। ऐसा लगता है कि आपका कोड-बेस थोड़ा बदसूरत है और इसे साफ करने के लिए एक एकल स्प्रिंट चक्र से अधिक लेने जा रहा है।
तो जैसे कॉर्बिन ने कहा,

  1. इसे "रीफैक्टरिंग प्रोजेक्ट" में शाखा दें
  2. अपनी शाखा परिवर्तन का परीक्षण करें
  3. QA परीक्षण के लिए अपने परीक्षण वातावरण को बढ़ावा देना
  4. वृद्धिशील रूप से इसे वापस ट्रंक में विलय कर देता है जब तक कि रिफैक्टिंग नहीं किया जाता है।

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


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

4

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

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


3

इस समय मैं जिस परियोजना के लिए काम कर रहा हूं, उसमें हम 4 सप्ताह के स्प्रिंट का उपयोग कर रहे हैं। और कभी-कभी हम एक उपयोगकर्ता कहानी को समाप्त नहीं कर सकते हैं और हम निम्नलिखित स्प्रिंट के दौरान इसे फिर से शुरू करते हैं।

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


एक 4 सप्ताह स्प्रिंट इसे कवर करना चाहिए। हालांकि हम अन्य बग फिक्स के कारण वर्तमान 2 सप्ताह स्प्रिंट को रोक नहीं सकते हैं, इसलिए इसे एक से अधिक स्प्रिंट के माध्यम से विस्तारित करना होगा। इस प्रकार मेरी समस्या की जड़।
चार्ल्स लैंबर्ट

जैसा कि मैंने कहा, हम 4 सप्ताह स्प्रिंट का उपयोग कर रहे हैं और, यदि कोई कहानी 4 सप्ताह में समाप्त नहीं होती है, तो हम इसे अगले स्प्रिंट के लिए निर्धारित करते हैं। क्या आप कम से कम 2 सप्ताह के स्प्रिंट के अंत में एक सुसंगत स्थिति में सिस्टम (और फिर निम्नलिखित स्प्रिंट के दौरान जारी रख सकते हैं)?
जियोर्जियो

नहीं एक निरीक्षण लगातार राज्य।
चार्ल्स लैम्बर्ट

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

2

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

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


हम इसे हमेशा के लिए बंद नहीं कर सकते हैं, और आपका जवाब पता नहीं है कि रिफैक्टरिंग कैसे करें।
चार्ल्स लैम्बर्ट

@Charles: 'दूसरी बार स्लेट किया गया।' ;) मैंने यह नहीं कहा कि परियोजना को रद्द करें।
आइब्रीस्ट

2

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

अन्य उत्तरों के बारे में मुझे दो छोटे नोट यहाँ दें:

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

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

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

एक स्क्रैच रिफैक्टरिंग करें और इसे इस तरह से व्यवहार करें। (एक प्रकार का "थ्रो-दूर" प्रोटोटाइप रिफैक्टरिंग, "थ्रो-दूर" बिट महत्वपूर्ण है!) ईमानदारी से, यह संभव नहीं है कि आप जानते हैं कि आपके रिफैक्टरिंग के सभी निहितार्थ होंगे। एक खरोंच refactoring कुछ संबंध में आपकी मदद करेगा:

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

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

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

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


1

एक रखरखाव खिड़की शुरू करें जिसके दौरान कोई और विकास नहीं किया जाता है। रीडिज़ाइन निष्पादित करें, फिर विकास स्प्रिंट फिर से शुरू करें।


0

हमारे हाथ में दो तरह के काम हैं:

  1. मानव-घंटे काम करता है
  2. प्रतिभा काम करती है

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


0

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

एक अन्य तरीका यह है कि आपत्तिजनक कोड की एक प्रति तैयार करें, इसे रिफलेक्टर करें और फिर एक बार नए कोड में ग्राहकों को स्थानांतरित करें। इस काम को पुनरावृत्तियों में तोड़ा जा सकता है।

और हार मत मानो: बस स्वीकार मत करो कि एक बड़े रिफैक्टिंग को छोटे चरणों में नहीं तोड़ा जा सकता है। सबसे आसान / सबसे तेज़ / सबसे अच्छा तरीका एक चलना से अधिक समय लग सकता है। लेकिन इसका मतलब यह नहीं है कि पुनरावृत्ति के आकार का हिस्सा करने का कोई तरीका नहीं है।

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