"बाद में इसे ठीक करने" की बुरी आदत पर काबू पाने

Question

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

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

तो अंत में, मैं एक बड़े मुख्य समारोह, एक वर्ग और कुछ सहायक कार्यों के साथ एक कार्यक्रम के साथ अटक गया हूं। कहने की जरूरत नहीं है, यह बहुत पुन: प्रयोज्य नहीं है।

किसी को भी एक ही समस्या थी और कोई सुझाव इस पर काबू पाने के लिए है है? एक बात जो मुझे दिमाग में थी वह मुख्य कार्य को pseduocode के साथ लिखना था (बिना विस्तार के लेकिन पर्याप्त वस्तुओं और कार्यों को देखने के लिए पर्याप्त)। अनिवार्य रूप से एक शीर्ष-नीचे दृष्टिकोण।

क्या यह एक अच्छा विचार है? कोई अन्य सुझाव?

Answer 1

"सबसे पहले हम हमारी आदतों बनाने, तो वे हमें बनाते हैं।"

यह दोनों अच्छी और बुरी आदतों के लिए आवेदन करने लगता है। एक बुरे की तरह लगता है कि आप को पकड़ लिया है।

जब तक मैं चीजें करता हूं, तब तक अधिक मॉड्यूलर ऊपर तक अभ्यास करना।

Answer 2

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

Answer 3

मुझे लगता है कि टीडीडी रेड-ग्रीन-रिफैक्टर अनुशासन अद्भुत काम करता है।

Answer 4

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

Answer 5

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

मेरे दृष्टिकोण ऊपर से नीचे है। मैं

while(obj = get_next_obj(data)) { 
    wibble(obj); 
    fumble(obj); 
    process(filter(obj)); 
} 

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

इस तरह से मैं भी एल्गोरिदम टिप्पणी करने के लिए से बचने: फ़ंक्शन नाम पर्याप्त स्पष्टीकरण कर रहे हैं।

Answer 6

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

OOP के संबंध में सोचें और के रूप में जल्दी के रूप में यह समझ में आता है refactor। सब कुछ बनने के बाद इसे करने से बहुत सस्ता है।

Answer 7

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

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

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

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

Answer 8

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

Answer 9

आपका दृष्टिकोण जरूरी बुरा नहीं है - पहले अधिक से अधिक मॉड्यूलर डिजाइन इंजीनियरिंग के रूप में खत्म हो सकता है।

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

चाल जल्द ही refactor करने के लिए है, लेकिन नहीं बहुत जल्दी। और अक्सर, लेकिन अक्सर नहीं। कितनी जल्दी और कितनी बार? यही कारण है कि यह एक कला और नहीं एक विज्ञान :)