फ्रंट एंड पहले या बैक एंड पहले। दो में से कौन सा एक अच्छा सिस्टम डिज़ाइन प्रैटिस है?

Question

मेरे पास अभी एक क्लाइंट है जो मुझे स्कूल नामांकन प्रणाली विकसित करने की आवश्यकता है। अब यह पहली बार है जब इस तरह की चुनौती है। पिछले सॉफ्टवेयर के अधिकांश जो मैंने बनाया है वह जटिल नहीं हैं।

मैं जानता हूं कि आप सभी ने जटिल सॉफ्टवेयर्स बनाए हैं, मैं सिर्फ इस पर आपकी सलाह चाहता हूं। क्या मुझे पहले फ्रंट एंड बैक एंड डिजाइन करना चाहिए?

धन्यवाद!

यहाँ एक लेख का निष्कर्ष है जो मुझे कुछ समय पहले इंटरनेट में मिला था। बस शेयर करना चाहते हैं

http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157

फ्रंट-एंड बनाम बैक-एंड डेवलपर्स (मेरे ले)

मेरा व्यक्तिगत लेना

फिर से यह प्रशिक्षण की बात है, कुछ व्यापक स्ट्रोक सामान्यीकरण:

फ्रंट एंड डेवलपर्स

• आमतौर पर एक सीएस डिग्री नहीं है, या एक 3 स्तरीय स्कूल से सीएस की डिग्री है।
• मूल के समान भाषाओं में काम करें (देखें PHP बेसिक है)
• फ़ोटोशॉप दस्तावेज़ों को CSS / HTML / etc में परिवर्तित करने में एक दृश्य कौशल हो।
• टाइप फ्री भाषाओं के कारण, पुनरावृति प्रोग्रामिंग के लिए एक उच्च सहिष्णुता है

बैक एंड डेवलपर्स

• सीएस डिग्री हो या बहुत अनुभव हो
• मुझे उनकी समस्या को सुलझाने के दृष्टिकोण में और अधिक व्यवस्थित करें
• एक वस्तु जो लीक हो रही है, उसे खोजने में दिन बिताने का मन न करें
• समस्याओं को हल करने के लिए उपकरणों का प्रयास करें और निर्माण करें

Comments

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

— पेटर टॉर्क

smh, यही कारण है कि मैं लोगों को बताता हूं कि मैं एक सॉफ्टवेयर डेवलपर बनाम वेब डेवलपर हूं।

— pllee

आगे और पीछे के अंत के देवों के बारे में इन सामान्यीकरणों का सवाल क्या है?

— एरिक रेपेने

फ्रंट एंड देव! = बैक एंड देव, हालांकि अधिकांश समय, संक्रमण बी / डब्ल्यू उन्हें चलता रहता है।

— अभिनव Gauniyal

मुझे लगता है कि यहां एकमात्र मान्य उत्तर 'यह निर्भर करता है ...'

— ओलिवर वेइलर

Answer 1

यदि आप पीछे से शुरू करते हैं, और आगे की ओर जाते हैं, तो आप ग्राहक को गलतफहमी का जोखिम देते हैं। जैसा कि आप ऐसी चीजें बना रहे हैं जो वे आसानी से नहीं देख सकते हैं और समझ नहीं सकते हैं, वे आवश्यकताओं को पूरा करने के लिए सत्यापित करने में बहुत आसानी से भाग नहीं ले सकते हैं। इसका मतलब है कि आप बहुत सारा काम बर्बाद कर सकते हैं।

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

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

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

Comments

मुझे लगता है कि एक अधिक संक्षिप्त विवरण है। लेकिन यह बेहतर होगा कि बैक एंड फर्स्ट कोज बनाने के बाद मुझे लगता है कि फ्रंट एंड को बनाना आसान है अगर आपके पास एक स्ट्रक्चर्ड बैक एंड है।

— drexsien

अगर उन्हें लगता है कि फ्रंट एंड सब कुछ है, तो आप Google का उल्लेख कर सकते हैं ...

— l0b0

इसलिए आपको एक मॉक-अप GUI का निर्माण करना चाहिए, जिसे आप क्लाइंट को दिखाते हैं और कहते हैं कि "क्या आप प्रोग्राम को करना चाहते हैं?"

