क्या जीयूआई से शुरू होने वाले एप्लिकेशन का निर्माण करना उपयोगी हो सकता है?

Question

एप्लिकेशन डिजाइन और विकास में रुझान "हिम्मत" से शुरू होता है: डोमेन, फिर डेटा एक्सेस, फिर बुनियादी ढांचा, आदि। जीयूआई आमतौर पर इस प्रक्रिया में बाद में आते हैं। मुझे आश्चर्य है कि अगर यह पहले जीयूआई बनाने के लिए उपयोगी हो सकता है ...

मेरा तर्क यह है कि कम से कम एक प्रोटोटाइप जीयूआई का निर्माण करके, आप एक बेहतर विचार प्राप्त कर सकते हैं कि पर्दे के पीछे क्या होना चाहिए, और इसलिए डोमेन और सहायक कोड पर काम शुरू करने के लिए बेहतर स्थिति में हैं।

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

यह एक वास्तविक परियोजना के लिए एक संभव विचार हो सकता है? हो सकता है कि हम GDD (GUI ड्रिवेन डेवलपमेंट) को स्टेबल के साथ जोड़ सकें ...

Comments

यह रैपिड एप्लिकेशन डेवलपमेंट है।

— जेम्स लव

क्या वैसे भी GUI लिखना उपयोगी है? जब तक यह एक मोबाइल ऐप, एक वेब ऐप या किसी भी ऐप के लिए नहीं है, जो छवियों को दिखाता है, तो मुझे इसकी आवश्यकता नहीं है।

— 1

कोड फर्स्ट बनाम डाटाबेस फर्स्ट

— gnat

Answer 1

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

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

इन जोखिमों को कम करने के लिए सक्रिय चर्चा और संभवतः आपके उपयोगकर्ताओं और / या प्रबंधकों की शिक्षा की आवश्यकता होती है।

Comments

व्यावहारिक प्रोग्रामर प्रोटोटाइप भाग को शामिल करता है, और हाँ, आप पूरी तरह से सही हैं। प्रोटोटाइप डिस्पोजेबल कोड है;)

— ऑस्कर मेडेरोस

"औसत उपयोगकर्ता के लिए, जीयूआई अनुप्रयोग है"। मैं अकेले उस अवलोकन के लिए इस 100 बार बढ़ाऊंगा।

— PSU

@ ऑस्कर, संदर्भ के लिए धन्यवाद, मैं व्यावहारिक रूप से भूल गया कि वे इस पर चर्चा करते हैं। यह वास्तव में पढ़ने की सिफारिश की है।

— Péter Török

@ user13645, मुझे यह दावा नहीं है कि यह मेरा है - वास्तव में मैंने अभी जोएल द्वारा मूल ब्लॉग पोस्ट का लिंक जोड़ा है जबकि आपने अपनी टिप्पणी :-)

— पेर्ट टॉरक

यही कारण है कि GUI प्रोटोटाइप उपकरण जैसे balsamiq.com ने दिखाया। आप यह दिखा सकते हैं कि जीयूआई कैसा दिखेगा और ग्राहक से शुरुआती प्रतिक्रिया मिलेगी। दूसरी ओर, टूल द्वारा बनाए गए GUI में पूरी तरह से एक अलग कला (हाथ से खींचा जाने वाला थोड़ा सा) है ताकि ग्राहक सीधे समझ सके कि यह उत्पाद का अंतिम रूप नहीं होगा। और इसे उत्पाद के लिए शुरुआती कोड के रूप में उपयोग नहीं किया जा सकता है - बस डिजाइन के रूप में।

— टोबियास लैंगर

Answer 2

मैं इसके साथ जो समस्या देख रहा हूं वह यह है कि लक्ष्य पूरी तरह से पिछड़ा हुआ लग रहा है।

"मेरा तर्क यह है कि कम से कम एक प्रोटोटाइप जीयूआई का निर्माण करके, आप एक बेहतर विचार प्राप्त कर सकते हैं कि पर्दे के पीछे क्या होना चाहिए, और इसलिए डोमेन और सहायक कोड पर काम शुरू करने के लिए बेहतर स्थिति में हैं।"

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

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

डेटा लेयर और UI लेयर की स्वतंत्रता को प्रोत्साहित किया जाना चाहिए। यही कारण है कि एक विशिष्ट यूआई को लक्षित करने के बजाय केवल संपूर्ण डेटा का प्रतिनिधित्व करने के लिए डेटा परत का निर्माण करना लंबे समय में बेहतर काम करता है।

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

