कोड शुरू करने से पहले आप कितनी योजना बनाते हैं?

Question

जब आप एक नई परियोजना शुरू कर रहे हैं, तो आप इसके लिए कैसे योजना बनाते हैं या कितना समय लगता है?

छद्म कोड? फ्लोचार्ट्स?

क्या आप पहले से ही सभी कक्षाओं के बारे में सोचने की कोशिश करते हैं?

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

Answer 1

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

वे आम तौर पर निम्नलिखित संरचना का पालन करें:

1. एक संक्षिप्त बनाएँ ताकि मेरे मन में एक उद्देश्य है।
2. उस डेटा को समझने के लिए class diagram लागू करें जिसका मैं निपटान करूँगा।
3. सभी कक्षाओं को लागू करें।
4. गतिविधियों की रूपरेखा के लिए use-case diagram बनाएं।
5. उपयोग-केस आरेख (वेबपैस के लिए एचटीएमएल में) मचान करें
6. यूनिट परीक्षणों को कार्यान्वित करके और उन्हें पारित करने के लिए मचान को वायर करें।
7. वाणिज्यिक सफलता के लिए उत्पाद को रिलीज़ करने का निर्णय लें, फिर इसके बारे में सब भूल जाओ।

Answer 2

एक बहुत कम से कम मैं

मैं हमेशा में, गोता चाहिए गंदे हो और फिर पता है कि मैं एक गड़बड़ कर दिया है। फिर वापस जाएं और योजना बनाएं, और सही करें।

लेकिन गंदे गलतियों के चरण मुझे महान विचार देता है कि मुझे औपचारिक डिजाइन प्रक्रिया के दौरान नहीं होता।

संपादित मैं मुख्य रूप से इस तरह में मिलता है जब बड़े/जटिल के साथ खेल कुंजीपटल भोजनालयों तोड़। यह देखने में दिलचस्प है कि इससे पहले कि आप अपने सिर में हैं, तो यह ठीक है 'डिजाइन 100% त्रुटिपूर्ण है।

Answer 3

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

Answer 4

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

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

Answer 5

शायद सबसे अच्छी तकनीक नहीं है ... लेकिन ... मैं कोड में योजना बना रहा हूं।

मुझे अक्सर कक्षा/विधियों/आदि की खोज होती है। कि मुझे इसे इस तरह से करने की ज़रूरत है। उस के साथ, मैं हमेशा मानता हूं कि मेरा नियोजन कोड अंतिम समाधान नहीं होने वाला है।

इसके अतिरिक्त मैं "प्रमुख विशेषताएं" और "मामूली/इच्छा सुविधाओं" का विवरण देने वाले नोट्स लिखूंगा।

Answer 6

किसी भी आकार की समस्या लेने पर, मैं हमेशा इसे कम से कम दो बार लिखने की योजना बना रहा हूं।

Answer 7

यह सब इस बात पर निर्भर करता है कि यह परियोजना कितनी बड़ी है। कभी-कभी सभी आवश्यकताओं को इकट्ठा करने में काफी महीनों लग सकते हैं और पता होना चाहिए कि उसे क्या करना है।

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

हालांकि, यदि यह सरल कोडिंग है।मैं आमतौर पर सिर्फ अपने दिमाग में क्या लिखता हूं और इसका परीक्षण करता हूं।

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

यह मेरी राय है।

Answer 8

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

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

Answer 9

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

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

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

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

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

Answer 10

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

Answer 11

व्यक्तिगत रूप से यह प्रोजेक्ट की जटिलता & दायरे पर निर्भर करता है, मैं इस पर कितने लोगों के साथ काम कर रहा हूं, और वितरण पर समग्र अपेक्षाएं।

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

अक्सर, सॉफ्टवेयर विकास में शामिल पार्टियों को यह नहीं पता कि पार्टियों के बीच संचार अक्सर परियोजना का सबसे महत्वपूर्ण और अविकसित हिस्सा है - और परियोजना दुर्घटनाओं का प्रमुख कारण है।

