मैं सोच रहा था कि अन्य डेवलपर्स कैसे रिफैक्टरिंग शुरू करते हैं। आपका पहला कदम क्या है? यदि आप कोड को दोबारा कॉन्फ़िगर करते हैं तो यह प्रक्रिया (रिफैक्टरिंग) अलग-अलग कैसे होती है? क्या आप रिफैक्टरिंग करते समय परीक्षण लिखते हैं?आप कैसे प्रतिक्रिया करते हैं?
* सूखी = अपने आप को दोहराना नहीं
+०१२३५१६४१०DRY = अपने आप को दोहराना न करें, मुझे तब तक पता नहीं चला जब तक मैंने इसे देखा, इसलिए मैंने सोचा कि मैं दूसरों को एक सिर दूंगा। –
@ [निमो]: धन्यवाद, स्पष्टता के लिए संपादित –
(1) वास्तव में किसी गैर-तुच्छ कोडबेस पर काम नहीं करता है। –
मेरे लिए पहली बात यह सुनिश्चित करती है कि कोड हमारे कार्यालय के सभी सर्वोत्तम प्रथाओं को हिट करता है। उदाहरण के लिए, हमारी पर्ल स्क्रिप्ट के लिए सख्त, चेतावनियां और रंग का उपयोग करना।
यदि प्रभावशीलता या गति समस्याएं उन पर ध्यान केंद्रित करती हैं। चीजें बेहतर एल्गोरिदम खोजने की तरह हैं, या लूप के लिए चौकोर रूप से घोंसला करने के लिए एक बेहतर तरीका ढूंढ रहा है।
और आखिरकार देखें कि कोड को और अधिक पठनीय बनाने का कोई तरीका है या नहीं। यह आम तौर पर 5 छोटी लिपियों को बदलकर पूरा किया जाता है जो समान रूप से 1 मॉड्यूल (कक्षा) में काम करते हैं।
यूनिट परीक्षणों का उपयोग करते हुए मैं नया कोड लिखते समय रिफैक्टर हूं। यदि पुराने तरीके बहुत अधिक हैं, या तो बुरी तरह से वैरिएबल हैं, या मैं डुप्लिकेशंस इत्यादि स्पॉट करता हूं, तो मैं पुराने कोड को दोबारा दोहरा दूंगा, या मैं डुप्लिकेशंस आदि को स्पॉट करता हूं।
यूनिट परीक्षण प्राप्त करने के साथ शुरू करें, और फिर स्वचालित रीफैक्टरिंग टूल का उपयोग करें। यदि रिफैक्टरिंग स्वचालित नहीं की जा सकती है तो यह वास्तव में कोड का यांत्रिक परिवर्तन नहीं है और इसलिए एक रिफैक्टरिंग नहीं है। यूनिट परीक्षण यह सुनिश्चित करने के लिए हैं कि आप वास्तव में एक कोडबेस से समकक्ष में यांत्रिक परिवर्तन कर रहे हैं।
मैं बकवास लेता हूं और इसे कम क्रोधित करता हूं। :-)
गंभीरता से। मैं नई कार्यक्षमता बनाने के लिए प्रतिक्रिया नहीं करता हूं। रिफैक्टरिंग नई सामग्री से पहले होती है। यदि कोई परीक्षण नहीं है तो मैं यह सुनिश्चित करने के लिए परीक्षण लिखता हूं कि मैं अपने रिफैक्टरिंग के साथ कुछ भी नहीं तोड़ रहा हूं। यदि परीक्षण हैं, तो मैं उन का उपयोग करता हूं। यदि परीक्षण अपर्याप्त हैं, तो मैं अधिक परीक्षण लिख सकता हूं लेकिन मैं इसे रिफैक्टरिंग से अलग मानता हूं और इसे पहले करता हूं।
मेरे लिए पहला कदम यह ध्यान रखना है कि मैं कुछ अमूर्त कर सकता हूं और इसे अधिक सामान्य बना सकता हूं (और अन्य जगहों पर उपयोगी जो अब कार्यक्षमता की आवश्यकता है), या मुझे लगता है कि कुछ खराब है और बेहतर (व्यक्तिपरक) हो सकता है। मैं बिना किसी कारण के सामान्यता के प्रति प्रतिक्रिया करता हूं। YAGNI principle लागू होता है।
हमारे पास साझा स्वामित्व की अवधारणा है इसलिए कोड हमेशा मेरा होता है - मैंने इसे लिखा नहीं होगा, लेकिन मुझे लगता है कि जब रिफैक्टरिंग नहीं होती है। इससे पहले कि मैं यह निर्णय लेता हूं कि उद्देश्य स्पष्ट नहीं है, तो मैं इसे समझने से पहले चीजों को समझने की कोशिश कर सकता हूं - हालांकि यह लगभग हमेशा और खुद को रिफैक्टर करने का कारण है।
यूनिट टेस्ट के बिना रिफैक्टरिंग खतरनाक है। हमेशा इकाई परीक्षण है। यदि आप अच्छे परीक्षण किए बिना कुछ बदलते हैं तो आप कोड के कुछ हिस्सों के लिए सुरक्षित हो सकते हैं लेकिन कहीं और कुछ भी वही व्यवहार नहीं हो सकता है। यूनिट परीक्षण के साथ आप किसी भी बदलाव की रक्षा करते हैं।
रिफैक्टरिंग अन्य कोड भी ठीक है लेकिन चरम नहीं है। यह सामान्य है कि कोई और आपके जैसा प्रोग्राम नहीं करता है। सामान बदलने के लिए यह "दयालु" नहीं है क्योंकि आप इसे दूसरी तरफ करते थे। अगर यह वास्तव में जरूरी है तो बस refactoring।
मैं डुप्लिकेशन को हटाता हूं, जो कोड में अंतर्निहित विचार पैटर्न को एकीकृत करता है। रिफैक्टरिंग उन दो चीजों को हासिल करने की जरूरत है। यदि आपके पास कोड है जो दो बार एक ही चीज़ करता है, तो इसे एक सामान्य स्थान पर दोबारा जोड़ दें, अबास्ट्रक्शन को एकीकृत करें। यदि आपके पास तीन स्थानों पर एक ही शाब्दिक है, तो इसे निरंतर रखें, उद्देश्य को एकीकृत करें। यदि आपके पास तर्कों का एक ही समूह है, तो सुनिश्चित करें कि वे हमेशा एक ही क्रम में उपयोग किए जाते हैं या बेहतर, उन्हें एक सामान्य संरचना में डालकर, सूचना समूहों को एकीकृत करते हैं।
पढ़ें Martin Fowler की पुस्तक "Refactoring"
Btw - कि, मार्टिन Fowler के अपने अमेज़न कार्यकारी लिंक है आप :)
कुछ लिंक जोड़ें! – MrBoJangles
और उसका नाम सही प्राप्त करें;) –
ओउप्स! धन्यवाद दोस्तों। मुझे लगता है कि मेरे जवाब refactor करने के लिए एक अच्छा बहाना – MarkJ
जब आप कोड आप पुनर्रचना कर रहे हैं मैं दूसरे पोस्टर से सहमत सोच रहे हैं लिखा था।
यदि यह कोड है जिसे आपने नहीं लिखा है, और विशेष रूप से यदि इसमें बहुत कुछ है, तो मैं fxCop, विजुअल स्टूडियो के कोड विश्लेषण, देवपार्टनर जैसे टूल का उपयोग करके शुरू करूंगा - मुझे यकीन है कि अन्य अच्छे भी हैं। वे आपको कहां से शुरू करना चाहते हैं और सबसे आम कोडिंग मुद्दे क्या हैं, इस बारे में आपको विचार देंगे। मैं यह देखने के लिए तनाव परीक्षण भी करूंगा कि बाधाएं कहां हैं, इसलिए कोड को बेहतर बनाने के आपके प्रयास पर सबसे बड़ी वापसी।
मुझे अपने कोड को दोबारा प्रतिक्रिया करना अच्छा लगता है, लेकिन इसे अधिक करना संभव है। यदि आप वास्तव में ऐप के प्रदर्शन में सुधार नहीं कर रहे हैं, या कोड पठनीयता में गंभीरता से सुधार कर रहे हैं, तो आपको शायद रोकना चाहिए। जब आप रिफैक्टर करते हैं तो हमेशा नई बग पेश करने की संभावना होती है, खासकर यदि आप यूनिट परीक्षण के बिना काम कर रहे हैं।
मेरे लक्ष्यों पर बहुत अधिक निर्भर करता है। जैसा कि कहा गया है, आपको यह सुनिश्चित करने के लिए यूनिट परीक्षण की आवश्यकता है कि आपके रिफैक्टरिंग ने कुछ भी तोड़ा नहीं है, और यदि आपको इसे ठीक करने के लिए समय देना है। कई परिस्थितियों में, मैं मौजूदा समाधान का परीक्षण करता हूं, और यदि यह काम करता है, तो इसे रीफैक्टर करने की बजाय इसे लपेटें, क्योंकि इससे ब्रेक की संभावना कम हो जाती है।
अगर मुझे रिफैक्टर करना है, उदाहरण के लिए मुझे हाल ही में यूनिकोड के लिए एएससीआईआई आधारित सी ++ का एक गुच्छा बंद करना पड़ा, तो मुझे यकीन है कि मेरे पास अच्छा रिग्रेशन परीक्षण है जो अंत उपयोगकर्ता के साथ-साथ यूनिट स्तर पर भी काम करता है। दोबारा, मैं मैन्युअल रूप से रीफैक्टरिंग के बजाए टूल का उपयोग करने की कोशिश करता हूं, क्योंकि यह त्रुटि से कम प्रवण होता है, और आपके द्वारा प्राप्त त्रुटियों को यादृच्छिक के बजाय व्यवस्थित किया जाता है।
मैं अपने आप को दोबारा करने के बजाय दूसरों द्वारा लिखे गए कोड को दोबारा प्रतिक्रिया करने के लिए बहुत अधिक अनिच्छुक हूं।
यदि यह मेरे पूर्ववर्तियों में से एक द्वारा लिखा गया है, तो मैं आम तौर पर केवल एक फ़ंक्शन के भीतर प्रतिक्रिया करता हूं। जैसे मैं एक स्विच के साथ एक if स्टेटमेंट को प्रतिस्थापित कर सकता हूं। उससे कहीं अधिक बड़ा आमतौर पर दायरे से बाहर है और बजट के भीतर नहीं है।
मेरे अपने कोड के लिए, मैं आमतौर पर प्रतिक्रिया करता हूं क्योंकि मैं लिख रहा हूं, जब भी कुछ बदसूरत लग रहा है या गंध शुरू होता है। सड़क के नीचे समस्याओं का कारण बनने की प्रतीक्षा करने के बजाय अब इसे ठीक करना बहुत आसान है।
आपका पहला कदम क्या है?
पहला कदम यह सुनिश्चित करने के लिए यूनिट परीक्षण चलाने के लिए है कि वे सभी पास हो जाएं। दरअसल, आप बड़ी संख्या में समय बर्बाद कर सकते हैं कि आपके परिवर्तनों में से एक परीक्षण तोड़ दिया गया है अगर यह से पहले कोड को संशोधित कर चुका है।
यदि आप कोड को दोबारा कॉन्फ़िगर करते हैं तो यह प्रक्रिया भिन्न होती है जो आपकी नहीं है?
मैं निश्चित रूप से छोटे कदम उठा रहा हूं जब मैंने कोड नहीं लिखा था (या कोड जिसे मैंने बहुत समय पहले लिखा था)। मैं आगे बढ़ने से पहले परीक्षण कवरेज को भी सत्यापित कर सकता हूं, हमेशा पारित होने वाले यूनिट परीक्षणों पर भरोसा करने से बचने के लिए ... लेकिन यह उस क्षेत्र का परीक्षण नहीं करता जिस पर मैं काम कर रहा हूं।
क्या आप रिफैक्टरिंग के दौरान परीक्षण लिखते हैं?
मैं आमतौर पर नहीं है, लेकिन मैं निम्नलिखित परिस्थितियों में नए परीक्षण (सूची संपूर्ण नहीं) जोड़ सकते हैं:
यह भी रिफैक्टरिंग किया जा रहा है पर निर्भर करता है में छेद की खोज। फ़ंक्शन निकालने पर, मैं एक नया परीक्षण बना सकता हूं यदि इसे पहले से अलग तरीके से बुलाया जा सकता है।
पहली बात करते हुए कोड पर काम कर देखा code smells की एक सूची बनाए रखने के लिए है:
यहाँ कुछ सामान्य सलाह कर रहे हैं। यह कोड में जो देखा गया था उसे याद रखने के बोझ से किसी के दिमाग को मुक्त करने की अनुमति देता है। इसके अलावा,
सुनहरा नियम कभी भी रिफैक्टर नहीं होता है जब यूनिट परीक्षण पूरी तरह से पास नहीं होता है।
कोड स्थिर होने पर रिएक्टर, जो कुछ आप जानते हैं उसे जोड़ने से पहले भविष्य में रीफैक्टरिंग द्वारा प्रभावित किया जाएगा, से पहले अपने को एकीकृत करने से पहले।
यूनिट परीक्षणों की अनुपस्थिति में, आपको उस कोड का हिस्सा रखना होगा जिसे आप परीक्षण के तहत रिफैक्टर करना चाहते हैं। यदि इकाई परीक्षणों को फिर से निकालने के लिए बहुत कठिन होता है, क्योंकि आमतौर पर यह मामला होता है, तो आप प्रति Michael Feathers in Working Effectively with Legacy Code की अनुशंसा के अनुसार characterization tests बना सकते हैं। संक्षेप में वे अंत-टू-एंड परीक्षण होते हैं जो आपको कोड के वर्तमान व्यवहार को पिन करने की अनुमति देते हैं (जिसे हर समय पूरी तरह से काम नहीं माना जाता है)।
बच्चे के चरणों करने से डरो मत। एक ही समय में दो चीजें मत करो। अगर आप किसी चीज को रीफैक्टरिंग की आवश्यकता पर टिप्पणी करते हैं, तो इसे नोट करें, अभी इसे ठीक न करें, भले ही यह बहुत आसान लगे।
परीक्षण पास होने पर अक्सर जांचें। ताकि आप पहले किए गए कार्यों को खोए बिना खराब रिफैक्टरिंग वापस कर सकें।
मन रिफैक्टरिंग पर रखें अपने ग्राहक (इस पर चर्चा की जा सकती है) को जोड़ने के मूल्य नहीं है, लेकिन ग्राहक refactor करने के लिए आप भुगतान नहीं करता है। अंगूठे का एक नियम कोड बनाने या कोड में नई क्षमताओं को जोड़ने से पहले रिफैक्टर करना है।
प्रथम चरण: एक code smell.
दूसरा कदम की पहचान: वैकल्पिक कार्यान्वयन पर विचार करें और मैं मामले में क्या व्यापार नापसंद कर रहे हैं और जो स्वीकार करते हैं जिनमें से है "बेहतर है।"
तीसरा चरण: बेहतर समाधान लागू करें।
यह कोड अलग नहीं है या नहीं, कभी-कभी मैं कोड पर वापस जा सकता हूं, मैंने महीनों या साल पहले लिखा था और यह किसी और से कोड जैसा दिखता है। यदि मैं नई विधियां कर रहा हूं या कोड, आईएमओ के लिए पर्याप्त परीक्षण नहीं हैं तो मैं परीक्षण लिख सकता हूं।
जनरल दृष्टिकोण
मैं पक्षी देखने से सॉफ्टवेयर (घटक) में देखना द्वारा शुरू कर सकते हैं। निर्भरता विश्लेषण और ग्राफिंग उपकरण यहां बहुत मददगार हैं (बाद के अनुभाग देखें)। मैं पैकेज-स्तर या कक्षा-स्तर निर्भरताओं में एक सर्कल की तलाश करता हूं, और वैकल्पिक रूप से कई निर्भरताओं वाले वर्गों के लिए भी। ये रिफैक्टरिंग के लिए अच्छे उम्मीदवार हैं।
देखें http://stackoverflow.com/questions/20262/refactoring-for:
व्यापार
निर्भरता विश्लेषण उपकरणों के उपकरण -testability-ऑन-एक मौजूदा प्रणाली। Http://stackoverflow.com/questions/48817/where-to-find-resources-on-refactoring देखें। इनमें से कोई भी मदद नहीं की? http://stackoverflow.com/questions/tagged/refactoring –