व्यवसाय को अच्छे कोड की आवश्यकता क्यों है?

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

मैं आपको बताना चाहता हूं कि कोड की गुणवत्ता के बारे में परवाह करने के बजाय "विशेषताओं पर जोर" क्या हो सकता है, और न केवल प्रोग्रामर को अच्छे कोड की आवश्यकता क्यों है।

समर्थन

मुख्य थीसिस, जिसके बिना वर्तमान लेख, सिद्धांत रूप में, निरर्थक होगा:

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

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

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



क्षैतिज अक्ष परियोजना जीवनकाल है, ऊर्ध्वाधर अक्ष समग्र कार्यक्षमता है।

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

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

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

कोड एक उपकरण नहीं है, कोड एक अंतिम उत्पाद है

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

"प्रदर्शन पर ध्यान केंद्रित" के बारे में

जिस लेख में मैंने संदर्भित किया था, उसमें निम्नलिखित विचार व्यक्त किया गया था: आपको परियोजना की तत्परता के स्तर पर ग्राहक / परियोजना प्रबंधक के साथ संवाद करने की आवश्यकता है, और निम्नलिखित उदाहरण इसके विपरीत था:

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

तो यहाँ है। एक अंतर है जिसके कारण इसे केवल सॉफ्टवेयर उत्पाद के समर्थन से स्थिति पर प्रोजेक्ट नहीं किया जा सकता है - फ़ोटोशॉप में ये सभी परतें और ब्रश काम के परिणाम (चित्र) के ठीक बाद किसी के लिए बेकार हो जाते हैं, और परिणाम प्राप्त करने के लिए बस एक उपकरण है , अंतिम उत्पाद नहीं।

इस प्रकार, जब अंतिम चित्रों के लिए आवश्यकताओं को आकर्षित किया जाता है, तो ग्राहक इस बारे में चिंता नहीं कर सकता है कि प्रक्रिया में क्या उपयोग किया जाएगा। सॉफ्टवेयर के मामले में, यदि ग्राहक (व्यवसाय) आवेदन से केवल कार्यक्षमता की मांग करेगा, तो वह ठीक-ठीक वही पाने का जोखिम उठाएगा जो वह चाहता था - नई कार्यक्षमता, लेकिन कोई सवाल नहीं था कि इसे बनाए रखने और विकसित करने की आवश्यकता होगी।

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

कोड - प्रोग्रामर का कार्यस्थल

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

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

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

यह सब क्यों है?

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

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

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

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

हालांकि, आईटी उद्योग विकसित हो रहा है, उत्पाद, कंपनियां, उपकरण विकसित हो रहे हैं, उपयोगकर्ता अधिक चयनात्मक हो रहे हैं, प्रतिस्पर्धा बढ़ रही है, और आशा है कि भविष्य अभी भी उच्च गुणवत्ता वाले उत्पादों के साथ होगा।

निष्कर्ष

वास्तव में, लेख का विषय, निश्चित रूप से, बहुत विवादास्पद है।

उपरोक्त ग्राफ इस सवाल का जवाब नहीं देता है कि किस समय सिस्टम का डिज़ाइन बंद होना शुरू हो जाता है।

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

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

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