मुझे एक परियोजना कैसे शुरू करनी चाहिए?

Question

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

क्या कोई मानक है, जब कोई परियोजना शुरू करता है जैसे कि कक्षाओं को मैप करना और यूनिट परीक्षणों से शुरू करना? एक मध्यम परियोजना की योजना बनाते और शुरू करते समय एक अच्छा सम्मेलन क्या है।

आखिरी परियोजना और शुरू किया गया एक प्रक्षेप्य गति सिम्युलेटर था - मुझे पता है, अनुमानित।

Comments

एक डिज़ाइन चुनें और उसके साथ रहें। लगता है कि आप अपने डिजाइनों को बदलने के लिए कारण ढूंढ रहे हैं।

— रामहाउंड

क्या आपका प्रश्न परियोजना के डिजाइन पहलू से संबंधित है या इस तथ्य से कि आप बदलाव के बारे में सोचते हैं और आप परियोजना के पूरे दायरे को बदल देते हैं?

— नं

@ रामहाउंड: "एक डिज़ाइन चुनें और उसके साथ रहें" पूरी तरह से काम करता है, जब तक आप कोड लिखने और परीक्षण करने के बाद एक डिज़ाइन चुनते हैं।

— केविन क्लाइन

मैं शायद डिज़ाइन पैटर्न और OO डिज़ाइन पर थोड़ा पढ़ना चाहूँगा। इसने मेरी मदद की। अगर मुझे लगता है कि आप शुरुआती हैं तो मैं हेड फर्स्ट डिज़ाइन पैटर्न की सिफारिश करूंगा।

— डैरेन यंग

Answer 1

जब आप योजना बनाते हैं, तो आवेदन के बारे में पहले से हर संभव योजना न बनाएं। बेबी स्टेप्स में प्लान करें। आवेदन का उपयोग शुरू करने के लिए आपको आवश्यक न्यूनतम न्यूनतम कार्यक्षमता क्या है ? वहाँ शुरू करो।

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

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

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

Comments

+1: यह एक उत्तर है जो मैं पीछे पा सकता हूं। पूर्ण न्यूनतम के लिए योजना बनाएं और आवश्यकतानुसार योजना में जोड़ें, लेकिन न्यूनतम जोड़ें।

— जोएल एथरटन

सरल, लेकिन इसने बहुत अच्छा काम किया; धन्यवाद।

— 22 मिनट पर Will03uk

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

— फ्रेडरिक विट्टे

Answer 2

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

Comments

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

— आर्सेनी मूरज़ेंको

Answer 3

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

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

Answer 4

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

Answer 5

http://nathanmarz.com/blog/suffering-oriented-programming.html

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

Answer 6

एप्लिकेशन डिजाइन करने के दो पहलू हैं। पहला निर्णय ले रहा है कि आपका आवेदन क्या कर सकता है। दूसरा यह डिजाइन कर रहा है कि यह कैसे करना है। परिवर्तन जो करता है वह बहुत महत्वपूर्ण है और आवेदन की परिपक्वता पर निर्भर करता है (और आवेदन की दिशा में बदलाव) को फिर से काम करने के बजाय एक फिर से लिखने वाले के रूप में जाना जाता है।

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

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

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

Answer 7

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

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

Answer 8

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

Answer 9

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

दूसरे शब्दों में, जब आप कुछ भी डिजाइन नहीं शुरू करते हैं !!! ।

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

तो, सुविधाओं की बुनियादी सूची + प्राथमिकताओं = आवश्यकताएँ ।

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

Ie: अब आप अपने डिजाइनरों से आग्रह करने के लिए मिलता है ।

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

रोना कहर ढाने दो, कुत्तों को ... कोड !!

वहां से, अपने विनिर्देशों से मिलान करने के लिए अपने परीक्षणों को लागू करें, फिर प्रत्येक परीक्षण के लिए, अपना कोड लिखें। बिल्ड, "रिलीज़", फिर अगली विशेषता के साथ दोहराएं जब तक आप तय नहीं करते कि परियोजना पर्याप्त है।

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

Answer 10

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

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

• संक्षिप्त अंग्रेजी पाठ।
• "Goal Driven" सबसे अच्छा काम करता है यानी "बंदर को एक अंगूर मिलता है" "Monkey Pushes red button" से बेहतर है।
• तकनीकी शब्दावली पर प्रतिबंध। कोई "पुलडाउन", "टेक्स्ट बॉक्स" नहीं। एक अच्छा उपयोग का मामला किसी भी इंटरफ़ेस तकनीक से स्वतंत्र होना चाहिए। आपको HTML आधारित प्रणाली के लिए उपयोग मामला लेने में सक्षम होना चाहिए और इसे उपयोग किए गए मामले में बिना किसी बदलाव के ध्वनि सक्रिय प्रणाली के लिए उपयोग करना चाहिए। (यह करना बहुत कठिन है लेकिन इसके लायक है!)।
• अपने पहले मसौदे की शब्द गणना को 50% तक कम करने के लिए, किसी भी अनावश्यक कदम और क्रिया से छुटकारा पाएं।

अपनी प्रमुख कक्षाओं को निर्दिष्ट करने के लिए आप तैयार हैं:

यूएमएल- यूनिवर्सल मॉडलिंग लैंग्वेज। कक्षाओं को डिजाइन करने के लिए मानक उपकरण है। आप प्रत्येक वर्ग के सार्वजनिक सदस्यों और विधियों को निर्दिष्ट करते हैं और उन्हें एक स्पष्ट संक्षिप्त चित्रमय मॉडल में एक साथ जोड़ते हैं।

अनुक्रम आरेख, डेटा मॉडल के साथ संयोजन में, आप किसी भी कोडिंग के होने से पहले अपने डिज़ाइन को सत्यापित और सुधार सकते हैं।

Answer 11

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

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

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

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