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

बिजनेस सिस्टम डेवलपर्स का नाम खराब है

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

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

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

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

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

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

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

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