गर्भाधान और कोडिंग से पहले डिजाइन: यह कितना सच है? [बन्द है]


14

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

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

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

हम पहले से ही अनुभव और प्रोग्राम किए गए किसी चीज़ को कैसे गर्भ धारण कर सकते हैं? क्या यह हास्यास्पद नहीं है? क्या प्रोग्रामिंग इसके बजाय गर्भाधान और डिजाइन का नेतृत्व नहीं करता है?



@ आपके द्वारा यहां दिया गया लिंक मेरे प्रश्न के एक पहलू का उत्तर हो सकता है। मुझे नहीं लगता कि यह कोई डुप्लिकेट प्रश्न है।


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

2
केवल एक बार जब आप सही मायने में और पूरी तरह से एक समस्या को समझते हैं, तो इसे हल करने के बाद, इसलिए यह केवल समझ में आता है कि एक बार समस्या को समझने के बाद, आप इसे बेहतर तरीके से हल कर सकते हैं। लेकिन वास्तव में समस्या को समझने के लिए आपको खोज के अभ्यास से गुजरना होगा।
मैट क्लिंकर

जवाबों:


5

मुझे लगता है कि इसका उत्तर होना चाहिए: जितना हो सके उतना प्लान करें, लेकिन इससे ज्यादा नहीं।

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

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

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


30

यह बिल्कुल सच है। आवश्यकता जितनी बड़ी और जटिल होती है, यह उतनी ही सही होती है।

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

लेकिन कैसे एक वास्तविक समय के व्यापार मंच के बारे में लाखों लेनदेन एक दूसरे, विश्व स्तर पर वितरित करने की उम्मीद है और इसके लिए 99.9999 अपटाइम और 100% शुद्धता की आवश्यकता है? क्या आप कोडिंग में कूदेंगे?

इन दो चरम सीमाओं के बीच बहुत सारे अन्य विकल्प हैं।

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

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


मैं शुरू से ही सब कुछ डिजाइन और गर्भ धारण करने में सफल नहीं हुआ

कोई भी कुछ भी नहीं करता है लेकिन समस्याओं का सबसे तुच्छ है। फिर से, बड़ा और अधिक जटिल परियोजना, और अधिक सच यह है - डिजाइन में गलतियां होंगी, अनदेखी की गई चीजें आदि ...

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

इसमें समय और प्रयास लगता है - और शुरुआत में पूर्ण या पूर्ण रूप से सही नहीं हो सकता है।

लेकिन इसीलिए इसे सॉफ्ट -वेयर कहा जाता है न कि हार्ड -वेयर। यह निंदनीय है और इसे बदला जा सकता है।


4
बहुत बढ़िया जवाब। ध्यान दें कि, हालांकि सॉफ्टवेयर है लचीला (वास्तव में, यह इसके बारे में अद्भुत और अद्वितीय चीजों में से एक है), संशोधन नहीं कर रहे हैं मुक्त । एक सॉफ्टवेयर सिस्टम जितना कसकर युग्मित और असंगत होता है, उसे संशोधित करना उतना ही कठिन और महंगा होगा। सॉफ़्टवेयर की डिज़ाइन में जाने की क्षमता का एक हिस्सा यह है कि भविष्य में बदलने की क्षमता होनी चाहिए , अगर कोई सॉफ़्टवेयर की मॉलबिलिटी का लाभ उठाना चाहता है।
रात १०:१०

9

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

यह सच है।

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

और आपकी समस्या है।

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

तो यह निश्चित रूप से सच है कि आपको समय से पहले डिजाइन करने की आवश्यकता है, लेकिन यह भी सच है कि केवल समय से पहले डिजाइन करना असंभव है ।


5

कोडिंग से पहले आपके पास कुछ डिज़ाइन होना चाहिए ।

कारण बहुत सीधा है - यदि आपके पास कोई डिज़ाइन नहीं है, तो आप नहीं जानते कि आप क्या बना रहे हैं

डिज़ाइन के अंतिम होने से पहले आपके पास कुछ कोड होना चाहिए ।

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

विकास पुनरावृति है।

योजना द्वारा या नहीं, टीम को इसका पता चलता है या नहीं, प्रत्येक सॉफ्टवेयर परियोजना को पुनरावृत्त रूप से पूरा किया जाता है - काम का हिस्सा पूरा हो जाता है, और फिर मूल्यांकन किया जाता है, और मूल्यांकन में परिवर्तन होता है कि शेष कार्य कैसे किया जाता है।

एक से अधिक तरीकों की कोशिश करें।

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


1

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

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

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

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

आप कोडिंग से पहले एक पूर्ण डिज़ाइन नहीं कर सकते हैं (और आपको नहीं करना चाहिए) लेकिन आपके पास उपयोगकर्ता का वर्कफ़्लो क्या होगा, इसका एक मोटा स्केच होना चाहिए।

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


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