Answer 12

मैं कुछ कॉफी पीता हूं और कुछ सैंडविच तैयार करता हूं।

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

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

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

Answer 13

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

1. मिलने और हर किसी परियोजना के साथ शामिल स्वागत होगा प्राप्त करने के लिए
2. कथित आवश्यकताओं के बारे में प्रचुर नोट ले
3. उच्च स्तर की आवश्यकताओं की लंबी बुलेट वाली सूचियां बनाने
4. शुरू अच्छी तरह से परिभाषित विवरण में उच्च स्तर की आवश्यकताओं को तोड़ने के लिए
5. सॉफ़्टवेयर आवश्यकताएं भरना शुरू करें विशिष्टता शब्द टेम्पलेट: SRS
6. cre में फ़ोटोशॉप तार फ्रेम खा लिया, एक्सेल, या (मेरी पसंदीदा) Balsamiq
7. सूची डेटा है कि कब्जा कर लिया जाना चाहिए और बाहर एक किसी न किसी स्कीमा
8. सूची यूएमएल में वर्ग संरचना के निर्माण के लिए शुरू
9. परियोजना समय को परिभाषित
10. blah blah blah
11. कोड लिखें
12. उम्मीद है कि अनुरोध किया गया था कि कोड पूरा होने पर अभी भी क्या चाहिए!

पिछले कुछ वर्षों से मैं Agile (SCRUM) के साथ पीछा कर रहा हूं और एक पूरी तरह से अलग दृष्टिकोण लिया है। उत्पाद मालिक के साथ

1. मिलने कार्यों के बारे में सुनने के लिए कार्य (मूल योजना)
2. कार्यों को असाइन समय में
3. घुलना कहानी निर्मित होने की
4. कुछ अधिक विस्तृत योजना बना कर
5. -> लिखने परीक्षण, परीक्षा पास करने के लिए कोड लिखें, रिफैक्टर -> नृत्य में चेक करें
6. कामकाजी उत्पाद/फीचर
से अधिक प्रक्रिया शुरू करें

मुझे यह कहना है कि Agile दस्तावेजों को लिखने में कितना समय कम करता है जो स्याही सूखने के साथ ही क्षय हो जाता है। उत्पाद के मालिक को परिणाम को और अधिक तेज़ी से देखना पड़ता है। जिसका अर्थ यह है कि वे समय के साथ परियोजना को सही दिशा में रखने के लिए मिलते हैं - भले ही वह दिशा बदलती जा रही हो।

ध्यान रखें कि विकास के दोनों तरीकों के लिए एक समय और स्थान है। मैं Agile का उपयोग कर जेट सॉफ्टवेयर बनाना नहीं चाहता!

Answer 14

मैं विश्वविद्यालय में अभी भी कर रहा हूँ और मैं अभी तक बड़े पैमाने पर सॉफ्टवेयर सिस्टम बनाने के साथ अनुभव की जरूरत नहीं है, लेकिन ...

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

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

एक बार जब मैं कम या ज्यादा जानता हूं कि मैं क्या करने की कोशिश कर रहा हूं, तो मैं बैठकर कोड लिखता हूं। यह यहां है कि मैं जो सोच रहा था उसमें मुझे कोई समस्या है।

मुझे नहीं लगता कि मैंने प्रत्येक एल्गोरिदम डिज़ाइन करने के लिए छद्म कोड का उपयोग किया है। मुझे लगता है कि कार्यक्रम के बड़े हिस्से को डिजाइन करने के लिए छद्म कोड बहुत कम स्तर है।

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

Answer 15

IMO नियोजन के 5 मिनट कोडिंग के आगे = 1 घंटे ....

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

सबसे महत्वपूर्ण हिस्सा फ्लोचार्ट होना चाहिए।

अन्य विवरण कभी-कभी फ्लाई पर ध्यान दिया जा सकता है।

Answer 16

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

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