मेरे कोड के एक बड़े हिस्से में एक प्रमुख डिजाइन दोष है। इसे खत्म करो या अब इसे ठीक करो? [बन्द है]

Question

मैं एक हाई स्कूल का छात्र हूं, जो C # प्रोजेक्ट पर काम कर रहा है, मेरे साथ मेरे दोस्त भी उसी कौशल स्तर के हैं। अब तक, हमने 100 कमिट्स की अवधि में कोड की लगभग 3,000 पंक्तियों और टेस्ट कोड की 250 पंक्तियों को लिखा है। स्कूल के कारण, मैंने कुछ महीनों के लिए परियोजना को बंद कर दिया और हाल ही में मैं इसे फिर से वापस लेने में सक्षम था।

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

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

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

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

Comments

गंभीरता से: अपने उत्पादों में एक प्रमुख डिजाइन दोष होने से लैरी एलिसन को कभी नहीं रोका गया। यह आपको क्यों परेशान करता है?

— पीटर गेकर्न्स

काम बेकार नहीं गया। इसने आपको एक बेहतर प्रोग्रामर बनाया है।

— संपतसरिस

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

— gcampbell

@JoeBlow "सॉफ्टवेयर का 100% जल्दी से पूरी तरह से बेकार हो जाता है और इसे फिर से खरोंचना पड़ता है।" इस कथन का तार्किक अर्थ नहीं है। आप मुझे बता रहे हैं जो सॉफ्टवेयर मैं रोज इस्तेमाल करता हूं ... पूरी तरह से बेकार है और खरोंच से फिर से तैयार होना है?

— ओल्डमुड 0

"ठीक है। हाँ, बिल्कुल। कोई भी OS9 या Windows3 का उपयोग नहीं कर रहा है। सॉफ्टवेयर उल्लेखनीय रूप से अस्थायी है।" आप हमेशा की तरह, आपके आत्मविश्वास के बावजूद गलत हैं! NT NT में पेश किया गया Windows NT कर्नेल, Windows 10 के मूल में भी है। कुछ 20 वर्षों में विंडोज में "पूर्ण पुनर्लेखन" नहीं हुआ है।

— परिक्रमा

Answer 1

अगर मैं आपके जूते में होता, तो मैं शायद इसे इस तरह आज़माता:

• सबसे पहले, वर्तमान परियोजना को समाप्त करें - कम से कम आंशिक रूप से - जितनी जल्दी हो सके, लेकिन एक कार्यशील स्थिति में । संभवतः आपको अपने मूल लक्ष्यों को कम करने की आवश्यकता है, न्यूनतम कार्यक्षमता के बारे में सोचें जो आपको वास्तव में "संस्करण 1.0" में देखने की आवश्यकता है।

• तब, और उसके बाद ही स्क्रैच से फिर से लिखने के बारे में सोचें (इस "संस्करण 2.0" को कॉल करें)। हो सकता है कि आप V1.0 से कुछ कोड का पुन: उपयोग कर सकें। हो सकता है कि फिर से सोने के बाद फिर से आप निर्णय पर आएं कि आप V1.0 को रिफ्लेक्टर कर सकते हैं और अधिकांश को बचा सकते हैं। लेकिन इससे पहले कि आप "कॉन्सेप्ट V1.0 का सबूत" न रखें, यह निर्णय न लें।

एक कामकाजी कार्यक्रम "1.0" कुछ ऐसा है जो आप दूसरों को दिखा सकते हैं, यहां तक ​​कि जब कोड खराब होता है (जो किसी और को परेशान नहीं करेगा, अपने आप को छोड़कर)। यदि V2.0 बनाने के मध्य में आपको एहसास होता है कि आप समय से बाहर चल रहे हैं, तो आपके पास अभी भी आंशिक रूप से सफलता के रूप में V1.0 है, जो आपके मनोबल के लिए बहुत बेहतर है। हालांकि, अगर आप V1.0 को पहले खत्म नहीं करते हैं, तो एक बड़ा मौका है कि आप कभी भी V2.0 को पूरा नहीं करेंगे क्योंकि जब आप आधे रास्ते से गुजरते हैं, तो एक बिंदु होगा जहां आप फिर से डिजाइन से असंतुष्ट हैं, और फिर? क्या आप V2.0 को फिर से छोड़ देंगे और V3.0 पर काम करेंगे? इस कभी न खत्म होने वाले घेरे में दौड़ने का एक उच्च जोखिम है, कभी भी समाप्त होने का नहीं।

