कोड लिखने के बाद, मुझे ऐसा क्यों लगता है कि "मैंने कुछ समय बाद बेहतर लिखा होगा"? [बन्द है]


12

मैं C ++ में अपने हॉबी प्रोजेक्ट पर 2 साल से अधिक समय से काम कर रहा हूं। जब भी मैं एक मॉड्यूल / फ़ंक्शन लिखता हूं, तो मैं इसे बहुत सोच समझकर कोड करता हूं। अब समस्या देखें,

do {
  --> write the code in module 'X' and test it
  --> ... forget for sometime ...
  --> revisit the same piece of code (due to some requirement)
  --> feel that "This isn't written nicely; could have been better"
} while(true);

यहां 'X'कोई भी मॉड्यूल है (यह छोटा / बड़ा / मध्यम हो)। मैं देख रहा हूं कि, कोडिंग करते समय मैंने कितना प्रयास किया, यह कोई बात नहीं है। इसलिए ज्यादातर, मैं खुद को एक कामकाजी कोड देखने से मना करता हूं। :)

क्या यह कई लोगों के लिए एक सामान्य भावना है? क्या यह भाषा विशिष्ट घटना है? (क्योंकि C ++ में एक ही चीज़ को अलग-अलग तरीके से लिख सकते हैं)।

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


14
मुझे अधिक चिंता होगी यदि मुझे अपने पुराने कोड के साथ कभी समस्या नहीं मिली। इससे पता चलता है कि आपके कौशल विकसित हो रहे हैं।
डेरेन यंग

1
यदि आप अपने पुराने कोड को देखते हैं और यह नहीं सोचते हैं कि "झकना, मैंने इसे इस तरह से वापस क्यों नहीं किया ?", तो आपने कोड लिखने के बाद से पर्याप्त नहीं सीखा है।
sbi

जवाबों:


17

यह घटना बहुत आम है और प्रोग्रामर के लिए विशिष्ट नहीं है। जब भी आप एक बौद्धिक कार्य करते हैं, तो आप उन दर्जनों स्थानों को नोटिस करेंगे जहाँ आप कुछ सुधार कर सकते थे - जब आपके पास कुछ दूरी थी। किसी भी बुद्धिमान (wo-) आदमी है जो कभी एक थीसिस लिखा पूछो, और वे आपको एक बात बता देगा: "। इस पर गौर नहीं करते आप करेंगे पहली नज़र पर एक त्रुटि पाते हैं।"

रिफ्लेक्टरिंग लूप से बचने के लिए मूल रूप से दो चीजें हैं:

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

इसे पढ़ें। en.wikipedia.org/wiki/Buyer_remorse बहुत मददगार।
एस.लॉट

3

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

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

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

संक्षेप में, यह मेरे अनुभव में एक सामान्य भावना है, लेकिन यह नकारात्मक नहीं है।


2

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


2

क्या यह कई लोगों के लिए एक सामान्य भावना है? क्या यह भाषा विशिष्ट घटना है?

इसका मतलब है कि आप अपने ज्ञान और विचारों का विस्तार कर रहे हैं।

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


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

1
@ डेविड वैलेस - अगर किसी को कभी भी पुराने कोड पर वापस नहीं जाना पड़ा, तो हम इसके बारे में ऐसा उपद्रव नहीं करेंगे।
जेएफओ

1
"एक बार जब आपका कोड काम करता है, तो आगे बढ़ें" - आपको विश्वास नहीं होगा कि मैंने उत्पादन कोड में किस तरह के कीड़े देखे, क्योंकि कोड ने काम किया;)
B

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

@VJovic - यदि उत्पादन में कीड़े थे, तो यह इसलिए है क्योंकि कोड DIDN'T काम नहीं करता है। मुझे लगता है कि ओपी कोड के बारे में बात कर रहा था जो सही ढंग से काम करता है, लेकिन बदसूरत है।
दाऊद इब्न करीम

2

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

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


2

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

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


1

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

यदि आपके पास यह भावना नहीं है, तो इसका मतलब दो चीजों में से एक है:

  1. आप अभी भी कौशल के समान स्तर पर हैं।
  2. आपका कोड पहले से ही परिपूर्ण (असंभावित) है।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.