एक नई परियोजना पर योजना और प्रोग्रामिंग का सही मिश्रण

Question

मैं एक नई परियोजना (एक खेल, लेकिन महत्वहीन) शुरू करने वाला हूं। मूल विचार मेरे सिर में है, लेकिन सभी विवरणों में नहीं।

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

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

अद्यतन : कैसे एक "डमी क्लिक करें" के साथ शुरू करने और बाद में कार्यक्षमता को लागू करने के बारे में?

Answer 1

आप सही रास्ते पर हैं। महीनों की योजना बनाने में कोई खर्च करने की आवश्यकता नहीं है, लेकिन आपके पास निश्चित रूप से किसी प्रकार की योजना होनी चाहिए।

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

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

Comments

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

— वॉरेनफैथ

आप वर्तनी "प्लानिंग" को गलत रखते हैं। बस मैंने सोचा था कि मैं आपकी टिप्पणी को संपादित नहीं कर सकता हूं :) लेकिन हां, मुझे लगता है कि घोटाला एक शानदार दृष्टिकोण है, इससे लचीलापन बना रहता है और आपको यह तय करने का मौका मिलता है कि क्या यह परियोजना को जारी रखने के प्रयास के लायक है।

— jmort253

ऊ जर्मन में इसका दूसरा तरीका है: एक n के साथ योजना बनाना और दो मीटर के साथ प्रोग्राम करना ...: D धन्यवाद!

— वॉरेनफैथ

@ArrenFaith - क्षमा करें! यही मेरी जातीयता सामने आ रही है! मेरी गलती को इंगित करने के लिए धन्यवाद;)

— jmort253

Answer 2

न्यूनतम व्यवहार्य उत्पाद की योजना बनाएं , और उस पर अमल करें। फिर अपने उपयोगकर्ताओं को सुनें और अगली तार्किक वृद्धि की योजना बनाएं, और उस पर अमल करें। दोहराएँ।

Comments

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

— k3b

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

— वॉरेनफ्रैथ

@WarrenFaith: विशेषताएं - >> कहानियाँ - >> परीक्षण के मामले।

— स्टीवन ए लोव

Answer 3

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

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

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

Comments

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

— वॉरेनफैथ

@Warren - योजना को विफल करने से रिफैक्टिंग नहीं होती है। आप या तो कंप्यूटर पर समाधान कोड कर सकते हैं, या इसे अपने सिर में या कागज पर कोड करने का प्रयास कर सकते हैं। मुझे लगता है कि वे दोनों अप्रभावी हैं। कोडिंग शुरू करें, यह जानते हुए कि आप इसे बाद में बदल देंगे।

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

@kevin cline: ठीक है, नई सुविधा या सुधार के लिए मौजूदा कोड को फिर से लाने और एक नई सुविधा के लिए लगभग पूरे ऐप को फिर से लिखने के बीच अंतर देता है। मैं पहली के साथ रह सकता हूं, वास्तव में दूसरे के साथ नहीं ..

— वॉरेनफैथ

@ArrenFaith: जब तक कोड तंग और आकार में है, तब तक आपको फिर से लिखने से बचना चाहिए। जब मैंने सिस्टम को फिर से लिखा है, तभी देखा है जब सिस्टम मिट्टी की एक बड़ी गेंद (कोई रिफैक्टिंग नहीं), या मौलिक तकनीकी परिवर्तन (प्लेटफ़ॉर्म का परिवर्तन) बन गया है।

— मार्टिन विकमैन

Answer 4

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

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

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

अधिक संक्षेप में संक्षेप में कहें, तो कोई कह सकता है कि "सबसे कठिन भाग को पहले निपटाना, विभाजित करना और जीतना, छद्म कोड और / या TDD योजनाओं के साथ"!

Comments

मैं TDD का प्रशंसक नहीं हूँ लेकिन फिर भी धन्यवाद!

— वॉरेनफैथ

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

— ब्रैडबेल

Answer 5

बस कोड को मॉड्यूलर बनाने का प्रयास करें। अगले पुनरावृत्ति के दौरान आपके द्वारा योजनाबद्ध कुछ भी फेंके जाने की संभावना है।

Answer 6

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