बेहतर यह है कि मध्यवर्ती लक्ष्यों को प्राप्त करने के लिए एक अवसर के रूप में ले लो, बजाय एक अधूरा राज्य में परियोजनाओं को छोड़ने के लिए सीखने के अवसर के रूप में।

Comments

एक भी एक कार्यशील संस्करण 1.0 को रिफैक्टिंग प्रक्रिया के बारे में जानने के अवसर के रूप में देख सकता है।

— jpmc26

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

— यूजीन रियात्सेव

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

— केल

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

— CaffeineAddiction

अंतिम वाक्य अद्भुत है:Better take this as an opportunity to learn how to achieve intermediate goals, instead of an opportunity to learn how to leave projects in an unfinished state behind.

— ब्रैंडन

Answer 2

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

अनफिनिश्ड लोग आपको बहुत कुछ सिखा सकते हैं, लेकिन उतना नहीं जितना आप खत्म कर सकते हैं।

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

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

रोजगार के दृष्टिकोण से, ज्यादातर मामलों में, आपको एक तैयार परियोजना के लिए अधिक कुदोस मिलेंगे।

Comments

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

— RedSonja

Answer 3

मैं खुशी-खुशी प्रोजेक्ट शुरू करूंगा।

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

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

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

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

• एक टूटे हुए कोडबेस में काम करना आपके मनोबल पर एक पुनर्लेखन की तुलना में कहीं अधिक बड़ा नाला होगा।

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

अंत में, यहाँ कभी-कभी बड़े कदमों को आगे ले जाने के लिए कदम पीछे हटाने के ज्ञान पर एक राय है।

Comments

स्क्रैच से फिर से लिखना शायद ही कभी गलतियों से सीख रहा है और अक्सर बस नए बना रहा है

— whatsisname

मेरी राय में, एक परियोजना को खत्म करना बहुत अधिक महत्वपूर्ण है, फिर सही परियोजना होना। एक सतत "यह बहुत अच्छा नहीं है" का खतरा लूप वास्तविक है।

— पीटर बी

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

— डेल जॉनसन

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

— केविन

@whatsisname वे समान गलतियाँ नहीं करेंगे। जैसा कि आपने ऊपर कहा, वे नए बना रहे होंगे, जो उन्हें नई चीजें सिखाएंगे।

— केविन

Answer 4

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

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

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

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

Answer 5

मैं सॉफ्टवेयर डेवलपमेंट में "मेक इट वर्क, मेक इट राईट, मेक इट फास्ट" विचारधारा का पालन करता हूं ।

1. इसे कार्य करें : कोर कार्यक्षमता लिखें, ताकि परियोजना प्रयोग करने योग्य हो। सब कुछ काम करने के लिए आपके पास क्या है, भले ही इसका मतलब बदसूरत कोड हो।
2. इसे सही बनाएं : बग को ठीक करें और कोड को फिर से भरें ताकि पढ़ने, समझने और बनाए रखने में आसान हो।
3. इसे तेज़ करें : गति, संसाधन उपयोग और स्थिरता के बीच एक अच्छा संतुलन बनाने के लिए, इस कार्यक्रम का अनुकूलन करें।

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

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

एक महान प्रेरक वक्ता को उद्धृत करने के लिए: बस करो ।

हमेशा की तरह, एक प्रासंगिक xkcd है:

Comments

खुले स्रोत में, आप चरण 0 भी सम्मिलित कर सकते हैं, "बस इसे बनाएं"। यहां तक ​​कि अगर यह काम नहीं करता है, अगर यह काफी दिलचस्प है, तो इसे जारी करें, और शायद कोई आपको चरण 1 के साथ मदद करेगा

— Jörg W Mittag

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

— TOOGAM

मुझे नहीं लगता कि यह लागू होता है। ओपी स्पष्ट रूप से मौलिक डिजाइन समस्याओं के बारे में बात कर रहा है । आप बाद में उन्हें सुरक्षित रूप से "पैच" नहीं कर सकते।

— लाइट की दौड़ ऑर्बिट

चरण ०.५, १.५, २.५, और ३.५ भूलना मत: इसे पठनीय बनाना।

— कैंडिड_ओरेंज

