Refactoring कीमत

विशेष रूप से: रीफैक्टरिंग एक युवा "बीमारी" है। व्यक्तिगत टिप्पणियों के अनुसार, 26 साल बाद कहीं जाने देना शुरू होता है। जैसा कि उस पुराने वाक्यांश में: "वह जो अपनी युवावस्था में क्रांतिकारी नहीं था - उसके पास दिल नहीं है, वह जो परिपक्वता में रूढ़िवादी नहीं है - उसका कोई मन नहीं है।" इसलिए, जब तक मैं अंत में जाने नहीं देता, तब तक मैं उपयोगकर्ता के मामलों और इसके साथ प्राप्त होने वाले संभावित लक्ष्यों का वर्णन करने का प्रयास करूंगा।

होनहार

मैंने 150+ फ़ाइलों के लिए पुल अनुरोध के अगले देखने के बाद लिखना शुरू किया, जहां नई कार्यक्षमता और मौजूदा एक के रीफैक्टरिंग में जमकर शामिल थे। रिफैक्टरिंग न केवल कॉस्मेटिक था, बल्कि तार्किक भी था, जिससे सबसे बड़ा दर्द होता था। उदाहरण के लिए, रूबी में, amount == 0 बदल दिया गया amount.zero? यह विचार किए बिना कि amount में nil के मामले के लिए amount ये निर्माण समतुल्य नहीं हैं। यह सब लगभग इस प्रकार समझाया गया था: "लेकिन कोड के अनुसार मानक ऐसा माना जाता है!" तार्किक प्रश्न के लिए "मानक और सामान्य रूप से कोड का पालन करने का उद्देश्य क्या है, एक डेवलपर के रूप में आपका लक्ष्य क्या है?" आदमी ने खुद को बंद कर लिया और थोड़ा दोषी दोहराया "लेकिन कोड मानक के अनुसार, आपको इस तरह लिखना होगा ..." और कपड़े की दुकान में एक गोरा की तरह दिखता था जो इच्छा के साथ सामना नहीं कर सकता था refactor सब कुछ खरीद लो।

परिभाषा

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

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

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

उत्पाद का मूल्य

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

प्रत्यक्ष उत्पाद मान

यहां सब कुछ सरल है। वे उत्पाद का उपयोग करते हैं, इसलिए प्रत्यक्ष मूल्य वे हैं जो उपयोगकर्ता स्पष्ट रूप से महसूस करता है / देखता है / महसूस करता है। अर्थात्:

1. सभी प्रकार की उत्पाद कार्यक्षमता;
2. प्रयोज्य (यूआई / यूएक्स, प्रदर्शन, गलती सहिष्णुता, आदि)।

दूसरा बिंदु कुछ चर्चा का कारण हो सकता है। आखिरकार, कई लोग मानते हैं कि यह मुख्य बात नहीं है। चूंकि यदि कार्यक्षमता अच्छी है, तो इससे कोई फर्क नहीं पड़ता कि यह किस में लिपटा है। Sane UI / UX के बिना कार्यक्षमता के अच्छे उदाहरण: Redmine और SAP । हालांकि, मैं कॉमरेड एलन कूपर और उनके "मरीजों के हाथों में मनोचिकित्सा अस्पताल" के अनुसार इस नज़र से असहमत हूं।

अप्रत्यक्ष उत्पाद मान

ये ऐसे मान हैं जो अपने आप में उपयोगकर्ता को प्रभावित नहीं करते हैं। लेकिन वे "गोली मार" या "जमा" कर सकते हैं और उत्पाद या इसकी कार्यक्षमता पर प्रभाव (बदलती गंभीरता का) हो सकते हैं।

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

डेवलपर मान

एक बहुत ही महत्वपूर्ण श्रेणी जो कई अनदेखी करती है, लेकिन जो हमेशा परिणाम को प्रभावित करती है।

1. मानक द्वारा कोड।
2. फेंग शुई पर संकेत।
3. अंतरात्मा के साथ अन्य लेनदेन। आखिरकार, कोड लिखा गया था, इसलिए दिन के लिए एक परिणाम है, और इसलिए लाभ है।
4. आंतरिक दुनिया के साथ कोड का अनुपालन।

लेकिन चलो ईमानदार हो। यह सब उत्पाद और अंतिम उपयोगकर्ता से जुड़े मूल्यों के बारे में नहीं है। यह मनोविज्ञान और व्यक्तिगत तिलचट्टे के बारे में है।

