क्या मुझे डिजाइनिंग पर समय बिताना होगा?

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



सबसे पहले, डिजाइन करना हमेशा आवश्यक होता है, भले ही परियोजना में सब कुछ "स्पष्ट और ऐसा ही" हो।

दूसरे, डिजाइन की अवधि और इसकी चक्रीयता इस बात पर निर्भर करेगी कि परियोजना कितनी जटिल है और परियोजना निष्पादन की टीम कितनी अनुभवी है।

संदर्भ की शर्तों का निर्माण

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

और टीके के बाद क्या?

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



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



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

कब गंभीरता से डिजाइन करना है, और कब प्रोटोटाइप बनाना है?

मैं यह नहीं कहूंगा कि मैं एक डिजाइन गुरु हूं, यह सबसे अधिक संभावना नहीं है, लेकिन मुझे बड़ी परियोजनाओं में भाग लेने का अनुभव है।



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



दूसरे विकल्प में, विभिन्न परिस्थितियां संभव हैं:

1. ग्राहक के लिए व्यवस्थित प्रोटोटाइप, वहां सब कुछ सुपर है, हर कोई खुश है! बधाई हो, आपकी टीम को नोबेल पुरस्कार की आवश्यकता है। यह स्थिति विशुद्ध रूप से सैद्धांतिक है, मैं इसे पौराणिक भी कहूंगा;

2. कुछ चीजें ग्राहक के अनुरूप नहीं थीं, कार्यान्वयन के कुछ स्कूलों को आपने देखा;

3. प्रोटोटाइप बिल्कुल सही नहीं है ।

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



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

ऐसा क्यों?

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

अंतभाषण

मैंने बहुत सारे शब्द लिखे, अब कुछ घूंघट और मैंने इस बारे में बात क्यों की:

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



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