योजना बनाम परीक्षण - सॉफ्टवेयर विकास

लेखन सॉफ्टवेयर के लिए फुर्तीला, स्क्रम, फैंसी शब्द जो प्रदान करता है

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

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

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

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

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

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

nb किसने अनुमान लगाया होगा कि विकास के प्रति मेरे दृष्टिकोण का एक नाम है, इसे एक चुस्त कार्यप्रणाली के रूप में वर्गीकृत किया गया है! यहाँ एक उत्कृष्ट लेख है जो बताता है चुस्त कार्यप्रणाली कुछ विस्तार से.