हर साल कम चूसने? [बन्द है]


10

हर साल कम चूसने -जेफ एटवुड

मैं इस व्यावहारिक लेख पर आया था। पोस्ट से सीधे

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

  1. आपके साथ ऐसा कितनी बार होता है या नहीं होता है?
  2. अपनी कोडिंग में वास्तविक सुधार देखने से पहले कब तक? महीना वर्ष?
  3. क्या आपने कभी अपने पुराने कोड का पुनरीक्षण किया है ?
  4. आपका पुराना कोड आपको कितनी बार प्लेग करता है? या आपको अपने तकनीकी ऋण से कितनी बार निपटना है।

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

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

  • क्या ऐसा होता है?
  • यदि ऐसा है तो किसी विशेष भाषा पर कोडिंग करने में कितने साल लगते हैं?

सम्बंधित:

कभी अपने पुराने कोड और दर्द में घबराहट को देखते हैं?

स्टार वार्स पल "ल्यूक! मैं आपका कोड हूँ!" "नहीं! असंभव! यह नहीं हो सकता!"


3
IMHO लोग जो सोचते हैं कि वे परिपूर्ण हैं और सोचते हैं कि उन्हें सुधार करने की आवश्यकता नहीं है, सही हैं। वे सुधार नहीं कर सकते । कोई भी समझदार व्यक्ति जानता है कि वे कभी भी परिपूर्ण नहीं हो सकते हैं, हमेशा सुधार / नया सामान सीखने के लिए जगह है। अगर मुझे पता चला कि मैं खुद को बेहतर नहीं कर सकता, तो मुझे बहुत डर लगेगा - मुझे नहीं लगता कि मेरे पास छत है।
MAK

मुझे उन परियोजनाओं पर वापस जाना पसंद है जिन्हें मैंने तब बनाया था जब मैं बहुत नया था, और उस कोड को देखना जो मेरे लिए लिखना बहुत मुश्किल था। कई बार कोड सरल है। यह मुझे चकित करता है।
मफिन मैन

जवाबों:


6
  > Sucking Less Every Year ?

नहीं, लेकिन हर साल अलग चूसने :-)

कई साल पहले मेरी पहली समीक्षा के बाद मुझे लापता नामकरण-सम्मेलनों का सामना करना पड़ा।

तब मुझे लगा कि मेरे कोडेड (अनावश्यक) को यथासंभव सामान्य रूप से लागू किया गया था, लेकिन इससे कोड को समझने और बनाए रखने में अंतर हो गया।

तब मैंने टेस्टड्रीवन विकास, इनवर्टेशनऑफकंट्रोल, डॉट नेट जेनरिक कहां और कई और अधिक जानकारी प्राप्त की।

निष्कर्ष

पुराने ख़राब हाबीज़ डिक्रिप्ट की पीड़ा, लेकिन मुझे मिली नई पीड़ाओं की भरपाई इसलिए हुई क्योंकि मैंने और सीखा।


19

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

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


2
मैं 100% सहमत हूं। वे मूक हत्यारे हैं! ओह और भयानक उपयोगकर्ता नाम, xkcd? :)
जेमीबारो

@ जैमीब्रो: बिल्कुल। :)
बॉबी टेबल्स

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

13

निम्नलिखित बिंदु सलाह नहीं हैं, लेकिन एक व्यक्तिगत लॉग हैं:

  • कम वैश्विक चर का उपयोग करना
  • चर या फ़ंक्शन नामों के लिए संक्षिप्त नाम का उपयोग न करें
  • [कुछ] परीक्षण कोड लिखें
  • बेंचमार्किंग के बिना कोड को धीमे (या तेज) के रूप में न देखें
  • एप्लिकेशन को लोड करने का तरीका जानें
  • इसे ठीक न करें, अगर यह टूटा नहीं है
  • स्रोत कोड प्रबंधन टूल का उपयोग करें (git / hg)
  • रीफैक्टरिंग शांत है, इसे लाने की लागत का परीक्षण न करें
  • सुरक्षा कठिन है, इसलिए जल्द से जल्द इससे सावधान रहें
  • कुछ ओपन सोर्स प्रोजेक्ट बग्स पैच करें
  • ब्लॉग कुछ नया
  • प्रयोज्य एक सुविधा अनुरोध नहीं हो सकता है, लेकिन यह महत्वपूर्ण है

मैंने एक साल के भीतर सब नहीं सीखा, सब कुछ समय लगता है ...


मुझे पसंद है कि आप कैसे "लिख [कुछ] परीक्षण कोड" का उल्लेख करते हैं। मेरा मानना ​​है कि कोई भी कभी भी पूर्णता तक नहीं पहुंचता है जहां वे प्रोग्रामर के रूप में कभी गलती नहीं करेंगे - हम सभी मानव हैं, और हम समय-समय पर गलतियां करते हैं। यूनिट परीक्षण और एकीकरण परीक्षण हमारी गलतियों को कम कर सकते हैं। और मुझे लगता है कि आप 'कुछ' परीक्षण कहते हैं, जो महत्वपूर्ण है, क्योंकि कभी-कभी मैंने ऐसे लेखन परीक्षण किए हैं जो वास्तव में उपयोगी नहीं थे।
जेमीबारो

वास्तव में, मुझे लगता है कि "इसे ठीक न करें, अगर यह टूट नहीं गया है" तो मैं "जोड़
दूंगा

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

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

4

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