Answer 6

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

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

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

Comments

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

— थेरेसा फोस्टर

कोड की 3k लाइनों पर कमिट्स की जांच करने में अधिक समय लग सकता है और फिर पूरी बात को फिर से लिखना होगा।

— मैथ्यू Whited

गिट रेपो के बारे में, बस इसे हटा दें और शुरू करें। वर्तमान कोड लगभग निश्चित रूप से पूरी तरह से वैधता है। किसी सर्वर पर इसे छोड़ने का क्या कारण है? - कोई नहीं। डिलीट पर क्लिक करें।

— फेटी

@JoeBlow: गिट रेपो को हटाने का कोई कारण नहीं। बस एक नई शाखा बनाओ। आप कभी नहीं बता सकते हैं कि आप पुराने सामान को कब देखना चाहते हैं।

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

Answer 7

आमतौर पर वास्तविक जीवन की परियोजनाओं में खरोंच से बचना एक बुरा कदम है, मुख्यतः क्योंकि वास्तविक जीवन की परियोजनाएँ बग फिक्स को जमा करती हैं कि एक नए डेवलपर को सॉफ्टवेयर ब्लॉग पर जोएल से (जैसे, चीजें आप कभी नहीं करना चाहिए , देखें ।)

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

सही डिजाइन आपके सिर में परिपक्व हो गया है और इसे कोड में लिखने के लिए अधिक समय नहीं लेना चाहिए।

Answer 8

मैं आदर के साथ उन सुझावों से असहमत हूं जो फिर से लिखना एक बुरा विचार है।

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

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

Comments

"उद्योग स्वीकृत" का क्या अर्थ है? संख्या का स्रोत क्या है?

— क्रिश्चियन

@Christian यह स्रोत प्रतीत होता है: ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100036670.pdf

TDD जाने का रास्ता है!

— 2rs2ts

Answer 9

आपने मुझे इस वाक्य में खो दिया:

समस्या यह है कि मैंने अपने कार्यक्रम की मुख्य कार्यक्षमता को भी समाप्त नहीं किया है, इसलिए मैं वास्तव में रिफ्लेक्टर नहीं कर सकता हूं, और मुझे पूरी तरह से पता है कि मेरे कोड का डिज़ाइन त्रुटिपूर्ण है।

मैं सिद्धांत में विश्वास करता हूं ( सिस्टमैनिक्स में कहा गया है )

• एक जटिल प्रणाली जो काम करती है वह हमेशा एक साधारण प्रणाली से विकसित होती है जो काम करती है।
• खरोंच से डिज़ाइन किया गया एक जटिल सिस्टम कभी काम नहीं करता है और इसे काम करने के लिए पैच नहीं किया जा सकता है। आपको काम की सरल प्रणाली के साथ शुरुआत करनी होगी।

इसलिए, एक जटिल प्रणाली लिखना शामिल है

• एक सरल प्रणाली लिखना
• यह सुनिश्चित करते हुए कि यह काम करता है

... यानी निम्नलिखित चरण:

1. थोड़ा कोड लिखें
2. यह सुनिश्चित करने के लिए परीक्षण करें कि यह काम करता है
3. थोड़ा और कोड लिखें
4. फिर से परीक्षण करें
5. आदि।

ध्यान दें कि चरण 3 में शामिल हो सकता है:

3. थोड़ा और कोड लिखें
   1. नए अतिरिक्त के लिए इसे तैयार करने के लिए रिफैक्टर मौजूदा कोड
   2. यह अभी भी काम करता है यह सुनिश्चित करने के लिए रीफैक्टरिंग का परीक्षण करें
   3. नई कार्यक्षमता जोड़ें

इसके अलावा, चरण 2 "यह सुनिश्चित करने के लिए परीक्षण करें कि क्या यह काम करता है" यदि यह नहीं है तो कुछ पुनर्लेखन को शामिल कर सकता है।

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

• स्रोत कोड सरल है
• और कोई नया बग पेश नहीं किया गया
• (और कुछ पुराने कीड़े समाप्त)

संयोग से, "यह सुनिश्चित करने के लिए परीक्षण करना कि यह काम करता है" जरूरी "इकाई परीक्षण" का मतलब नहीं है - जब टीम संरचना सरल है, तो आप एक (सरल) सिस्टम परीक्षण (सरल) सिस्टम परीक्षण (बजाय इकाई परीक्षण) का परीक्षण कर सकते हैं ।

