- तकनीकी कर्ज की अवधारणा
- जब अधिक समय लेने वाले बेहतर approach को अपनाने के बजाय आसान लेकिन सीमित solution चुना जाता है, तो भविष्य में दोबारा काम करने की जो अप्रत्यक्ष लागत बनती है
- सबसे प्रभावी solution के बजाय सबसे तेज solution चुनने से उत्पन्न अतिरिक्त काम की लागत
- सॉफ्टवेयर इंजीनियर Martin Fowler द्वारा वर्गीकृत तकनीकी कर्ज के प्रकार
- विवेकपूर्ण और जानबूझकर लिया गया तकनीकी कर्ज (Prudent & Deliberate)
- टीम को पता होता है कि वह कर्ज ले रही है, लेकिन वह इस बात पर विचार करती है कि ‘तेज़ रिलीज़ का लाभ कर्ज चुकाने की लागत से बड़ा है या नहीं’
- अविवेकपूर्ण लेकिन जानबूझकर लिया गया तकनीकी कर्ज (Reckless & Deliberate)
- अच्छी design practices का ज्ञान होने और उन्हें लागू कर सकने के बावजूद, साफ-सुथरा code लिखने का समय न होने के कारण ‘तेज़ और गंदे तरीके’ से आगे बढ़ने का परिणाम
- विवेकपूर्ण लेकिन अनजाने में लिया गया तकनीकी कर्ज (Prudent & Inadvertent)
- अच्छा software बनाया गया, code भी साफ था, लेकिन समय बीतने के बाद ही यह समझ आया कि ‘design कैसी होनी चाहिए थी’
- अविवेकपूर्ण और अनजाने में लिया गया तकनीकी कर्ज (Reckless & Inadvertent)
- जानकारी की कमी के कारण उत्पन्न परिणाम
- तकनीकी कर्ज को हल करने के तरीके
- तकनीकी कर्ज की सूची का प्रबंधन
- project retrospective के ज़रिए तकनीकी कर्ज को सूचीबद्ध कर साझा करें
- जब भी तकनीकी कर्ज बने, उसे हल करने के लिए आवश्यक काम को अनुमानित effort और timeline के साथ दर्ज करें
- टीम में यह चर्चा करें कि तकनीकी कर्ज को हल करना है या नहीं, कब करना है, और उसका समाधान कैसे बनाना है
- अच्छे तकनीकी कर्ज और बुरे तकनीकी कर्ज में अंतर करना
- इस तरह तकनीकी कर्ज को अलग-अलग करने से सबसे बड़ी समस्याओं की priority तय करने में मदद मिलती है
- refactoring
- काम करते हुए ज़रूरी हिस्सों को व्यवस्थित करें और थोड़ा-थोड़ा refactor करें
- बड़े पैमाने पर refactoring करते समय टीम के साथ स्थिति साझा करें और तकनीकी कर्ज के जोखिम व लागत की जानकारी दें
- test code लिखना
- code जितना जटिल होगा और refactoring जितनी बड़ी होगी, bug के बिना code को एक बार में बदलना उतना कठिन होगा
- side effects से बचने के लिए test code लिखें
- गुणवत्ता मानक तय करना और उनका पालन करना
- गुणवत्ता मानक तय करके coders को ढीला-ढाला code deploy करने से रोका जा सकता है
- अचानक नियम या schedule न बदलें
- डेवलपर्स से जुड़े नियम लगातार बदलने या deadline बदलने पर तकनीकी कर्ज से बचना मुश्किल हो जाता है
- यथार्थवादी schedule, methodology और workload देकर तकनीकी कर्ज को प्रबंधित करने में मदद करें
- क्या तकनीकी कर्ज हमेशा बुरा ही होता है?
- Chris Riccomini और Dmitriy Ryaboy की पुस्तक 『ज़रूर पढ़ें! डेवलपर ऑनबोर्डिंग गाइड: sustainable software और smooth collaboration culture को समझते हुए एक professional developer का निर्माण』 में कहा गया है, “अगर यह ऐसा प्रशिक्षित कर्ज है जिसे टीम बाद में भी हल कर सके, तो इसे ‘अच्छा कर्ज’ कहा जा सकता है”
- But तकनीकी कर्ज business पर नकारात्मक प्रभाव डाल सकता है, इसलिए इसे हल करना चाहिए
- यह bug के रूप में सामने आकर user experience को खराब कर सकता है
- तकनीकी कर्ज बढ़ने पर डेवलपर्स के लिए मौजूदा codebase के भीतर काम करना और कठिन हो जाता है
- नई features बनाना और मौजूदा features में बदलाव करना समय को बाँट देता है, जिससे software development lifecycle धीमा हो जाता है और market release का समय टल जाता है
अभी कोई टिप्पणी नहीं है.