जब एक टीम का
तकनीकी ऋण धीरे-धीरे सभी बोधगम्य और अनिर्वचनीय सीमाओं से अधिक होने लगता है, तो टीम के पास इसे चुकाने के लिए कम से कम दो तरीके होते हैं: सिस्टम को फिर से भरना ताकि भविष्य में होने वाले परिवर्तनों की लागत इतनी अधिक न हो या सिस्टम के वर्तमान संस्करण को अकेला छोड़ दें और फिर से सब कुछ फिर से लिखें। पहले मामले में,
रिफैक्टिंग सिंड्रोम का सामना करना आसान
है , जब परिवर्तन भविष्य के परिवर्तनों की लागत को कम करने की गणना के साथ नहीं किए जाते हैं, लेकिन केवल परिवर्तनों के लिए किए जाते हैं। दूसरे मामले में, "दूसरी प्रणाली का प्रभाव" तब उत्पन्न हो सकता है जब सिस्टम के कार्यों को किसी के द्वारा विकसित और सुधार की आवश्यकता नहीं होती है, और "सब कुछ फिर से लिखना नहीं है" का विचार पहली और एकमात्र आज्ञा है जो किसी अजनबी के सामने आते ही दिमाग में आती है कोड।
और यद्यपि शास्त्रीय अर्थ में "दूसरी प्रणाली का प्रभाव" किसी और के कोड के पैथोलॉजिकल डिसऑर्डर और इसकी निरंतर पुनर्लेखन से थोड़ा अलग है, इन दोनों मामलों में कुछ समान है, इसलिए यह इन दोनों लक्षणों पर एक साथ विचार करने के लिए समझ में आता है।
दूसरी प्रणाली का क्लासिक प्रभाव
यदि आप पक्षों को करीब से देखते हैं, तो आप ... बच्चों की परवरिश करते समय दूसरी प्रणाली के प्रभाव की एक अद्भुत अभिव्यक्ति देख सकते हैं। दादा-दादी अक्सर अपने पोते-पोतियों की शिक्षा से उसी तरह संबंध नहीं रखते हैं, जिस तरह से वे अपने बच्चों की शिक्षा के लिए करते थे। और माता-पिता स्वयं बहुत बार अपनी समस्याओं को ठीक करने की कोशिश करते हैं, अपने बच्चों में प्यार पैदा करते हैं जो उनके लिए दिलचस्प है, यह सुनिश्चित करने की कोशिश करते हैं कि बच्चे अपने लक्ष्य को प्राप्त करें।
चूंकि कई डेवलपर्स और आर्किटेक्ट भी अपनी आत्मा को सॉफ्टवेयर सिस्टम बनाने में लगाते हैं, इसलिए यह बिल्कुल आश्चर्यजनक नहीं है कि जब वे अपने दिमाग की उपज का एक नया संस्करण शुरू करते हैं, तो वे सभी गलतियों और कमियों को ठीक करने की कोशिश करते हैं, और सही सिस्टम बनाने की कोशिश करते हैं। इसके अलावा, पहली प्रणाली की सफलता से प्रेरित (विफलता के मामले में, सब कुछ सरल है, यह सिर्फ सिस्टम के दूसरे संस्करण तक नहीं पहुंचता है), डेवलपर्स यह सोचना शुरू करते हैं कि उनके पास मौजूदा निजी ज्ञान के आधार पर सामान्य निष्कर्ष निकालने के लिए इस विषय क्षेत्र में पर्याप्त ज्ञान और अनुभव है। यह अक्सर समाधान के समयपूर्व सामान्यीकरण की ओर जाता है, जिसे अक्सर समय से पहले अनुकूलन (*) से कम बुराई नहीं माना जाता है।
दूसरी प्रणाली बनाने में एक और समस्या मूल्यों का गलत पुनर्मूल्यांकन है, जब सिस्टम के अप्रचलित कार्य परिपूर्ण होते हैं, और मौलिक रूप से नए दृष्टिकोण और समाधान विकसित नहीं होते हैं। इससे उन कार्यों का एक अद्भुत कार्यान्वयन होता है जिनकी किसी को ज़रूरत नहीं है, जो विशुद्ध रूप से सौंदर्य की दृष्टि से उपयोगी हो सकता है, लेकिन सिस्टम की सफलता के लिए शायद ही उपयोगी हो।
इन सभी समस्याओं का वर्णन फ्रेडरिक ब्रूक्स ने अपने "पौराणिक मानव-माह" में किया था, जहां, इस समस्या का वर्णन करने के अलावा, इसके समाधान के लिए सिफारिशें दी गई हैं। और हालांकि वह एंडी हंट और डेव थॉमस की दूसरी अद्भुत किताब "प्रैग्मैटिक प्रोग्रामर" से बहुत पहले ही बाहर आ गई थी, ब्रूक्स वही सलाह देती है जो लगातार व्यावहारिकता की किताब में सुनाई देती है: कोई चरमपंथ, और अधिक व्यावहारिकता और आत्म-अनुशासन।
सिंड्रोम "लेकिन सब कुछ फिर से लिखना नहीं है"
सहमत हूं कि आप और मैं जानते हैं कि पिछली प्रणाली का विकास, जो पड़ोसी टीम ने किया था, विफल रही। अब, अगर मैं इसके विकास का नेतृत्व करूंगा (मैं आवश्यक विकल्प पर जोर देने के लिए इसका आर्किटेक्ट / लीड / डेवलपर बनूंगा), मैं सब कुछ अलग तरीके से करूंगा, और हम निश्चित रूप से छह महीने की समय सीमा को नहीं तोड़ेंगे, और इसमें 4 गुना कम ग्लिच होंगे।
हालांकि, समस्या यह है कि ज्यादातर लोग दूसरे लोगों की असफलताओं पर थोड़े-थोड़े अहंकार के साथ देखते हैं, यह मानते हुए कि वे बेहतर करेंगे। 87.5 प्रतिशत प्रोग्रामर मानते हैं कि उन्होंने यह काम बेहतर तरीके से किया होगा, और उनमें से केवल 2.5 प्रतिशत (**) ने वास्तविकता में इसे बेहतर किया होगा। बाकी लोगों ने इसे "अपने तरीके से" किया होगा, हालांकि समय, गुणवत्ता और कार्यक्षमता के मामले में समान सफलता के साथ।
प्रोग्रामर के अलावा, प्रबंधक और ग्राहक भी ऐसे कचरे से पीड़ित होते हैं। जब आप सिस्टम को फिर से लिखने के लिए "पेशकश" किए गए थे, तो आप कितनी बार ऐसी स्थिति में आए हैं, क्योंकि कोई भी वर्तमान संस्करण को नहीं समझता है? इसके अलावा, यह उसी प्रणाली के कोड से स्वतंत्र रूप से आवश्यकताओं को मछली देने का प्रस्ताव था, जिसके साथ भारतीयों का एक झुंड चला। तो यह समझने के लिए कि किस तरह की बकवास चल रही है, पहले से ही बहुत मुश्किल है, और इसका परिणाम क्या होना चाहिए, दस साल के बच्चे के सापेक्षता के सिद्धांत के रूप में स्पष्ट है।
नतीजतन, नई प्रणाली की गुणवत्ता पूरे विकास श्रृंखला में सबसे कमजोर लिंक द्वारा निर्धारित की जाती है, और आवश्यकताओं के अभाव में, यह अब अधिक नहीं हो सकती है। इसलिए उन्हें समान अंडे मिलते हैं, लेकिन एक साइड व्यू, हालांकि कुछ समय के लिए नई प्रणाली अधिक "विस्तार योग्य" हो जाती है, क्योंकि यह अभी भी सेनानियों की उस जोड़ी के लिए समझ में आता है, जिन्होंने इसे नए सिस्टम में स्थानांतरित करने की प्रक्रिया में मौजूदा तर्क को अघोषित कर दिया।
यदि दूसरी प्रणाली के सिंड्रोम को दूर किया जा सकता है, यदि वांछित है, या कम से कम नैदानिक मामलों के जोखिम को काफी कम कर देता है, तो पुनर्लेखन की समस्या का सामना करना अधिक कठिन है। यदि पुनर्लेखन के लिए पेंसिल प्रोग्रामर या वास्तुकार की आत्मा में छिपी हुई है, तो आपको एक समान तरीके से निपटने की आवश्यकता है। वास्तव में, ऐसे मामले होते हैं जब यह आसान नहीं होता है, लेकिन पुलों को जलाना और सभी को फिर से शुरू करना आवश्यक है, लेकिन ज्यादातर मामलों में, इस तरह के प्रयासों को एक ही व्यावहारिकता और सावधानी के साथ इलाज किया जाना चाहिए।
यदि यह प्रबंधक या यहां तक कि ग्राहक की आवश्यकता है, तो इस मामले में, सबसे अधिक संभावना है कि बस कोई विकल्प नहीं होगा: आपको इसे फिर से लिखना होगा; यह सिर्फ साबुन के लिए एक अव्यवस्था का आदान-प्रदान नहीं करने और पिछली प्रणाली की मुख्य गलतियों को यथासंभव ध्यान में रखने की कोशिश करने के लायक है।
--------------------------------------
(*) एक तरह से, समय से पहले सामान्यीकरण को वास्तु समाधानों का समय से पहले अनुकूलन माना जा सकता है। एकमात्र अंतर यह है कि जब यह समय से पहले अनुकूलन की बात आती है, तो यह अनावश्यक रूप से अनुप्रयोग प्रदर्शन में सुधार के उद्देश्य से श्रम संसाधनों की अनावश्यक बर्बादी को संदर्भित करता है। और जब यह समय से पहले सामान्यीकरण की बात आती है, तो यह समय और प्रयास की समान बर्बादी की चिंता करता है, लेकिन समाधान का एक अनावश्यक सामान्यीकरण।
(**) यह वैज्ञानिक रूप से सिद्ध है कि 78.5% आँकड़े छत से लिए गए हैं :)