— गैबलिन

+1। @andsien: यदि आप पहले से ही अपनी राय रखते हैं, तो आपने क्यों पूछा? मेरे अनुभव के अनुसार, पॉल सही है, सुविधा-संचालित विकास लगभग हमेशा बेहतर रणनीति है।

— डॉक ब्राउन

@andsien: "यदि आपके पास एक अच्छी तरह से संरचित बैक एंड है तो फ्रंट एंड बनाना आसान है"। IMHO कि एक खतरनाक गलतफहमी है। समस्या यह है: आपको पता नहीं है कि क्या आपका बैक एंड तब तक अच्छी तरह से संरचित है जब तक कि आपने इसका इस्तेमाल फ्रंटेंड के लिए फीचर बनाने के लिए नहीं किया है।

— sleske

Answer 2

सॉफ्टवेयर के कई आयाम हैं, इसलिए, एक अति सरलीकृत फ्रंट-बनाम-बैक एक खराब प्रश्न है और बहुत, बहुत ही मुश्किल है, एक समझदार, उपयोगी उत्तर प्रदान करना।

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

एक दृश्य प्रसंस्करण की गतिशील संरचना है। इस दृष्टि से भी कम से कम तीन आयाम हैं।

एक तीसरा दृश्य वास्तुशिल्प घटक हैं, जो परतों में स्वाभाविक रूप से गिरते हैं, उपयोग के मामलों का समर्थन करते हैं, और लागत और जोखिम होते हैं।

मैं जा सकता था, लेकिन बात यह है।

फ्रंट-एंड बनाम बैक-एंड डेवलपर्स (मेरे ले)

समस्या को देखने के लिए लगभग कम से कम उपयोगी तरीका है। वास्तविक डेवलपर्स - और उनमें से आपकी राय - बहुत, यहाँ बहुत कम। क्या मायने रखता है

• मामलों और अभिनेताओं का उपयोग करें

• उन उपयोग मामलों का समर्थन करने के लिए तार्किक डेटा मॉडल

• प्रक्रिया जो उपयोग केस के हिस्से के रूप में की गई है

• आपके द्वारा उपयोग किए जाने वाले घटक तार्किक और प्रसंस्करण तत्वों के निर्माण के लिए उपयोग किए जाएंगे।

यही कारण है कि अधिकांश लोग कहते हैं कि आपको उपयोगकर्ता कहानी या उपयोग के मामले में अपने सिस्टम को विघटित करने की आवश्यकता है।

उन लोगों के बारे में व्यापक स्ट्रोक सामान्यीकरण नहीं करें जो विकास कर रहे होंगे।

Answer 3

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

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

लेकिन आप जो भी करते हैं, एक के डिजाइन को दूसरे के हुक्म को नहीं चलने देते। इस तरह पागलपन है।

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

इसके अलावा, 2008 में फ्रंट एंड डेव्स की बैक एंड डेव से तुलना करना वेब वर्षों में बहुत पहले की बात है। मज़े के लिए, मैं उस पुराने चेस्टनट में कुछ चीजों को सही करना / जोड़ना चाहता हूं क्योंकि हमने इसे प्रश्न में जोड़ा है, लेकिन (उम्मीद है कि) कुछ सुझावों को एम्बेड करें:

फ्रंट एंड डेवलपर्स

आमतौर पर एक सीएस डिग्री नहीं है, या एक 3 स्तरीय स्कूल से सीएस की डिग्री है।

हाथों को दिखाएँ। CS डिग्री वाले कितने लोगों को सामने के छोर पर सर्वोत्तम अभ्यास सिखाया गया है? या जावास्क्रिप्ट के साथ गड़बड़ी कैसे नहीं करें? या कैसे IE6-IE9 से सीएसएस समस्याओं को संभालने के लिए? पाठ्यपुस्तक उद्योग, जो एकेडेमिया चलाता है, बहुत मोटा आलसी है और लगातार बदलती प्रौद्योगिकी को संभालने के लिए फूला हुआ है, इसलिए इसे कॉलेजों में बहुत कम 'गंभीर' ध्यान मिला है। यह अपने जैसे देर से खिलने वालों के लिए उत्कृष्ट रहा है।

