2009-05-13 23 views
7

डुप्लिकेट:। Design & Coding - top to bottom or bottom to top?शीर्ष नीचे वी नीचे ऊपर डिजाइन दृष्टिकोण

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

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

शीर्ष डाउन दृष्टिकोण के मामले में मुझे विश्वास होगा कि डिजाइनर इंटरफ़ेस के क्लाइंट साइड को देखेगा और क्लाइंट इंटरफ़ेस के साथ कैसे सहभागिता करेगा और फिर कंक्रीट कक्षाओं को लागू करने का प्रयास करेगा।

तो मैं ऊपर-नीचे/नीचे-अप के फायदे और नुकसान देख सकता हूं। मैं सिर्फ यह जानना चाहता हूं कि कौन सा अधिक कुशल है और आपके पिछले अनुभवों के आधार पर बेहतर परिणाम प्रदान करता है?

नोट: मैं विकास पद्धति (फुर्तीली, झरना इत्यादि) के बारे में बात नहीं कर रहा हूं, मैं डिजाइन दृष्टिकोण के बारे में बात कर रहा हूं।

उत्तर

15

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

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

उम्मीद है कि मदद करता है।

+2

+1 सहमत - कोई "एक समाधान" नहीं है लेकिन –

4

यह समस्या पर निर्भर करता है।

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

यदि आपके पास समस्या का अस्पष्ट विचार है [फ़ील्ड एजेंटों को वितरित ऑफ़लाइन/ऑनलाइन विकी के माध्यम से संवाद करने की अनुमति दें] तो एक शीर्ष-डाउन दृष्टिकोण बेहतर काम करेगा। सभी समस्याओं को देखें और उन्हें हल करने के लिए किन कदमों का उपयोग किया जा सकता है। परीक्षण त्रुटि विधि। चुस्त।

4

सॉफ़्टवेयर डिज़ाइन करने का कोई सही तरीका नहीं है। कोई दृष्टिकोण सही डिजाइन की गारंटी नहीं देगा।

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

समस्या को अपने उच्चतम स्तर पर समझें और समाधान के माध्यम से अपना रास्ता कम करें, उन हिस्सों की पहचान करें जहां विवरण डिज़ाइन को बदलना समाप्त हो सकता है (विवरण आपको निम्नतम स्तर से संपर्क करना चाहिए और अपना रास्ता वापस लेना चाहिए)।जब तक आपके पास ऐसा डिज़ाइन न हो जो काम करने के लिए पर्याप्त हो, तब तक समस्या के सभी घटकों के माध्यम से पुनरावृत्ति रखें।

Code Complete अध्याय 5 वास्तव में मैं जो कह रहा हूं उसके विवरण को हथियाने में मदद कर सकता हूं। मेरा सुझाव है कि आप एक नज़र डालें।

2

मुझे यकीन नहीं है कि मैंने आपके प्रश्न को सही ढंग से समझा है, लेकिन यदि मेरे पास है, तो आप एक आवेदन के निर्माण के साथ पेशेवर/विपक्ष के लिए पूछ रहे हैं और फिर यह इंटरफ़ेस बनाम इंटरफेस बना रहा है और फिर इसे वास्तव में बनाने के लिए ऐप का निर्माण कर रहा है कार्य करना।

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

+0

दोनों का मिश्रण इसे तोड़ने के लिए धन्यवाद –

0

नीचे-अप हम में से बहुत सारे कोड हैं। पसंद के माध्यम से नहीं बल्कि इंटेलिजेंस के माध्यम से। पेटज़ोल्ड ने इस here के बारे में एक लेख लिखा था।

प्रैक्टिस में मुझे लगता है कि आपको आर्किटेक्ट डिज़ाइन का अधिकांश हिस्सा मिल जाएगा। मैं व्यक्तिगत रूप से नहीं सोचता कि मैंने कभी किसी को दूसरे तरीके से डिजाइन (अमूर्त के लिए ठोस) डिजाइन किया है।

निश्चित रूप से, आवश्यकताएं ठोस-आश हैं लेकिन आम तौर पर अबास्ट्रक्शन को निर्देशित करने और सॉफ़्टवेयर के उद्देश्य और उद्देश्य को परिभाषित करने के लिए आवश्यकताओं का उपयोग करता है।

संबंधित मुद्दे