क्या उच्च गुणवत्ता वाला सॉफ़्टवेयर इसके विकास की लागत के लायक है?

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

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

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

हम कीमत और गुणवत्ता के बीच चयन करने के लिए उपयोग किए जाते हैं।

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

सॉफ्टवेयर की गुणवत्ता बहुत अधिक है।

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

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

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

पहली नज़र में, उपयोगकर्ताओं के लिए आंतरिक गुणवत्ता कोई मायने नहीं रखती (लेकिन केवल पहली बार में)

यदि उपयोगकर्ता सॉफ़्टवेयर की आंतरिक गुणवत्ता का मूल्यांकन नहीं कर सकते हैं, तो क्या यह मानदंड महत्वपूर्ण है? आइए एक काल्पनिक स्थिति की कल्पना करें कि दो विकास टीमों ने स्वतंत्र रूप से एक-दूसरे को ट्रैक करने और उड़ान देरी की भविष्यवाणी करने के लिए एक आवेदन बनाने का फैसला किया। मैं एक टीम का प्रबंधन करता हूं, और रेबेका दूसरे का नेतृत्व करती है। अनुप्रयोगों के लिए बुनियादी कार्यों का सेट लगभग समान है, दोनों अनुप्रयोगों के लिए इंटरफ़ेस भी काफी सुविधाजनक और विचारशील निकला, अनुप्रयोगों में कोई महत्वपूर्ण बग नहीं हैं। एकमात्र अंतर यह है कि रेबेका से आवेदन का स्रोत कोड स्पष्ट रूप से संरचित और व्यवस्थित है, और मेरी टीम द्वारा बनाया गया कोड अस्पष्ट नामों के साथ कक्षाओं और विधियों का एक गन्दा सेट है और यह कोड कैसे जुड़ा हुआ है, इससे भी अधिक अस्पष्ट तर्क। एक और अंतर है: मैं $ 6 के लिए अपना आवेदन बेचता हूं, और रेबेका $ 10 के लिए लगभग एक ही आवेदन बेचता है।

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

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

उच्च आंतरिक गुणवत्ता वाले कार्यक्रमों का विस्तार करना आसान है

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

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

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

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

उपयोगकर्ता जल्द से जल्द नई सुविधाएँ प्राप्त करना चाहते हैं।

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

आंतरिक गुणवत्ता के प्रभाव का दृश्य

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

नीचे दिया गया ग्राफ़ योजनाबद्ध रूप से दिखाता है कि आप कार्यक्षमता के अनुपात और इसे विकसित करने में लगने वाले समय की कल्पना कैसे कर सकते हैं। आमतौर पर, एक वक्र कुछ इस तरह दिखता है:


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

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


हालांकि, एक चाल है। विकास के प्रारंभिक चरणों में, उच्च मानकों का पालन करने की तुलना में कोड की गुणवत्ता की अनदेखी करना अधिक प्रभावी है। लेकिन यह अवधि कब समाप्त होती है?

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

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

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

यहां तक ​​कि सर्वश्रेष्ठ टीमें कभी-कभी खराब कोड भी लिखती हैं

विकास प्रक्रिया में नए लोगों का मानना ​​है कि बुरा कोड बताता है कि टीम अच्छी तरह से काम नहीं कर रही है। लेकिन, जैसा कि अभ्यास से पता चलता है, यहां तक ​​कि सबसे अनुभवी टीम भी कभी-कभी गलतियां करती हैं और खराब कोड लिखती हैं।

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

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

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

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

DevOps अनुसंधान और मूल्यांकन (DORA)

लागत और गुणवत्ता के बीच व्यापार-बंद सॉफ्टवेयर विकास की दुनिया में एकमात्र ऐसा नहीं है जो पहली नज़र में सरल लगता है, लेकिन व्यवहार में सब कुछ कुछ अधिक जटिल हो जाता है। तेजी से विकास और रिलीज दरों, या धीमी दरों और कठोर परीक्षण - क्या चुनने के लिए सबसे अच्छा है की व्यापक चर्चा भी है। यह माना जाता है कि दूसरे दृष्टिकोण का उपयोग उत्पादन प्रणालियों की उच्च स्थिरता प्राप्त करने की अनुमति देता है। हालाँकि, DORA अध्ययन ने साबित कर दिया कि ऐसा नहीं है।

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

एक अच्छी वास्तुकला के साथ सिस्टम के लिए समर्थन सस्ता है

ऊपर हमने जो बात की, उसमें से सबसे महत्वपूर्ण बिंदु:

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

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

यह सही कारण है कि लेख के शीर्षक से प्रश्न का कोई मतलब नहीं है। वास्तुकला और अच्छे कोड पर अतिरिक्त संसाधनों को खर्च करना, आर्थिक दृष्टिकोण से, अंत में, अधिक लाभदायक है। , , , . , . ( ). , .

---

. :

, , . – . . , . .