बड़ी परियोजनाओं में रिफैक्टिंग का अभ्यास

कुछ समय पहले, मैं एक गेम देव में आ गया, जहाँ मैं दर्जनों प्रोग्रामर द्वारा लिखी गई कोड की 2 मिलियन लाइनों की परियोजनाओं में भाग गया। कोड आधार के इस पैमाने पर, पहले से अज्ञात प्रकृति की समस्याएं उत्पन्न होती हैं। मैं अब आपको उनमें से एक के बारे में बताना चाहता हूं।

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

अभ्यास से उदाहरण, मेरे और मेरे सहयोगियों दोनों:

• Hibernate पर शुद्ध JDBC से सभी डेटाबेस काम करते हैं।
• किसी दूरस्थ प्रक्रिया कॉल (RPC) को संदेश भेजने और प्राप्त करने से सेवा की वास्तुकला को फिर से बनाएँ।
• रनटाइम ऑब्जेक्ट्स में XML फ़ाइलों के अनुवाद के लिए सबसिस्टम को पूरी तरह से फिर से लिखें।

क्या करें? समस्या का सामना करने के लिए कौन सा पक्ष? नीचे उन युक्तियों और प्रथाओं का एक सेट है जो हमें इस समस्या से निपटने में मदद करते हैं। पहले, अधिक सामान्य शब्द और फिर विशिष्ट तकनीक। सामान्य तौर पर, कुछ भी अलौकिक नहीं है, लेकिन यह किसी की मदद कर सकता है।

रिफैक्टरिंग की तैयारी

• यदि संभव हो तो भागों में रिफैक्टरिंग को तोड़ें। हो सके तो कोई बात नहीं। असफल होने पर क्या करना है, इसके बारे में अन्य सभी टिप्स।
• उस अवधि को चुनने का प्रयास करें जब उपतंत्र में नई सुविधाओं को जोड़ने की गतिविधि न्यूनतम होगी। उदाहरण के लिए, बैकएंड को फिर से करना सुविधाजनक है, जबकि टीम के सभी प्रयास फ्रंट एंड पर केंद्रित हैं।
• कोड को अच्छी तरह से पढ़ें, इसकी आवश्यकता क्यों है। सबसिस्टम की नींव क्या वास्तुकला है, मानक दृष्टिकोण क्या हैं जो वहां उपयोग किए गए थे। स्पष्ट रूप से अपने लिए परिभाषित करें कि नई अवधारणा क्या है और आप वास्तव में क्या बदलना चाहते हैं। एक औसत दर्जे का अंतिम लक्ष्य होना चाहिए।
• कोड के क्षेत्र को परिभाषित करें जो कि रिफैक्टिंग कैप्चर करेगा। यदि संभव हो, तो इसे अलग मॉड्यूल में / अलग निर्देशिका में अलग करें। यह भविष्य में बहुत उपयोगी होगा।
• परीक्षण के बिना Refactoring बहुत खतरनाक है। आपके पास परीक्षण होना चाहिए। मैं नहीं जानता कि उनके बिना कैसे रहना है।
• कवरेज की गणना के साथ परीक्षण चलाएं, इससे विचार के लिए बहुत सारी जानकारी मिल जाएगी।
• टूटे हुए परीक्षणों की मरम्मत करें जो वांछित सबसिस्टम से संबंधित हैं।
• तरीकों के बारे में कवरेज की जानकारी का विश्लेषण करके, आप अप्रयुक्त कोड को ढूंढ और निकाल सकते हैं। अजीब तरह से पर्याप्त है, यह अक्सर 10-15% तक होता है। अधिक कोड आप निकाल सकते हैं, कम रिफ्लेक्टर। लाभ!
• कवरेज द्वारा, यह निर्धारित करें कि कोड के कौन से भाग कवर नहीं किए गए हैं। हमें लापता परीक्षणों को जोड़ने की आवश्यकता है। यदि यूनिट परीक्षण लंबे और थकाऊ हैं, तो कम से कम उच्च-स्तरीय स्मैक परीक्षण लिखें।
• सार्थक कोड के 80-90% तक कवरेज लाने की कोशिश करें। सब कुछ कवर करने की कोशिश मत करो। थोड़े से लाभ के साथ बहुत समय मार डालो। कम से कम मुख्य निष्पादन पथ को कवर करें।

रिफैक्टरिंग

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

अतिरिक्त टिप्स

• रिफैक्टरिंग के साथ समानांतर में बनाई गई सभी नई सुविधाओं को 100% परीक्षणों द्वारा कवर किया जाना चाहिए। यह आवश्यक है ताकि नए कार्यान्वयन पर स्विच करते समय, परीक्षण गिरें और संकेत करें कि नए कार्यान्वयन में पुराने से पर्याप्त कोड नहीं है।
• कोई बग फिक्स सिद्धांत के अनुसार किया जाना चाहिए - पहले हम एक परीक्षण लिखते हैं जो समस्या और दुर्घटना को पुन: उत्पन्न करेगा, फिर इसे सुधारें। कारण वही हैं।
• यदि आप सिस्टम का ला टीमिटी का उपयोग करते हैं, तो रिफैक्टरिंग के समय के लिए एक अलग निर्माण करें, जहां नए सबसिस्टम पर सभी परीक्षणों का पीछा किया जाएगा। स्वचालित निर्माण आपके नए, अभी तक उपयोग नहीं किए गए कोड "आधिकारिक" बनाता है। सभी समान नीतियां और नियम उस पर लागू होने लगते हैं जो बाकी सब चीजों की तरह हैं।
• अक्सर ऐसा होता है कि आप यह नहीं जानते हैं कि क्या आपने नए आर्किटेक्चर के लिए पुराने कोड में सब कुछ तय कर दिया है। उदाहरण के लिए, आपको पता नहीं है कि आपका कोड Hibernate के बजाय कहीं प्रत्यक्ष JDBC कनेक्शन का उपयोग कर रहा है या नहीं। या अचानक एक मैसेज कहीं फिसल गया, RPC कॉल नहीं। ऐसे स्थानों को खोजने के लिए, आपको पुरानी पद्धति को निष्क्रिय बनाने के लिए एक तरीका आना चाहिए। यानी इसे परीक्षणों में तोड़ो। उदाहरण के लिए, संदेश वितरण प्रणाली को तोड़ने या सिस्टम में टूटी हुई JDBC ड्राइवर को खिसकाने के लिए। अभ्यास से पता चलता है कि इस तरह से कम से कम 5 टुकड़े भूल गए और सही नहीं किए गए स्थान आमतौर पर पाए जाते हैं।
• अन्य प्रोग्रामर्स से बात करें, उन्हें अपनी प्रगति के बारे में सूचित रखें। यदि वे जानते हैं कि आपके पास एक सप्ताह बचा है, तो वे कभी-कभी अपने कार्यों को स्थानांतरित कर सकते हैं जब तक कि आपके उपतंत्र के नए संस्करण को जारी नहीं किया जाता है। परिवर्तनों को मर्ज करने की कोई आवश्यकता नहीं होगी।

अनुभव बताता है कि यहां तक ​​कि डरावने और बड़े उपप्रणाली अपेक्षाकृत कम रक्त के साथ फिर से बनाए जा सकते हैं। आपके मुख्य सहायक परीक्षण और व्यवस्थित हैं।