Answer 3

मुझे लगता है कि @ Péter यह सुझाव देना सही है कि GUI प्रोटोटाइप बनाना एक अच्छा विचार है। मैं गधे-बैकवर्ड तरीके से उपयोगकर्ता अनुभव प्रदान करने के संभावित नुकसान के साथ पूरक करना चाहता हूं, अर्थात्, ऑन्कोलॉजी, वास्तुकला और बुनियादी ढांचे पर ध्यान केंद्रित करना और पिछले उपयोगकर्ता का तत्काल अनुभव।

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

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

प्रत्येक craptastic अनुभव के लिए, प्रवाह विचित्र, खराब collocated सूचना, चीजें हैं जो सिर्फ सादा गलत हैं, उदाहरणों जब भी आप पूछने के लिए "बस जो प्रतिभा के साथ आया था विनती की है स्पष्ट कार्यक्षमता की कमी है कि ?", झूठ कुछ है कि, पर ध्यान नहीं दिया नकार दिया या उपयोगकर्ता को विकास के प्रयासों में सबसे आगे बताया।

Answer 4

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

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

यह वेब सेवाओं या अन्य एपीआई को डिजाइन करने के लिए प्रासंगिक है - केवल इसे " अनुबंध-पहले " डिजाइन के रूप में जाना जाता है ।

तो, जैसा कि सब कुछ है, पहले डिजाइन करने के लिए क्या नियम है; कभी-कभी यह मॉडल है, और कभी-कभी यह जीयूआई है। एक अंगूठे के नियम के रूप में, मैं "सबसे महत्वपूर्ण भाग पहले डिजाइन" के साथ जाऊंगा।

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

Answer 5

मुझे लगता है कि यह एप्लिकेशन डिजाइन के करीब पहुंचने का एक बहुत अच्छा तरीका है, खासकर एक फुर्तीले विकास के माहौल में। मैंने जिन पर काम किया है, उनमें से अधिकांश ने एक प्रोटोटाइप के साथ शुरुआत की है जो अंततः वास्तविक चीज बन गई है।

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

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

और आप प्रोटोएप को क्यों फेंकना चाहेंगे? हम मैचस्टिक्स से बाहर बने स्टेडियमों के साथ काम नहीं कर रहे हैं। बस कुछ अच्छा में लानत बात refactor।

Answer 6

अगर मुझे GUI देखने वाला व्यक्ति समझता है कि यह केवल एक शेल है और शाब्दिक बटन और प्रक्रियाएँ काम नहीं करती हैं (नया NotImplementedException (;);) फेंकें) तो मुझे बिल्कुल भी बुरा नहीं लगता।

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

प्रबंधन के लिए, उन्हें 3 भागों के साथ एक बड़ा पाई चार्ट ड्रा करें, उन्हें "एम", "वी", और "सी" लेबल करें। V को लगभग 20% दें और बाकी पाई को "TBC";) समझाएं।

Answer 7

किसी भी तरह के आकार की प्रणाली में, पर्दे के पीछे क्या होने की जरूरत है, जो जीयूआई जैसा दिखता है, उससे संबंधित है। GUI आपको केवल कुछ आवश्यकताओं को देगा। अक्सर कई घटक होते हैं जिनमें कोई GUI नहीं होता है।

सिस्टम के विकसित होने के बाद अतिरिक्त इंटरफेस (नए GUI सहित) की आवश्यकता हो सकती है। सफल होने के लिए व्यावसायिक आवश्यकताओं को समझना और कार्यान्वित करना महत्वपूर्ण है।

जीयूआई और अन्य इनपुट और आउटपुट तंत्र को डिजाइन करने से मॉडल को मान्य करने में मदद मिल सकती है। विशेषताएँ जो कभी आउटपुट नहीं होती हैं, उनकी आवश्यकता नहीं हो सकती है। (उन्हें रखने के लिए कारण हो सकते हैं, लेकिन वे संभवतः ऑडिट या नियामक आवश्यकताएं होंगी।)

जैसा कि दूसरों ने उल्लेख किया है, एक बार जब आपके पास एक काम करने वाला जीयूआई होगा, तो कई ग्राहक सोचेंगे कि आप कर रहे हैं। हालाँकि, आपके पास इसके पीछे कोई बुनियादी ढांचा नहीं हो सकता है। जीयूआई के लेआउट और सामग्री को मान्य करने के लिए पेपर प्रोटोटाइप एक अच्छा विकल्प हो सकता है।

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