मूल के समान भाषाओं में काम करें (देखें PHP बेसिक है)

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

फ़ोटोशॉप दस्तावेज़ों को CSS / HTML / etc में परिवर्तित करने में एक दृश्य कौशल हो।

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

टाइप फ्री भाषाओं के कारण, पुनरावृति प्रोग्रामिंग के लिए एक उच्च सहिष्णुता है

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

Comments

मेरा एकमात्र खेद यह है कि मैं आपके प्रश्न को एक से अधिक बार +1 नहीं कर सकता। यह एक शर्म की बात है कि मुझे इस सवाल के 2 जवाबों को नीचे स्क्रॉल करना पड़ा, आखिरकार इसे खोजने के लिए जहां यह कहा गया है कि सामने और पीछे के क्रम के बारे में पूछना और विकसित किया जाना गलत सवाल है। मैं सीएस डिग्री पर आपकी राय से भी सहमत हूं। और अंतिम "देर से खिलने वाले" टिप्पणी।

— शिवन ड्रैगन

Answer 4

इसका एक भी सही उत्तर नहीं है। कुछ स्थितियों में या तो दृष्टिकोण अच्छा (और बुरा) हो सकता है।

मैं आपको TDD दृष्टिकोण पर विचार करने की सलाह देता हूं, जहां एक (स्वीकृति और इकाई) परीक्षणों द्वारा नेतृत्व किया जाता है।

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

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

इस दृष्टिकोण के लिए, एक अनुशंसित रीडिंग ग्रोइंग ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर है, जो टेस्ट द्वारा निर्देशित है ।

Answer 5

एपीआई पहले

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

एक पुनरावृत्त दृष्टिकोण के साथ गठबंधन और इस तरह दिखना चाहिए:

1. एक साधारण एपीआई डिजाइन
2. दोनों टीमें एपीआई के आधार पर विकसित और परीक्षण करती हैं
3. जोड़ने का परीक्षण
4. ग्राहक को दिखाएं और प्रतिक्रिया प्राप्त करें।
5. API बढ़ाएँ और दोहराएं।

Answer 6

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

उनकी सुरक्षा अपेक्षाओं और कानून की आवश्यकता के बारे में पूरी जानकारी प्राप्त करें। यह सुनिश्चित नहीं है कि यह किस प्रकार का स्कूल है, लेकिन छात्र की जानकारी के लिए आमतौर पर कुछ गोपनीयता की आवश्यकता होती है।

यदि संभावित छात्र किसी वेबसाइट पर डेटा दर्ज कर रहे हैं, तो ग्राफिकल डिज़ाइन एक मुद्दे से अधिक होने वाला है।

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

तब आप डेटाबेस से जुड़ी जानकारी प्राप्त करना शुरू कर सकते हैं।

Comments

सामने के अंत के साथ शुरू करने में समस्या (अनुभव के आधार पर) यह है कि जब आप कुछ कार्यक्षमताओं को भूल जाते हैं, तो यह आपकी पीठ के अंत को गड़बड़ कर सकता है और आपको इसे ठीक करने की कोशिश कर रहा हो सकता है

— drexsien

@andsien - क्या आप डिजाइनिंग या बिल्डिंग के बारे में बात कर रहे हैं? मैं बैकएंड को डिजाइन किए बिना फ्रंट एंड बनाना शुरू नहीं करूंगा।

— जेफो

मेरी गलती im इमारत के बारे में सोच रहा था ... उस jeff के लिए धन्यवाद।

— drexsien

Answer 7

हाँ मुझे एहसास हुआ कि ओपी ने थोड़ी देर पहले पूछा। पीछे के छोर से शुरू करें लेकिन उपयोगकर्ता को यह देखने के लिए अनुमति देने के लिए सामने के छोर को ऊपर की ओर दबाएं। सामने का छोर, सभी के लिए यह मूल्य है, बस घंटियाँ और सीटी हैं। पिछला छोर वह है जहां पैसा है, और एक बार जब आप सीधे होते हैं, तो मांस पर केवल ग्रेवी होती है।

Comments

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

