[अनुवाद] सॉफ्टवेयर विकास में 7 घातक पाप

दोस्तों, मैं आपके लिए infoworld.com पर प्रकाशित नील मैकलिस्टर के लेख "सॉफ्टवेयर विकास के 7 घातक पाप" प्रस्तुत करता हूं।


मैं एक बार में एक आरक्षण करना चाहता हूं कि मैंने "फीचर" शब्द का इस लेख में अक्सर "फीचर" के रूप में अनुवाद किया, क्योंकि यह मेरे लिए एक सामान्य अनुवाद विकल्प है।

तो चलिए चलते हैं।

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

1. जुनून (अतिरिक्त डिजाइन)

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

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

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

2. लोलुपता (रिफ्लेक्टर में असमर्थता)

किसी उत्पाद को जारी करने से ज्यादा मजेदार कुछ नहीं है। एक बार आपके पास तैयार संस्करण होने के बाद, प्रलोभन अगले विकास यात्रा की योजना बनाना शुरू करने के लिए बहुत अच्छा है। मुझे कौन सी नई सुविधाएँ जोड़नी चाहिए? उनमें से कौन सा हमारे पास पहले संस्करण के विकास के दौरान करने का समय नहीं था?

यह भूलना आसान है कि कोड बहुत कम है। कार्यक्षमता की मात्रा स्वाभाविक रूप से विकास के प्रत्येक पुनरावृत्ति के साथ बढ़ जाती है, और प्रोग्रामर आमतौर पर पिछले पुनरावृत्तियों में की गई गलतियों को बढ़ाते हैं। यह बदले में, एक फूला हुआ और नाजुक कोड होता है जो इसे प्रभावी ढंग से समर्थन करने के लिए बहुत उलझन में है।

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

3. लालच (विकास टीमों के बीच प्रतिस्पर्धा)

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

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

4. आलस्य (इनपुट डेटा के सत्यापन की कमी)

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

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

5. गुस्सा (कोड पर टिप्पणी करने के लिए अभ्यास की कमी)

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

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

लेकिन याद रखें कि निरर्थक टिप्पणियां, साथ ही अत्यधिक वाक्यांश, टिप्पणियों की पूर्ण अनुपस्थिति से भी बदतर हो सकती हैं। "यह काम नहीं करता है" या "किसी भी मामले में इसे स्पर्श न करें!" जैसी टिप्पणियाँ दूसरों के लिए बहुत उपयोगी नहीं हैं। शुरुआती वेरिएबल्स जैसे सरल ऑपरेशन की व्याख्या करने वाली अनावश्यक टिप्पणियां भी बेकार हैं। कोड सबसे अच्छा दस्तावेज़ जो यह करता है; यह समझने के लिए टिप्पणियों की आवश्यकता है कि यह क्यों आवश्यक है।

6. ईर्ष्या (संस्करण नियंत्रण प्रणालियों का उपयोग नहीं)

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

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

7. गर्व (इकाई परीक्षण की कमी)

अक्सर आप खुद को पीठ पर थपथपाना चाहते हैं और अच्छी तरह से काम करने के लिए धन्यवाद देते हैं। लेकिन आप कैसे जानते हैं कि यह वास्तव में अच्छी तरह से बनाया गया है? आप किन मेट्रिक्स का उपयोग करते हैं?

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

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

पीएस मैं खुद से यह जोड़ना चाहता हूं कि स्टीव मैककोनेल की पुस्तक परफेक्ट कोड में पूरे अध्याय के साथ कई विचार गूंजते हैं। यदि आपने इसे अभी तक नहीं पढ़ा है, तो मैं इस चूक को सुधारने की सलाह देता हूँ :)