व्यापार के पक्ष से देखें

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

उदाहरण के लिए।

• OAuth स्क्रूइंग के साथ एक नई सुविधा ने पंजीकरण की संख्या में 10% की वृद्धि की और हमें + 1k $ मिला।
• हमने सिंगल-जिम्मेदारी पैटर्न के आधार पर बिलिंग मॉड्यूल को कई स्वतंत्र भागों में विभाजित किया है। ऐसा लगता है कि इसे बनाए रखना आसान हो गया, लेकिन इसे मापना संभव नहीं था।
• हम कोड मानक कोड मानक के अनुरूप लाए और ... कुछ भी नहीं मिला।

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

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

और क्या refactoring के बारे में?

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

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

सिस्टम प्रोग्रामिंग एक प्रक्रिया है जो एन्ट्रापी को कम करती है, और इसलिए इसमें मेटास्टेबिलिटी अंतर्निहित है। प्रोग्राम रखरखाव एक ऐसी प्रक्रिया है जो एन्ट्रापी को बढ़ाती है, और यहां तक ​​कि इसका सबसे कुशल रखरखाव सिस्टम को निराशाजनक रूप से अप्रचलन में गिरने से बचाता है।

इसलिए, यदि हम रीफैक्टरिंग को प्रोग्राम मेंटेनेंस प्रक्रिया का हिस्सा मानते हैं, तो कम रिफ्लेक्टर, जितनी देर तक कोड लेखन के बिना रहेगा।

रिफैक्टरिंग के क्या लक्ष्य हो सकते हैं?

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

एन्ट्रापी के लिए!

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

प्रलेखन के लिए!

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

गति के लिए!

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

सब कुछ इस श्रेणी में आता है: ऑपरेशन एल्गोरिदम में बदलाव के कारण एन + 1 के अहानिकर सुधार से लेकर गंभीर त्वरण तक। पूरी समस्या यह है कि बग की "समता" हमेशा गति से बैठती है। यहाँ एक मामला है: डेटाबेस में एक लेनदेन डेटा में धकेल दिया जाता है और उसी लेन-देन में साइडकीक में एक कार्य निर्धारित किया जाता है; रेडिस में साइडकीक की कतार और लेनदेन उस पर लागू नहीं होता है; जब कतार की गति बढ़ जाती है, तो डेटा को प्रतिबद्ध करने से पहले कार्य को कभी-कभी निष्पादित किया जाता है; आप परिणामों की कल्पना कर सकते हैं और डिबग प्रक्रिया खुद कर सकते हैं।

रिफैक्टरिंग के लिए!

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

मुझे आशा है कि आप समझेंगे कि आपको अपने बारे में नहीं, बल्कि इस बारे में सोचने की ज़रूरत है कि आप इसे किसके लिए करते हैं।

विनम्रता और स्वीकृति

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

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

थोड़ा स्पष्टीकरण।

1. बग को उत्पन्न करने के लिए कोड में किसी भी बदलाव के लिए एक गैर-शून्य मौका है। और चूंकि यह क्रिया अंतिम कार्यक्षमता से जुड़ी नहीं है, तो आप मूल मूल्यों को उत्पन्न किए बिना केवल कीड़े पैदा करते हैं। इसके बारे में पता होना अच्छा है और जब वे आपके पास प्रश्नों के साथ आते हैं तो hoses होने का नाटक नहीं करते हैं।
2. "एनाटेट पिछला" और इसके जैसे बहाने बहुत ही दयनीय हैं, क्योंकि एक ही गितुब / गीतालाब में ऐसी कोई विशेषता नहीं है। साथ ही, पिछले लेखक ने पुष्टि की कि सब कुछ उसके विन्यास में काम करता है, और वह आपके परिवर्तनों के लिए जिम्मेदारी नहीं उठाता है और जो हो रहा है उसकी तस्वीर का हिस्सा खो देता है। अधिक सटीक रूप से, आप इसे जिम्मेदारी के साथ उससे दूर ले जाते हैं।
3. उपयोगकर्ता वास्तव में रिफैक्टिंग के बारे में परवाह नहीं करता है, वह स्थिरता और कार्यक्षमता में रुचि रखता है, और रिफैक्टिंग उस बारे में नहीं है।

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

अंत

कड़ाई से न्याय न करें। यदि संभव हो, रचनात्मक रूप से आलोचना करें। और हमेशा अपने कार्यों के उद्देश्य के बारे में सोचें। आपका धन्यवाद