मैंने अभी आपके द्वारा पोस्ट किए गए लेख लिंक को पढ़ा है, मुझे कहना है कि फाउलर ने कुछ बहुत अच्छे अंक बनाए हैं और बहुत सारी बातें उन्होंने कहा है, मैं वर्षों से हमारी टीम के साथ वकालत कर रहा हूं।
IMO, यदि आप कोई भी अच्छा डिज़ाइन करते हैं, तो आपको इस बात पर ध्यान नहीं देना चाहिए कि इसे मृत-अंत की स्थिति कैसे माना जाएगा। मैंने हमेशा सॉफ़्टवेयर को बिल्डिंग ब्लॉक्स से देखा है । मैं अभी भी कुछ अप-फ्रंट डिज़ाइन में विश्वास करता हूं, लेकिन मुख्य लक्ष्य पूरे उत्पाद को डिज़ाइन करना नहीं है, बल्कि समग्र वास्तुकला / दिशा प्रदान करना है ताकि आपकी टीम एक सामान्य तस्वीर की कल्पना कर सके जो हम सभी की ओर काम कर रहे हैं। यदि आपके पास घन और त्रिकोण के टुकड़ों का एक गुच्छा है, तो यह स्केच करने में मददगार है कि कैसे महल को एक साथ रखा जाएगा इससे पहले कि आप बस टुकड़ों को एक साथ शुरू करें।
चूंकि मैं OO भूमि से आता हूं, मेरे लिए प्रत्येक ब्लॉक एक वर्ग है और उस ब्लॉक का सतह क्षेत्र सार्वजनिक इंटरफ़ेस है (बाहरी या व्युत्पन्न वर्गों द्वारा दिखाई देता है)। यदि आप अच्छे SOLID सिद्धांतों का पालन करते हैं, तो आप यह सुनिश्चित करेंगे कि प्रत्येक ब्लॉक बेहद सरल और एक सहज सार्वजनिक इंटरफ़ेस है। मेरे सादृश्य में वापस जाना, आप यह सुनिश्चित करना चाहते हैं कि आप कोड केवल सरल आकृतियाँ बनाते हैं। जब भी आप कक्षाएं बनाते हैं, तो वे बहुत जटिल होते हैं (कई फ़ंक्शन, कई चर), आप ऐसे आकार बनाते हैं जो आवश्यकताएं बदलने पर पुन: उपयोग करना कठिन होते हैं।
मैं फाउलर से सहमत हूं कि विकासवादी डिजाइन के लिए सबसे बड़ा जोखिम / चुनौती यह है कि आप डिजाइन के फैसले कोडिंग समय पर छोड़ देते हैं, और आप प्रत्येक व्यक्तिगत डेवलपर से उन निर्णयों की अपेक्षा करते हैं। यह वह जगह है जहां सिस्टम टूट सकता है यदि आपके पास उचित प्रतिक्रिया तंत्र नहीं है। जब भी एक नई सुविधा के लिए कहा जाता है, तो यह केवल उस फ़ंक्शन को खोजने के लिए बेहद आकर्षक होता है जिसे विस्तारित करने की आवश्यकता होती है, इसके अंदर किसी प्रकार की सशर्तता डालें और उस फ़ंक्शन के ठीक अंदर कोड का एक पूरा गुच्छा जोड़ें। और कभी-कभी, यह सब आवश्यक हो सकता है, लेकिन यह (आईएमओ) एकल सबसे आम अभ्यास भी है जो मृत-अंत घटकों की ओर जाता है। इसका विकासवादी डिजाइन से कोई लेना-देना नहीं है। इसे "नो डिज़ाइन" कहा जाता है।
जब तक आप वापस कदम रखने और कहने का समय लेते हैं, तब तक एक मिनट रुकें, इस वर्ग में पहले से ही 15 सदस्य चर हैं, मुझे इनमें से 6 को निकालने और अपने स्वयं के वर्ग में डालने के लिए, आपका सॉफ्टवेयर बहुत हल्का हो जाएगा -वह, लचीला और पुन: प्रयोज्य इमारत ब्लॉकों। निश्चित रूप से अगर पीएम साथ आते हैं और आप पर आधे उत्पादों की आवश्यकताओं को बदलते हैं, तो आपको अपने कुछ ब्लॉक लेने होंगे, उन्हें वापस शेल्फ पर रखना होगा और कुछ नए लोगों को आकर्षित करना होगा (जैसे कि महल बनाते समय, आप सभी का उपयोग नहीं कर सकते हैं आपके सिलेंडर)। लेकिन उस बिंदु पर, यह व्यवसाय करने का सिर्फ एक हिस्सा है। आवश्यकताएं बदल गई हैं और अपने कोड को लचीला और मॉड्यूलर रखते हुए, आपको अपने उत्पाद को अपनी नई व्यावसायिक दिशा के साथ संरेखित करने में सक्षम होना चाहिए।
मेरा मानना है कि इंजीनियर के कौशल के हर स्तर के साथ काम करने के लिए यह विकासवादी दृष्टिकोण है। व्यक्तिगत रूप से, मैंने बहुत लंबे समय तक सॉफ्टवेयर किया है और इससे पहले कि हमारी टीम फुर्तीली कार्यप्रणाली में चले, मैं अपने देव पीसी से कई प्रमुख घटकों को लगभग सीधे किसी भी क्यूए के साथ ग्राहक को शिपिंग करने के लिए जिम्मेदार था। एक ही समय में उन घटकों हमेशा लचीला और बनाए रखा है।
मैं केवल यह कहने की कोशिश कर रहा हूं कि मैं डिजाइनिंग सॉफ्टवेयर में खुद को अपेक्षाकृत सभ्य समझूंगा। उसी समय, अगर आपने मुझसे 100-पेज का डिज़ाइन डॉक्यूमेंट लिखने के लिए कहा है, तो उसे एक कोडर को दें और उससे काम करने की अपेक्षा करें, मैं शायद खुद को एक पेपर बैग से डिज़ाइन नहीं कर सकता। काम शुरू करते समय, मैं कभी-कभी कुछ यूएमएल-जैसे (बहुत ही सरलीकृत, पूर्ण भाषा नहीं) आरेखों को स्केच करता हूं, लेकिन जैसा कि मैंने कोडिंग शुरू की है, मैं आवश्यकतानुसार आवश्यक आधार पर रिफ्लेक्टर करूंगा और मेरा अंतिम कोड कभी भी ऐसा नहीं दिखेगा, जो मैंने मूल रूप से आकर्षित किया था। यहां तक कि अगर मैं हर छोटे से विवरण के बारे में एक या दो महीने बिताता हूं, तो मैं किसी और को अपने आरेख लेने में सक्षम नहीं कर सकता और डिजाइन को संशोधित किए बिना सॉफ्टवेयर के ठोस टुकड़े के साथ आ सकता हूं क्योंकि वे कोडिंग कर रहे हैं।
स्पेक्ट्रम के दूसरे छोर पर, वर्तमान में मेरी टीम में (अब चुस्त और मैं पूरी तरह से समर्थन करता हूं) हमारे पास कुछ लोग हैं जो एम्बेडेड भूमि से हमारे साथ जुड़ गए हैं जहां उन्होंने पिछले 15 वर्षों से केवल सी किया है। मैंने स्पष्ट रूप से कुछ प्रारंभिक योजना और कक्षाओं को बिछाने में मदद की, लेकिन मैंने नियमित कोड समीक्षा और बुद्धिशीलता सत्रों के साथ पालन करना सुनिश्चित किया, जहां हम SOLID और डिजाइन सिद्धांतों के अनुप्रयोगों पर चर्चा करते हैं। उन्होंने कुछ स्पेगेटी कोड का उत्पादन किया, जिसने मुझे थोड़ा कमज़ोर बना दिया, लेकिन मुझ से बस थोड़ी सी नोक-झोंक के साथ, उन्होंने जो कुछ पहले ही निर्मित किया था, उसे वापस लेना शुरू कर दिया और मजेदार बात यह है कि उनमें से एक कुछ दिनों बाद मेरे पास आया और कहता है, मुझे नफरत है यह कहने के लिए, लेकिन उस कोड को स्थानांतरित करने के बाद, यह इतना अधिक पठनीय और समझने योग्य लगता है। डेड-एंड एवरेज। बिंदु I ' मी बनाने की कोशिश कर रहा है कि यहां तक कि कोई भी जो ओओ के लिए पूरी तरह से नया है, कुछ हद तक सभ्य कोड का उत्पादन कर सकता है, जब तक कि उसके पास अधिक अनुभव वाला एक संरक्षक है, उसे याद दिलाने के लिए कि "विकासवादी डिजाइन" "कोई डिजाइन नहीं" जैसी चीज नहीं है। और यहां तक कि उनके कुछ "अधिक जटिल" वर्ग उस डरावने नहीं हैं क्योंकि प्रत्येक वर्ग के पास इतनी ज़िम्मेदारी नहीं है (अर्थात इतना कोड नहीं है), तो सबसे बुरा बदतर होता है, अगर वह एक वर्ग "डेड-एंड", हम इसे चक दें और एक प्रतिस्थापन वर्ग लिखें जिसमें समान सार्वजनिक इंटरफ़ेस है (अब तक मैंने कभी भी इस आकस्मिकता की आवश्यकता नहीं देखी थी कि हमने क्या लिखा है और मैं सप्ताह में दो बार कोड समीक्षा कर रहा हूं)।
अंतिम नोट के रूप में, मैं डिजाइन दस्तावेजों में एक दृढ़ विश्वास रखने वाला व्यक्ति हूं (कम से कम मेरी वर्तमान टीम की व्यावसायिक स्थितियों के लिए) लेकिन हमारे डिजाइन डॉक्स के लिए प्राथमिक लक्ष्य संगठनात्मक मेमोरी है , इसलिए वास्तविक दस्तावेज कोड के उत्पादन के बाद लिखे जाते हैं और पुनर्संशोधित। कोडिंग से पहले, हमारे पास आम तौर पर एक त्वरित (कभी-कभी इतनी जल्दी नहीं) डिजाइन चरण होता है जहां हम नैपकिन / mspaint / visio पर कक्षाएं छोड़ते हैं और मैं हमेशा लोगों को याद दिलाता हूं कि यह चरण एक ब्लूप्रिंट नहीं बल्कि पालन करने के लिए एक पथ का उत्पादन करता है और जैसा कि वे कोडिंग करते हैं। जो कुछ भी समझ में नहीं आता है उसे बदला जाना चाहिए। यहां तक कि इन अनुस्मारक के साथ, नए लोग मूल डिजाइन में फिट कोड को वापस करने की कोशिश करते हैं, भले ही यह उनके लिए कितना भी अप्राकृतिक हो। यह आमतौर पर कोड समीक्षा में सतहों।
डांग, मैंने बहुत कुछ लिखा। उसके लिए माफ़ करना।