पूर्व-डिज़ाइन: "लॉजिक का वर्णन करने के लिए Visio में आकृतियाँ और तीर जैसे हैं; विभिन्न प्लेटफार्मों (एसएपी, एसएफ, डेटाबेस ...) के लिए कनेक्शन की अनुमति देने के लिए प्लग-इन क्षमताएं हैं; एक मॉनिटरिंग कंसोल है, जहां कोई डेटा गुजरने वाले डेटा की खोज कर सकता है; प्रणाली; डेटा को नेत्रहीन रूप से वर्णन करने और एक प्रारूप को दूसरे में बदलने का एक तरीका है "। एक और महान विपणन बूँद। यह आपको कुछ विचार भी देता है कि महत्वपूर्ण क्या है, कोडिंग से पहले भी इस तरह के एक स्केच होना चाहिए।

डिज़ाइन / कोड: "इस तरह की विशेषताओं के साथ एक HTML डिज़ाइनर को होस्ट किया गया है; जावा में बैकएंड को कोड करें ताकि वह किसी भी मौजूदा सर्वर को चला सके; डेटा संरचनाओं और UX को परिभाषित या आवश्यकतानुसार उन्हें संशोधित करने के लिए; आपदा वसूली, त्रुटि की योजना; रिपोर्टिंग, ऑडिट लॉगिंग; योजना संस्करण नियंत्रण; योजना अभिगम नियंत्रण; .... "- यह जितना अधिक अवास्तविक है, सूची को उतना ही बेहतर बनाना है।

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


0

मैं हमेशा समय का आवंटन इस प्रकार करता हूं:

  1. 1/3 डिज़ाइन
  2. 1/3 विकास
  3. 1/3 परीक्षण

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

विकास: एक बार जब आप अपने भागों को जानते हैं, तो उन्हें कोड करें। फिर आप उन्हें एकीकृत करते हैं।

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

इन पहलुओं के अलावा, ध्यान रखें कि एक परियोजना में इन चरणों के शीर्ष पर 3 चरण भी हैं।

  1. अंडर-इंजीनियर पहला प्रयास
  2. 1 प्रयास से सीखे गए सबक से अधिक इंजीनियर दूसरा प्रयास।
  3. ठीक से इंजीनियर 3 प्रयास।

मैंने पाया है कि आप बेहतर डिजाइन चरण करते हैं, कि यह अतिरिक्त प्रयासों को कम करता है। पूरे काम को फिर से करने के बजाय, आपके पास बस एक उप-प्रणाली हो सकती है, जिसे फिर से काम किया जाता है।

मैं इन-हाउस, आउटसोर्स और ऑफ-शोर विकास परियोजनाओं के लिए एक सॉफ्टवेयर डेवलपर और सॉफ्टवेयर डेवलपमेंट मैनेजर हूं।


-1

यहां एक मौलिक गलत धारणा है। आप पहले कोड लिखे बिना अच्छे डिजाइन के साथ कभी नहीं आ पाएंगे (स्कूल कभी भी आपको यह नहीं सिखाएगा)। फिर भी, स्कूल सही है कि आपको डिजाइन के बिना अच्छा कोड नहीं मिलेगा।

समाधान है:

  1. कुछ कोड लिखें जो आपको लगता है कि समस्या को हल कर सकते हैं।
  2. एक डिज़ाइन के साथ आओ जो आपने कोड से सीखा था।
  3. सभी कोड को फेंक दें और इसे डिजाइन के अनुसार स्क्रैच से फिर से लिखें।
  4. आवश्यकतानुसार दोहराएं।

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

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


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

+1। पता नहीं क्यों यह अपमानजनक था। "इसे फेंकने के लिए एक निर्माण करें" एक क्लासिक फ्रेड ब्रूक्स सलाह है।
निक्की

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

-3

गर्भाधान मुख्य डिज़ाइन है जिसे हमेशा बदला जा सकता है प्रोग्रामिंग को पूरी तरह से कल्पना की गई ऐप की आवश्यकताओं को पूरा करना होगा।

1st व्हाट्स पॉइंट, 2nd को इसे एक्सेस करने की आवश्यकता कैसे है, तीसरा जो उपयोगकर्ता है, 4 वां काम का पूरा SOW स्कोप विशिष्ट शब्दों में परिभाषित करता है जो यह सभी एप्लिकेशन करना है। और आपके द्वारा जोड़ा गया प्रत्येक फ़ंक्शन कैसे काम करेगा।

इससे पहले कि आप वेब ऐप की वास्तुकला के लिए कोई विकल्प चुनते हैं, योजना बनाएं और इसे पूरी तरह से सोचें।

तो सबसे अच्छा ढेर उठाओ

मैं एक LAMP डेवलपर हूं

इसलिए मैं इस सवाल को संकुचित करता हूं कि php फ्रेमवर्क का मैं क्या उपयोग करूंगा। और सामने की अंत लिपियों को मुझे उन सभी चीजों को करने की आवश्यकता होगी जो मुझे आदर्श तरीके से करने की आवश्यकता है

इसे जोड़ने के लिए, MVC फ्रेमवर्क का उपयोग करना सीखें, ZEND और CAKEPHP सबसे अच्छे रैपिड डेवलपमेंट फ्रेमवर्क (PHP) हैं


7
" सबसे अच्छा स्टैक उठाओ ... मैं एक LAMP डेवलपर हूं " - जबकि किसी के बुनाई के लिए छड़ी करना पूरी तरह से ठीक है, यह कथन एक मामूली विरोधाभास की तरह लगता है, है ना?
जेन्सजी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.