कठिनाई मूल्य

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

हाल ही में मैंने यममेर के क्रिस गेल का एक लेख पढ़ा, जो "जटिलता लागत" की अवधारणा का परिचय देता है, जो मेरे लिए बहुत करीब और स्पष्ट है। जटिलता की कीमत तकनीकी प्रणालियों के रूप में जटिल प्रणालियों के विकास के बिल्कुल समान पहलू का वर्णन करती है, केवल परिचय, मेरे दृष्टिकोण से, अधिक स्पष्टता।

यह विचार अत्यंत सरल है - यह परियोजना जितनी जटिल है, उतना ही अधिक प्रयास इसे समर्थन करने पर खर्च किया जाता है, इसे बदलना उतना ही महंगा है। यद्यपि हम "शुद्धता" को उसके शुद्ध रूप में नहीं माप सकते, लेकिन सभी इंजीनियर इस कथन को सही मानते हैं।

क्रिस अपने लेख में लिखते हैं कि एक नई कार्यक्षमता बनाने में लगने वाला समय इस कार्यक्षमता की लागत का सबसे छोटा हिस्सा है। वह एक उदाहरण देता है कि कैसे उसने 1 घंटे में यमर के लिए कुछ किया, और अगले 5 वर्षों में 40 घंटे बिताए और अन्य इंजीनियरों को बताया कि यह क्या है और यह कैसे काम करता है। और इसका मतलब है कि कुल मिलाकर इन वार्तालापों में कम से कम 80 घंटे लगे, क्योंकि एक अन्य इंजीनियर भी इस पर अपना समय बिता रहा था।

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

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

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

कई बार मुझे परियोजनाओं को एक और "तेज" संदेश कतार से शुरू करने से बचाना पड़ा, जब प्रति दिन संदेशों की संख्या कई हजार से अधिक नहीं थी, और सब कुछ डेटाबेस पर पूरी तरह से बदल गया, जो पहले से ही परियोजना में उपयोग किया गया था।

कई परियोजनाओं में हमने परामर्श किया, और जो एक संबंधपरक डीबीएमएस का उपयोग करते थे, हमने मोंगोबीडी से छुटकारा पाया, उनके समर्थन को बहुत सरल किया।

जब प्रबंधक पूछता है: "ऐसा करने में कितना समय लगता है?", तो किसी को तुरंत सोचना चाहिए कि यह प्रश्न व्यावहारिक रूप से निरर्थक है, क्योंकि नई कार्यक्षमता बनाने के लिए समर्थन और परिशोधन का समय समय से कई गुना अधिक है।

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

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