Answer 10

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

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

उसे पेशाब कर दिया गया था, लेकिन 3 दिन बाद उसने प्रोग्राम खत्म कर दिया, जिसमें क्लीनर कोड और कम कीड़े और कोड की कम लाइनें थीं।

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

3 विकल्प हैं

• इसे हटाएं (पूरी तरह से, पीछे मुड़कर नहीं)
• पुराने डिजाइन में काम करना जारी रखें
• जाते समय रिफैक्टर कोड।

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

Comments

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

— जूजा oo ’

Answer 11

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

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

ऐसा करते समय, डिज़ाइन प्रक्रिया और योजना पर ध्यान केंद्रित करें, और अपने मौजूदा सामान पर ध्यान दें और उस चीज़ को प्रतिबिंबित करें जो आप बेहतर समझ रहे हैं।

Answer 12

Refactor। Refactor। Refactor! Refactor !!!!

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

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

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

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

हमेशा रिफ्लेक्टर करने के लिए कुछ होगा।

Answer 13

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

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

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

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

Answer 14

आपको खुद को नियोक्ता के जूते में रखना होगा।

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

एक अच्छी संस्करण प्रक्रिया, शाखाओं और टैग के साथ वह सब करें।

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

आप स्पष्ट रूप से इसे फिर से लिख सकते हैं, लेकिन फिर इसे एक और परियोजना बना सकते हैं।

Comments

कौन सा नियोक्ता? ओपी हाई स्कूल में है, एक पालतू प्रोजेक्ट कर रहा है।

— लाइट की दौड़ ऑर्बिट

शुरू से ही पेशेवर अभिनय करना बहुत बुरा नहीं हो सकता है, और हाई स्कूल एक वास्तविक नौकरी के अवसर IMHO से बहुत दूर नहीं है।

— स्टीव चामिलार्ड

"पेशेवर रूप से अभिनय" का आपके पास रिफ्लेक्टर है या नहीं, इससे कोई लेना-देना नहीं है।

— ऑर्बिट

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

— स्टीव चामिलार्ड

और यह उन समयों में से एक नहीं है।

— ऑर्बिट

Answer 15

बस मिश्रण में मेरे अतीत के कुछ अनुभव जोड़ने के लिए। मैं एक साल से अधिक समय से एक साइड प्रोजेक्ट पर काम कर रहा हूं, जब भी मुझे कुछ मिनट मिलते हैं। यह प्रोजेक्ट एक साधारण टेस्टेड से स्टैटिक क्लास में जाकर ऑब्जेक्ट ओरिएंटेड स्लिम लाइन डिजाइन के लिए तैयार किया गया था।

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

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

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

Answer 16

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

तो क्या आपका कोडबेस इतना खराब है कि आप एक जटिलता छत के पास हैं? यदि आपको लगता है कि यह है, तो आगे बढ़ने से पहले सफाई करने और सरल बनाने के लिए कुछ समय लें। यदि सफाई का सबसे आसान तरीका कुछ हिस्सों को फिर से लिखना है, तो यह ठीक है।

Answer 17

न तो? दोनों?

बाद में जारी रखें, मौजूदा डिज़ाइन को संशोधित करने और नई कार्यक्षमता को जोड़ने में कुछ समय बिताएं।

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

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

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

Answer 18

यदि आपका कोड मॉड्यूलर है, तो आपको बाकी के कोड को बुरी तरह से लिखे गए घटकों के आसपास खत्म करने में सक्षम होना चाहिए, फिर बाकी कोड को प्रभावित किए बिना बुरी तरह से लिखे गए घटकों को फिर से लिखें।

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

Answer 19

पहला सवाल आपको खुद से पूछना चाहिए कि "दोष कितना बुरा है?"

आपने वास्तव में क्या गलत किया?

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

---

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

यदि आप अपना आवेदन जल्द से जल्द जारी करते हैं, भले ही यह 100% न हो, कीड़े सभी को मानते हैं, तो आपको संस्करण 1.1 के लिए बग और अन्य सामान को ठीक करने का समय होने पर, दूसरों से FEEDBACK मिलता है । अन्य लोग आपको एप्लिकेशन को इतना बेहतर बनाने में मदद करने में सक्षम होंगे, और आपने कुछ ऐसा करने में समय बर्बाद किया होगा जो लोगों को नापसंद हो सकता है।

