तकनीकी ऋण

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

इसके अलावा, किसी विशेष समाधान को चुनने में सबसे कठिन बात तत्काल पर्यवेक्षक के लिए अपनी पसंद का "संचार" है ताकि वह एक सूचित निर्णय ले सके। चूंकि अधिकांश प्रबंधकों के दृष्टिकोण से "वेटिंग" समाप्त होने के तुरंत बाद, वे कार्यान्वयन की समय सीमा सुनते हैं, "संचार" शुरू होने के लगभग 37 सेकंड बाद समाप्त होता है (आमतौर पर नेता को एक बहुत ही सरल प्रश्न का उत्तर खोजने में इतना समय लगता है,) एक शब्द में व्यक्त: "कब?")

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

क्लासिक अर्थों में क्लासिक ऋण

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

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

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

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

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

तकनीकी ऋण के स्रोत के रूप में गंदा कोड

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

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

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

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

निष्कर्ष

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

इसके अलावा, भले ही आपको सचेत रूप से या अनजाने में ऋण छेद में समझौता करना पड़े और अपने सिस्टम को डिजाइन करने का प्रयास करें ताकि अस्पष्ट निर्णयों का प्रभाव कम से कम हो और कार्यान्वयन कोड की गुणवत्ता उच्च स्तर पर हो।

-------------------------------------------

(*) वार्ड कनिंघम एक प्रसिद्ध व्यक्ति है जिसने कंप्यूटर समुदाय के विकास में एक अविश्वसनीय योगदान दिया है; वह "डैड" विकी है, और "पैटर्न" और "एक्सट्रीम प्रोग्रामिंग" के लेखकों में से एक है। पहले योगदान की जानकारी विकिपीडिया पर और दूसरी - लेख में “डिज़ाइन पैटर्न” पर मिल सकती है । सफलता की कहानी । "

(**) बेशक, हम केवल उन मामलों के बारे में बात कर रहे हैं जिनमें से प्रत्येक उपरोक्त समाधान अधिक इष्टतम लगता है, लेकिन अभी इसके आवेदन की लागत अनुचित रूप से बहुत अधिक है।

(***) बॉब मार्टिन सहित कुछ लेखक गंदे कोड को तकनीकी ऋण नहीं मानते हैं, लेकिन इस तरह के कोड से एक नई सुविधा को जोड़ने की लागत बढ़ जाती है, इसलिए मुझे ऐसा लगता है कि इसे तकनीकी ऋणों के प्रकारों में से एक माना जा सकता है।

(****) यहां हम पॉडकास्ट सॉफ्टवेयर इंजीनियरिंग रेडियो एपिसोड 167: द हिस्ट्री ऑफ यूनिटी और केंट बेक के साथ भविष्य के परीक्षण के बारे में बात कर रहे हैं, जिसमें केंट बेक ने इस पोषित विचार को व्यक्त किया था।