रिफैक्टिंग सिंड्रोम

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


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

यह सब अभी तक एक और रूपक की ओर जाता है, जो पुराने कोड को फिर से लिखने के लिए एक समान घातक इच्छा का वर्णन करता है - रिफैक्टिंग सिंड्रोम के लिए।

लक्षण 1. दूसरे का कोड - जी # $ लेकिन

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

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

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

लक्षण 2. परिपूर्ण कोड के लिए प्रयास

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

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

लक्षण 3. "मैं लड़ता हूँ क्योंकि मैं लड़ता हूँ"

समय के साथ, अपने स्वयं के नए पेशेवर अनुभव की ऊंचाई से, उपयोगकर्ता की आवश्यकताओं की स्पष्ट समझ और अपने स्वयं के सिस्टम की समझ के लिए धन्यवाद, यहां तक ​​कि उनका अपना कोड भयानक लगने लगता है। कितनी बार आपने खुद को यह सोचते हुए पकड़ा है: "अरे, यह बकवास किसने लिखी?" और फिर आपको यह जानकर आश्चर्य हुआ कि यह कोई आप ही हैं।

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

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

लक्षण 4 ... 1001

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

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

-

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