क्या आपने कभी एक सॉफ्टवेयर डेवलपमेंट टीम के बारे में सुना है जिसे तकनीकी ऋण का सामना नहीं करना पड़ेगा?

मुझे न तो। इसके अलावा:

इंजीनियर्स अपने समय का लगभग एक तिहाई तकनीकी ऋण पर खर्च करते हैं, जो टीमों के मनोबल को कम करता है और कंपनियों की लागत लगभग 85 बिलियन डॉलर सालाना है।

अध्ययन धारी

जरा इसके बारे में सोचो। यह 85 बिलियन डॉलर है।

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

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

लेकिन क्या ऐसा होना चाहिए? क्या सॉफ्टवेयर विकास के कोई मौलिक कानून हैं जो इसके लिए जिम्मेदार हैं? और, यदि हां, तो क्या हम इन कानूनों का इस्तेमाल अपने फायदे के लिए कर सकते हैं? तकनीकी ऋण आम है, लेकिन यह तकनीकी दिवालियापन नहीं होना चाहिए।

आइए हम कुछ युक्तियों के लिए विज्ञान के विभिन्न क्षेत्रों की ओर रुख करें, क्योंकि उष्मागतिकी के नियम हमें यह समझने के लिए महत्वपूर्ण विचार दे सकते हैं कि तकनीकी ऋण अपरिहार्य क्यों है।

मैक्रोट्रेंड्स तकनीकी ऋण को अपरिहार्य बनाता है

ऊष्मप्रवैगिकी का पहला नियम

ऊर्जा के संरक्षण के नियम के रूप में भी जाना जाता है; का दावा:

बंद प्रणाली की कुल ऊर्जा स्थिर रहती है; वे कहते हैं कि यह समय के साथ बना रहता है।

दूसरे शब्दों में, ऊर्जा को बनाया या नष्ट नहीं किया जा सकता है, हालाँकि, यह एक रूप से दूसरे में स्थानांतरित हो सकती है।

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

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

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

लेकिन एक पल रुकिए। यह तकनीकी ऋण में वृद्धि का कारण क्यों बनता है?

उष्मागतिकी का दूसरा नियम

बंद प्रणाली में अव्यवस्था कम नहीं हो सकती; यह केवल अपरिवर्तित या बढ़ सकता है।

वास्तव में, बंद सिस्टम प्राकृतिक तरीके से अधिक से अधिक विकार की स्थिति में जाते हैं। इस "गड़बड़" - जिसे हमने "ऊर्जा" या "अराजकता" से ऊपर कहा है - एंट्रॉपी कहा जाता है। इवर जैकबसन और उनके सहयोगियों ने कोडबसेस में एन्ट्रापी की घटना की जांच की और सॉफ्टवेयर एंट्रॉपी शब्द की शुरुआत की। जैसे-जैसे आप कोड आधार में परिवर्तन करते हैं, इसकी एन्ट्रापी बढ़ती जाती है। यह व्यापक अराजकता तकनीकी ऋण का कारण है।

हमारी तेजी से बढ़ती सॉफ्टवेयर कंपनी, जिसके ग्राहक आधार का विस्तार जारी है और बाजार बढ़ रहा है। उनकी बढ़ती विकास टीम में विकास के साथ तालमेल रखने के लिए दिन-रात सुविधाएँ होती हैं। यदि आप कुछ नहीं करते हैं, तो कोड आधार केवल अधिक भ्रमित हो जाएगा। दबाव बढ़ रहा है।

मैं तकनीकी ऋण को कोडबेस में एन्ट्रापी के रूप में देखता हूं। मुझे नहीं लगता कि वह कभी गायब हो जाएगा, उसके साथ लड़ाई निरंतर होगी।

रॉन प्रैगाइड्स , कार्टा में इंजीनियरिंग के उपाध्यक्ष

प्रत्येक स्प्रिंट की योजना बनाते समय, हमारी कंपनी एक विकल्प का सामना करती है: क्या कुछ है जो आपको बढ़ती जटिलता पर अंकुश लगाने की आवश्यकता है या यह नई सुविधाओं को विकसित करने और वितरित करने के लिए समय के लायक है?

ऊष्मप्रवैगिकी का तीसरा और अंतिम कानून स्पष्ट करता है कि यह दुविधा चीजों की वास्तविक स्थिति के साथ निकटता से क्यों नहीं होती है।

थर्मोडायनामिक्स का तीसरा नियम

जब तापमान पूर्ण शून्य होता है, तो सिस्टम की एन्ट्रॉपी निरंतर मूल्य तक पहुँच जाती है।

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

तो हम सॉफ्टवेयर एन्ट्रापी को नियंत्रित करने के लिए क्या कर सकते हैं?

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

हालांकि, कोड को हमेशा के लिए जमे हुए रखना असंभव है - हमें नई सुविधाओं की आवश्यकता है। तो हमारे लिए एकमात्र विकल्प रिफ्लेक्टर है।

कोड रीफैक्टरिंग प्रक्रिया सॉफ्टवेयर एंट्रॉपी को चरणबद्ध करने में मदद कर सकती है।
विकिपीडिया

इस के साथ मदद करने के लिए VSCode के लिए एक मुफ्त एक्सटेंशन । चीजों को हाथ से निकलने से पहले अभी शुरू करें!

सॉफ्टवेयर एन्ट्रापी को कम करना आसान नहीं है

अभी तक तो अच्छा है। वास्तव में, यह सब स्पष्ट के एक बयान की तरह दिखता है; जिस किसी ने भी सॉफ्टवेयर विकास के बारे में कुछ भी सुना है, वह कम से कम सहज ज्ञान युक्त है।

क्यों तकनीकी ऋण अभी भी हमें आश्चर्यचकित कर रहा है?

ऐसा इसलिए है क्योंकि भले ही हमें भ्रम को कम करने के लिए रिफ्लेक्टर कोड की आवश्यकता के बारे में पता है, फिर भी अन्य बलों के असंख्य हैं जो हमारे ऊपर हावी हैं जो हमें समय और संसाधनों को सही ढंग से और अक्सर पर्याप्त करने के लिए आवश्यक संसाधनों को आवंटित करने से रोकते हैं। इसका मतलब यह है कि हमारे और अन्य सभी कोडबेस में, सॉफ़्टवेयर का एन्ट्रापी लगातार बढ़ रहा है।

हम सभी मूर के नियम को जानते हैं, लेकिन बिल गेट्स के वर्थ के नियम के बारे में सोचें:

सॉफ्टवेयर की गति हर डेढ़ साल में आधी घट जाती है।
बिल गेट्स

मुझे विश्वास है कि इस पैटर्न के पीछे हमारे कोडबेस की बढ़ती एन्ट्रोपी मुख्य प्रेरक शक्ति है।

सॉफ्टवेयर एन्ट्रापी की वृद्धि दर सीधे तौर पर प्रौद्योगिकी, सॉफ्टवेयर बाजार, सॉफ्टवेयर कंपनियों और कोड राइटिंग साक्षरता जैसे कारकों की वृद्धि दर से संबंधित है - और उनमें से प्रत्येक तेजी से बढ़ता है।

स्रोत: द इमर्जिंग फ्यूचर

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

तकनीकी ऋण से लड़ने वाले डेवलपर्स की एक टीम का वास्तविक फुटेज

अगले लेख में, हम उन माइक्रोट्रेंड्स पर विचार करेंगे जो लगातार हमें तकनीकी दिवालियापन की ओर धकेलते हैं, साथ ही कितनी तेजी से बढ़ती सॉफ्टवेयर कंपनियां उनसे लड़ सकती हैं। हमारे साथ रहो!