— एरिक रिपेन

@ErikReppen मुझे कई बार ऐसा अनुभव हुआ है - मैं क्लाइंट को दिखाना चाहता था "उपयोगकर्ता एक टेक्स्ट फ़ील्ड में डेटा दर्ज करेगा" और क्लाइंट देखता है "फॉर्म फ़ील्ड बिल्कुल 400 पिक्सेल चौड़ा होगा और पृष्ठ का रंग हल्का नीला होगा एरियल 11pt पाठ के साथ पृष्ठभूमि ... "लेकिन मुझे अभी भी लगता है कि यह सामने के छोर को प्रदर्शित करने से बेहतर है। अन्यथा एक संपूर्ण प्रणाली का निर्माण संभव है जो उनके मुख्य उपयोग के मामले में कुछ अस्थिर धारणा के साथ संघर्ष करता है।

— अष्टकूट

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

— एरिक रेपेन

इर्र, यह नहीं है कि हमारे पास सीएसएस क्यों है? (हालांकि मैं आपका दर्द महसूस करता हूं )। मैं हमेशा और जानबूझकर एक बदसूरत, लेकिन कार्यात्मक, FE और सादा बनाता हूं कि हम Use Cases, वर्कफ़्लो पर चर्चा कर रहे हैं ... और बाद में इसे पहले से बता सकते हैं। (लेकिन इसका सही जवाब

— डेटाबेस-

Answer 8

मेरी टिप्पणी पर विस्तार:

पहले आवश्यकताओं को इकट्ठा करें, फिर उन्हें उपयोग मामलों और डिजाइन में बदल दें।

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

आप बीई के बिना एफई के साथ कैसे शुरू कर सकते हैं? किस लिए ??? अपने डेटाबेस को परिभाषित करें !! यही एफई चालाकी करता है।

ठीक है, वहाँ की समस्याओं और बाद में तोड़ मरोड़ हो जाएगा, और मैं ऐसा मानता हूँ कि यह ग्राहक यथाशीघ्र के सामने एक सरल, नमूना, जीयूआई प्राप्त करने के लिए अच्छा है, के बाद से हिमशैल के उस विशेष टिप जो सबसे सबसे समझते हैं।

हालाँकि, I 1) तनाव है कि यह केवल एक मोटा मज़ाक है, चर्चा के लिए porpoises, और 2) जानबूझकर इसे बदसूरत, लेकिन कार्यात्मक बनाते हैं , ताकि जो लोग इसे समझ नहीं पाते हैं और मुझे उस इनपुट बॉक्स को 400Xpx बनाने के लिए कह सकें चौड़ी और पृष्ठभूमि हल्की-नीली।

मैं गिर गया कि अधिकांश उत्तर यहां (और मैंने उनका अनुसरण किया है) ग्राहक पर बहुत अधिक ध्यान केंद्रित करते हैं, लेकिन, विशुद्ध रूप से s / w दृष्टिकोण से, मैं यह मानता हूं कि आप पहले से बिना बीई में हेरफेर करने के लिए एक एफई डिजाइन नहीं कर सकते। डिजाइनिंग कि बी.ई.

Comments

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

— at ’’

यह क्या प्रोटोटाइप है? कोई लौ युद्ध, यह सिर्फ मेरे सिर में popped। मैं समझता हूं कि एक प्रोटोटाइप क्या है, लेकिन शायद इसलिए कि मैं एक अलग क्षेत्र से आया हूं, मैं हमेशा इसे केवल इस रूप में देखता हूं: आवश्यकताएं प्राप्त करें, उन्हें उपयोग के मामलों और डिजाइन में बदल दें। यदि आपके पास अपना डी / बी नॉट डाउन नहीं है, तो आप बहुत अधिक अनावश्यक पुनरावृत्ति करेंगे, इसलिए पहले उस प्रकार को हल करें, फिर यह पता लगाएं कि इसमें कैसे हेरफेर किया जाए (आवश्यकताओं के अनुसार)। YMMV ... जारी ...

— माग

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

— नोटेर

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

— sleske

मुझे संदेह है कि हम एक ही बात को अलग-अलग तरीकों से कह सकते हैं (+1)

— मग