मुझे पता है कि कोई भी प्रोग्रामर अपने सॉफ्टवेयर के टुकड़े पर गर्व नहीं करता है, लेकिन यह अच्छा है। थन का मतलब है कि प्रोग्रामर ने प्रक्रिया में सीखा है।

यदि आप "क्लीन कोड" पुस्तक पढ़ते हैं तो आप कई बार अपना खुद का कोड "चूसना कारक" बढ़ाएंगे। : डी


1
मैं एक बिंदु पर आपसे असहमत हूं, मेरा मानना ​​है कि कुछ कोड आप पर गर्व कर सकते हैं। विडंबना यह है कि आप एक परियोजना को बहुत अच्छी तरह से कर सकते हैं, और इस पर गर्व कर सकते हैं, शायद कुछ कम झुंझलाहट के साथ। फिर अगली परियोजना, प्रति घंटे आपके डब्ल्यूटीएफ उच्च हैं ... आपके अपने कोड के लिए! : डी
जेमीबारो

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

स्वच्छ कोड के लिए +1 हालांकि इसकी तुलना हमेशा आपके स्वयं के साथ होती है।
आदित्य पी

4

मेरे पास वास्तव में इसके लिए सिक्के के दोनों पहलू हैं।

एक ओर, आप पुराने कोड को देखते हैं और आप देखते हैं कि यह बग्स से भरा हुआ है और उन चीजों के जटिल तरीके हैं जो केवल तकनीक और भाषा सुविधाओं का लाभ उठाते हैं जिन्हें आप तब वापस नहीं जानते थे।

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

और फिर आप कुछ लाइनों को नीचे स्क्रॉल करते हैं और भयावहता से घबराते हैं, इस तथ्य पर कि आपने C में GOTO का उपयोग किया है।


3

हम्म ... मैं अक्सर काफी सुखद आश्चर्यचकित हूं कि मेरा पुराना कोड कितना अच्छा है।

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


3
  1. आपके साथ ऐसा कितनी बार होता है या नहीं होता है?

  2. अपने कोडिंग में वास्तविक सुधार देखने से पहले कब तक? महीना वर्ष?

  3. क्या आपने कभी अपने पुराने कोड का पुनरीक्षण किया है?

  4. आपका पुराना कोड आपको कितनी बार प्लेग करता है? या आपको अपने तकनीकी ऋण से कितनी बार निपटना है।

  1. हर बार मैं कुछ नया सीखता हूं, उम्मीद है कि यह हर रोज हो।

  2. अगर मैंने जो सीखा है, उसे लागू करने के लिए तैयार हूं, तो जब मैं इसे लागू करता हूं, तो यह तत्काल होता है।

  3. हां, केवल (1) नई सुविधाओं के लिए, (2) बग फिक्स, (3) नॉस्टेल्जिया, (4) देखें कि मैंने कैसे कुछ हल किया, उपयोगी हो सकता है।

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


3

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

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

तो हाँ, व्यवहार में, मेरे द्वारा लिखा गया प्रत्येक कोड एक वर्ष में मेरे दृष्टिकोण से असहनीय हो जाता है। और मैं फेंक-दूर कोड के बारे में बात नहीं कर रहा हूं, लेकिन उस कोड के बारे में भी जो मैंने गुणवत्ता, रखरखाव और पठनीयता को ध्यान में रखते हुए लिखा है। फिलहाल, कोई अपवाद नहीं था।

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

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

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

जब कोई व्यक्ति कहता है कि वह इतना परिपूर्ण है कि उसे कुछ भी सीखने की आवश्यकता नहीं है, तो इसका मतलब है कि वह यह समझने में भी सक्षम नहीं है कि वह कितना गूंगा है।

यहां तक ​​कि अगर आपके पास कंप्यूटर / प्रोग्रामिंग में बीस साल का अनुभव है, तो चीजें बहुत तेजी से बदलती हैं, इसलिए कोड को बेहतर बनाने के लिए हमेशा नई चीजें सीखने और नई तकनीकें हैं। उदाहरण के लिए, जब कोई .NET फ्रेमवर्क 3.0 था, तब लिखा गया C # कोड बहुत संभवतया हमारे द्वारा आज की गई नई चीज़ों (लिनक, कॉन्ट्रैक्ट कॉन्ट्रैक्ट्स आदि) के साथ अधिक पठनीय और बेहतर बनाया जा सकता है, और यह, भले ही पुराना कोड हो सबसे चतुर डेवलपर द्वारा लिखा गया था।


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

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

1

यह काफी नियमित रूप से होता है जब मैं कोड देख रहा हूं और सोच रहा हूं, "जब मैंने यह लिखा था तो मैं क्या सोच रहा था?"

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

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

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

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


1

1. अक्सर ऐसा कैसे होता है या आपके साथ नहीं होता है?

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

2. कब तक आप अपने कोडिंग में एक वास्तविक सुधार देखते हैं? महीना वर्ष?

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

3.क्या आपने कभी अपने पुराने कोड को फिर से देखा है?

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

4. कैसे अक्सर अपने पुराने कोड आप प्लेग? या आपको अपने तकनीकी ऋण से कितनी बार निपटना है।

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


सफेद धोने = फिर से कारक? क्या आप किसी प्रोजेक्ट कोड या अपने व्यक्तिगत कोड आधार की बात कर रहे हैं।
आदित्य पी।

1
@ AdityaGameProgrammer: व्हाइट वॉश = इसे सब बाहर टॉस करें और शुरुआत से इसे फिर से लिखें। मैं अपने व्यक्तिगत कोड के बारे में बात कर रहा हूँ।
स्टीवन एवर्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.