2009-01-17 9 views
5

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

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

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

क्या आप छोटे चरणों में प्रतिक्रिया करते हैं और कम आवृत्तियों में अखंड कोड उत्पन्न करने का प्रयास करते हैं? और: क्या आप ऐसा करने में सफल हैं?

+0

यह विकी होना चाहिए। –

+0

@ocdecio यह नहीं देखते कि यह विकी क्यों होना चाहिए। यह एक मतदान नहीं है – krosenvold

+0

मेरी सोच यह थी कि यह कहना मुश्किल होगा कि कोई जवाब सही है। और इसे एक मतदान माना जा सकता है - छोटे बड़े बनाम छोटे कदम। ओह ठीक है, पर्याप्त नाइटपिकिंग। –

उत्तर

6

मार्टिन फाउलर छोटे, धीरे-धीरे रिफैक्टरिंग दृष्टिकोण की तरफ झुकता प्रतीत होता है। हालांकि, अपनी पुस्तक पढ़ने के बाद वह कभी-कभी कुछ कठोर कदम उठाता है लेकिन केवल कोड का बैक अप लेने के लिए यूनिट परीक्षणों के साथ करता है।

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

1

मैं ज्यादातर समय बड़े पैमाने पर प्रतिक्रिया करता हूं ताकि मैं पेड़ से जंगल देख सकूं। यह प्रोग्रामिंग की तरह "चेतना की धारा" है। जब तक आपका आखिरी कामकाजी संस्करण आपके स्रोत नियंत्रण में सुरक्षित रहता है ...

+0

जिसने आपको "प्रोग्रामिंग का राजा" बनाया है? : बी –

+0

गीज़ .. यह वर्तनी जांचकर्ताओं के साथ समस्या है, वे आपके असली इरादे का अनुमान नहीं लगा सकते :) धन्यवाद दोस्त। –

0

वह जगह है जहां "लाल, हरा, रिफैक्टर" दृष्टिकोण उपयोगी है। प्रत्येक चरण में आपके पास यह सत्यापित करने की क्षमता है कि आपके कोड का व्यवहार अपरिवर्तित है, और रिफैक्टरिंग को केवल नए व्यवहार को एकीकृत करना है।

4

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

0

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

60 मिनट पर आप निश्चित हैं कि आपका कोड ठीक वही कर रहा है जो यह होना चाहिए। पास करने के लिए आपको बहुत सारे परीक्षणों की आवश्यकता होगी। मैं बस कोशिश करता हूं और एक जा रहा हूं और फिर अगले स्थान पर जाता हूं।

0

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

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

3

हाँ, हमेशा। मुझे लगता है कि रिफैक्टरिंग का असली सार चुनने के लिए कौन से कदम उठाए जा रहे हैं।

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

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

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

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

लेकिन यह इनाम के लिए सीधे जाने के लिए आकर्षक है।

0

मैं आमतौर पर कोड को प्रतिबिंबित करता हूं क्योंकि मैं इसे बदलता हूं। यही है, कोड का एक टुकड़ा लेने और इसके कार्य को बनाए रखने के दौरान इसे फिर से लिखने के बजाय, मैं इसे एक नई कार्यक्षमता की ओर लिखता हूं और ऐसा करने की प्रक्रिया में मैं कोड के डिजाइन में सुधार करता हूं।

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

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

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

0

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

एनबी। जिस कोड-बेस पर मैं काम करता हूं वह काफी पुराना है, और वैज्ञानिकों के नाम पर उन रहस्यमय बगों से भरा है। बड़े हिस्सों में अभी भी 50% परीक्षण कवरेज के करीब कुछ भी कमी है, इसे दूर ले जाने के लिए लापरवाही होगी।

0

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

संबंधित मुद्दे