तो आपके मामले में, इसे वहां से बाहर निकालें, कुछ प्रतिक्रिया प्राप्त करें, और फिर आप सभी परिवर्तनों के साथ संस्करण 2.0 को संरचना कर सकते हैं, और जो दोष है उसे ठीक कर सकते हैं।

---

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

Answer 20

यह इस बात पर निर्भर करता है कि आपका कोड कितना गड़बड़ है।

• यदि आपने वास्तविक n00b त्रुटियां की हैं जो आपके कोड को अत्यधिक जटिल या क्रिया बनाती हैं, तो मैं उन हिस्सों को फिर से लिखने की सलाह दूंगा।

• यदि आपको लगता है कि आपके पास गंभीर कीड़े हैं जिन्हें आपको वैसे भी ठीक करना होगा, तो कुछ यूनिट परीक्षण लिखें जो यह जांच कर सकते हैं कि क्या आपने बग को ठीक किया है (... क्योंकि आप अभी तक प्रोग्राम लॉन्च नहीं कर सकते हैं)। बग्स को जल्दी ठीक करना बेहतर है, और बग्स को ठीक करना निश्चित रूप से बेहतर है जबकि आपको अभी भी याद है कि कोड क्या करता है।

• यदि आपको यह पसंद नहीं है कि विधियों को क्या कहा जाता है, या वे किस वर्ग से संबंधित हैं, या इस तरह की छोटी चीजें हैं, तो बस आईडीई का उपयोग करें। (याद रखें, यह C # है, कुछ जावास्क्रिप्ट, अजगर, पर्ल, php, आदि नहीं) जब आप ऐसे कोड पर काम कर रहे हैं जो प्रभावित घटक का उपयोग करता है, और आपके सिर में स्पष्ट चित्र है कि उस घटक को क्या करना चाहिए, आदि यदि आपका आईडीई इसे दर्द रहित बनाता है तो इसे फिर से रिफैक्ट करें।

अन्यथा, इसे काम करना और अगले प्रोजेक्ट पर अपने कौशल को सुधारना।

Answer 21

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

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

आप दुनिया में सभी सलाह के लिए पूछ सकते हैं, लेकिन आनुभविक रूप से एक परिकल्पना का परीक्षण करने जैसा कुछ नहीं है।

आपके प्रयोग के रूप में एक पुनर्लेखन को चुनने पर विचार करने के लिए कुछ कारण:

• मेरे अनुभव में, यह आमतौर पर अधिक मजेदार है। पेशेवर स्थितियों में अक्सर एक बड़े कारण को नहीं लिखा जाता है कि मज़ा एकमात्र कसौटी से दूर है। लेकिन आप कोडिंग के लिए अभी भी अपेक्षाकृत नए हैं, इसलिए मज़ा शायद एक बहुत ही महत्वपूर्ण मानदंड है, और अन्य कारकों का एक संकेतक भी है जो इस प्रारंभिक चरण में आपके लिए अमूर्त हो सकते हैं (मज़े से पता चलता है कि आप अधिक सीखेंगे, आदि)।
• आपका अनुभव और संभवतया अंतरात्मा की आवाज आपको बता रही है कि एक पुनर्लेखन एक विचार करने लायक है। एक है, तो उस आवाज को सुनो। यहां तक ​​कि अगर आप इसे सलाह का पालन नहीं करते हैं, तो कम से कम सुनें। भविष्य में और अधिक बाहरी आवाज़ें होंगी, और आपको अपने स्वयं के अच्छे ज्ञान को सुनने के लिए अभ्यास की आवश्यकता होगी।
• मुझे फिर से लिखने पर संदेह है, आप अपने कोड को और अधिक संशोधित करने की संभावना रखते हैं। जब आप मॉड्यूल बनाते हैं, तो आपके पास अधिक पुन: प्रयोज्य और विश्वसनीय घटक होते हैं जो आप अन्य परियोजनाओं के लिए लाभ उठा सकते हैं। आपको यह भी पता लग सकता है कि अंत में, जो आपके मुख्य प्रोजेक्ट के एक मात्र मॉड्यूल की तरह लग रहा था, वह आपके द्वारा लिखे गए कोड का सबसे दिलचस्प और मूल्यवान टुकड़ा निकला।

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