त्वरित और गंदे प्रोग्रामर्स को कैसे पता चलेगा कि वे इसे सही कर रहे हैं?

Question

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

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

Comments

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

— जॉब

हालांकि, कुछ लोगों को लगता है कि शिपिंग सॉफ़्टवेयर के हित में जानबूझकर गंदे कोड की जांच करना कभी-कभी ठीक है, "बाद में इसे साफ करें" की योजना के साथ। हेह ... नरक इससे पहले कि " बाद में " जम जाएगा ...

— कार्लोस कैंपड्रेस

सभी प्रोग्रामर एक जैसे नहीं सोचते हैं - मुझे यह सुनिश्चित करने के लिए कोड दिया गया है कि महीनों तक मेरे लिए कोई मतलब नहीं था, एक दिन तक, यह एक प्रकाश स्विच की तरह था, फ़्लिप किया गया था, जैसा कि मुझे एहसास हुआ कि समग्र आयोजन संरचना क्या थी, और यह सब समझ में आया कि उन्होंने ऐसा क्यों किया था। क्या मैंने इसे इस तरह से किया होता? नहीं, लेकिन यह काम किया।

— जो

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

— जेम्स एंडरसन

How do quick & dirty programmers know they got it right?क्योंकि यह काम करता है :)

— राहेल

Answer 1

कोड शायद सही नहीं है।

हालाँकि, इससे कोई फर्क नहीं पड़ता।

त्वरित और गंदे हालात में जाने का सही तरीका हो सकता है:

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

कभी-कभी यह महत्वपूर्ण नहीं है कि कोड मजबूत है और हर कल्पनीय इनपुट को संभालता है। कभी-कभी इसे सिर्फ आपके पास मौजूद ज्ञात डेटा को संभालने की आवश्यकता होती है।

उस स्थिति में, यदि यूनिट परीक्षण आपको तेजी से लिखे गए कोड को प्राप्त करने में मदद करते हैं (यह मेरे लिए मामला है), तो उनका उपयोग करें। अन्यथा, जल्दी और गंदे कोड करें, काम पूरा करें। कीड़े जो ट्रिगर नहीं करते हैं कोई फर्क नहीं पड़ता। कीड़े आप ठीक करते हैं या चारों ओर काम करते हैं, कोई फर्क नहीं पड़ता।

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

Comments

+1 के लिए "विफलता का प्रभाव कम है।" मेरा पसंदीदा गणितीय जोखिम गणना जोखिम है = विफलता का वास्तविक परिणाम x विफलता की संभावित संभावना x विफलता का परिणाम माना जाता है (मेरे अनुभव में, कथित जोखिम वाले हिस्सेदार अक्सर फंस जाते हैं)

— Trav

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

— जॉय एडम्स

@ ट्राव तो, बस पुष्टि करने के लिए, यदि विफलता का वास्तविक परिणाम बड़े पैमाने पर है, लेकिन मेरी विफलता का कथित परिणाम शून्य है, कोई जोखिम नहीं है?

— ईसाई स्टीवर्ट

@ChristianStewart एक विशुद्ध गणितीय दृष्टिकोण से, आपका कथन सही होगा। हालांकि, व्यवहार में, परिणाम शून्य होने की धारणा संभावना x वास्तविक परिणाम के वजन को नकार नहीं पाएगी। धारणा को संगठनात्मक आशंकाओं को ध्यान में रखते हुए सूत्र में रखा गया है जो अक्सर शमन निर्णयों को प्रभावित करते हैं। इस तरह के डर की कमी वास्तविक संभावना या परिणामों को कम नहीं करती है। इस प्रकार, किसी को यह मानना ​​चाहिए कि धारणा हमेशा कम से कम 1 के बराबर होती है (क्योंकि यह किसी भी तरह से वास्तविक जोखिम को बढ़ा सकती है लेकिन नकारात्मक नहीं है)

— Trav

@Trav वैकल्पिक रूप से, एक नाम बदलें। अर्थात्, जोखिम को कथित जोखिम के लिए स्वैप किया जाना चाहिए , क्योंकि अगर हम मानते हैं कि विफलता के कोई परिणाम नहीं हैं, तो हम यह भी मानते हैं कि कोई जोखिम नहीं है।

— Delioth

Answer 2

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

Comments

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

— जॉनएफएक्स

हममें से कई लोग दुर्भाग्यपूर्ण स्थिति में हैं। यह अन्य लोगों के तकनीकी ऋण से वंचित किया जा रहा बहुत निराशाजनक है ।

— मार्क बूथ

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

— tp1

@ tp1: अच्छे प्रोग्रामर कोड लिख सकते हैं जो पढ़ने में आसान है। वे ऐसा किसी और को पढ़ने, और स्पष्ट होने वाली किसी भी चीज़ को स्पष्ट करके करते हैं। अभ्यास के साथ, वह भाग जो पहले पढ़ने पर अस्पष्ट है, सिकुड़ जाएगा।

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

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

— पेटर टॉर्क

Answer 3

ठीक है, डाउनवोट-बैट के पूर्ण होने के जोखिम पर, मैं विरोधी दृष्टिकोण को "शैतानों के वकील" के लिए जा रहा हूं।

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

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

मैंने कई बार इस बारे में अपने सहयोगियों से लड़ाई लड़ी है। वहाँ हमेशा एक और अधिक tweak, कुछ और है कि "होना चाहिए" इसके लिए "सही" होना चाहिए। आप हमेशा यह पा सकते हैं। कुछ बिंदु पर, वास्तविक दुनिया में, बस अच्छा पर्याप्त होना चाहिए। कोई वास्तविक दुनिया, वास्तविक, शिपिंग सॉफ्टवेयर एकदम सही नहीं है। कोई नहीं। सबसे अच्छा, यह काफी अच्छा है।

Comments

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

— बेकार

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

— जियोर्जियो

+1 - वास्तविक दुनिया में कोड गुणवत्ता और बैठक की समय सीमा के बीच हमेशा एक व्यापार होगा। मेरे पास एक प्रोग्रामर होगा जो एक पूर्णतावादी की तुलना में जल्दी से उचित कोड का उत्पादन कर सकता है जो महीनों तक इस बात पर व्यंग्य करता है कि क्या उसे एक विधि "सीरियलाइज़" या "राइटटॉयफाइल" कहनी चाहिए।

— जेम्स एंडरसन

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

— jwenting

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

— थॉमसएक्स

Answer 4

ऐसे प्रोग्रामर लगभग कभी नहीं जानते कि वे इसे सही मानते हैं , केवल ऐसा मानते हैं। और अंतर को समझना आसान नहीं हो सकता है।

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

जिस व्यक्ति के पास इस अनुभव की कमी है, उसके लिए अंतर स्पष्ट करना असंभव है। इसलिए वे जीवन भर कोड-एंड-प्रेयर मोड में विकसित होते चले जा सकते हैं, परोपकारी (और अज्ञानतावश) यह विश्वास करते हुए कि वे परिस्थितियों को देखते हुए अपना सर्वश्रेष्ठ प्रदर्शन कर रहे हैं।

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

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

Comments

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

— स्टीव जैक्सन

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

— लेगा

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

— स्टीफन ग्रॉस

डोनाल्ड नथ: "उपरोक्त कोड में बग से सावधान रहें; मैंने इसे केवल सही साबित किया है, इसे आजमाया नहीं है।" haacked.com/archive/2007/11/29/…

— MarkJ

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

— स्टीव 314

Answer 5

इकाई परीक्षण । किसी भी कोड में आत्मविश्वास रखने का एकमात्र तरीका है (गंदा या नहीं)।

एक और बात;

शॉर्ट कट लंबे देरी (पिपिन) के लिए बनाते हैं

Comments

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

— डैनियल रोसमैन

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

— कोडर

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

— मिस्टर स्मिथ

जब हम उद्धृत कर रहे हैं, तो आप यह भी पसंद कर सकते हैं "परीक्षण उपस्थिति को दर्शाता है, बग की अनुपस्थिति को नहीं दिखाता है" - एद्स्गर दिक्स्ट्रा

— टिमोथी जोन्स

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

— बिल K

Answer 6

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

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

Comments

+1 यह इंगित करने के लिए कि गुणवत्ता के उपायों के बारे में निर्णय व्यावसायिक आवश्यकताओं के द्वारा उचित हैं।

— स्टीफन ग्रॉस

+1 के लिए "" विकसित किया जाने वाला कौशल एक समझ है कि किसी विशेष परियोजना के लिए 'पूर्णता' के किस स्तर का उपयोग करने की आवश्यकता है। "... आपकी कंपनी को लगता है कि" ट्वीकिंग "कितना स्वीकार्य होगा इसके लिए एक न्यूनतम मानक निर्धारित करें। गुणवत्ता के मामले में जोखिम, फिर उससे चिपके रहते हैं।

— S.Robins

Answer 7

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

उदाहरण के लिए, हो सकता है कि आपके पास नियमित अभिव्यक्तियों के कुछ गुप्त हैक हों और किसी तीसरे पक्ष से आने वाली कुछ फ़ाइलों को पार्स करने के लिए बाइट ऑफ़सेट हों। और मान लें कि आपके पास एक परीक्षण है जो कह रहा है कि आप पार्सिंग उदाहरण फ़ाइलों से बाहर निकलते हैं जो आप उम्मीद करते हैं। आप इसे साफ कर सकते हैं ताकि आप कर सकें ... मुझे नहीं पता, किसी तीसरे पक्ष द्वारा फ़ाइल प्रारूप में बदलाव किए जाने पर अधिक तेज़ी से प्रतिक्रिया करें? यह अक्सर पर्याप्त नहीं होता है। अधिक संभावना है कि वे पूरी तरह से नए एपीआई में बदल जाएंगे और आप पुराने पार्सर को फेंक देंगे और नए में वही प्लग इन करेंगे जो उसी एपीआई और वॉयला के अनुरूप हो, आपका काम हो गया।

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

Comments

दूसरे शब्दों में कहने के लिए - मॉड्यूल क्यू एंड डी हो सकते हैं, लेकिन वास्तुकला ठीक से साफ होना चाहिए।

— क्रॉमास्टर

Answer 8

यहाँ एक त्वरित और गंदे प्रोग्रामर के बारे में कहानी है जो मुझे पता है।

मुझे पता है कि एक व्यक्ति जो इकाई परीक्षणों को समय की बर्बादी मानता है। बहुत तर्क के बाद, उन्होंने आखिरकार एक लिखा। इसमें एक लंबी विधि शामिल थी जिसे && और || और जोर लगाने के लिए एक बूलियन लौटा। स्टेटमेंट 20 लाइनों का है। फिर, उन्होंने एक वर्ग लिखा, जहां हर पद्धति में एक पंक्ति थी और मुख्य एक में 1000 से अधिक लाइनें थीं जिनमें कोई व्हाट्सएप नहीं था। यह पाठ की एक दीवार थी। जब मैंने उनके कोड की समीक्षा की और कुछ नई लाइनें डालीं, तो उन्होंने 'क्यों' पूछा। मैंने कहा 'पठनीयता के कारण'। उसने उन्हें हटा दिया और हटा दिया। उन्होंने शीर्ष पर एक टिप्पणी रखी "इसे मत छुओ, यह काम करता है!"

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

इसके अलावा, वह सोचता है कि प्रोग्रामिंग किताबें और ब्लॉग पढ़ना बेकार है। वह कहते हैं, 'बस प्रोग्रामिंग शुरू करो'। उन्होंने ऐसा 12 साल तक किया और उन्हें लगता है कि वह एक उत्कृष्ट प्रोग्रामर हैं। / facepalm

---

यहाँ कुछ और है।

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

Comments

+1। किसी कारण से मुझे वे कहानियाँ पढ़ना बहुत अच्छा लगता है। वे मुझे दुखी या नाराज भी नहीं करते।

— सैम होसेवर

-1 किसी भी प्रकार के _______Manager वर्ग को लिखने के लिए।

— ब्रायन ड्रिस्कॉल

@SamHocevar रन, thedailywtf.com तक न चलें

— Mawg

Answer 9

त्वरित और गंदे से बचने में मेरा सबक तब था जब मेरे पास एक महीने का काम होने के लिए अनुमानित (कम अनुमानित) देने के लिए छह महीने का समय था। मैंने काम शुरू करने से पहले अनुसंधान विधियों का फैसला किया। अंत में मैंने तीन महीने का शोध किया और शेष तीन महीनों में वितरित करने में सक्षम था।

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

एक डेवलपर ने एक जवाब दिया जब मैंने उसे लाइब्रेरी कोड का उपयोग करने के लिए कहा: "क्या वह धोखा नहीं है? मुझे स्कूल में अपना सारा कोड लिखना था।"

Comments

काफी नैतिक डेवलपर है जो आपको मिल गया है!

— स्टीफन ग्रॉस

Answer 10

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

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

Answer 11

उत्पाद जहाज।

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

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

Answer 12

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

मैं व्यक्तिगत रूप से "गंदा कोड लिखने" और इसकी शुद्धता के बारे में आश्वस्त होने के कौशल को विकसित करने का लक्ष्य नहीं रखूंगा। मैं बल्कि पहली बार उचित कोड लिखूंगा।

Answer 13

वे कैसे जानते हैं कि वे इसे सही समझे हैं? परीक्षण सरल उत्तर है।

यदि उनके कोड को एक अच्छी क्यूए टीम द्वारा पूरी तरह से परीक्षण किया गया है और यह पास हो जाता है, तो मैं कहूंगा कि उन्होंने इसे सही पाया।

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

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

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

बेशक यह छवि प्रदर्शित करती है कि किसी को भी त्वरित और गंदे कोड के खतरे को कम नहीं करना चाहिए!

Answer 14

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

Comments

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

— कैफ़ीक्यूक

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

— Raku

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

— S.Robins

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

— वॉरेन पी

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

— रक्कू

Answer 15

मेरे विचार से, प्रश्नोत्तर संहिता को शुद्धता के लिए सीखना कौशल विकसित करने के लायक नहीं है क्योंकि यह सिर्फ बुरा व्यवहार है। यहाँ पर क्यों:

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

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

Answer 16

अगर यह बहुत गंदा है तो मैं यह नहीं बता सकता कि मेरा नया कोड सही है या नहीं।

"डर्टी" का मतलब अलग-अलग लोगों के लिए अलग-अलग चीजें हैं। मेरे लिए, इसका मतलब ज्यादातर उन चीजों पर निर्भर होता है जो आप जानते हैं कि आपको शायद भरोसा नहीं करना चाहिए, लेकिन जिसे आप जानते हैं कि आप निकट अवधि में काम करने की उम्मीद कर सकते हैं। उदाहरण: यह मानते हुए कि ऊंचाई की गणना करने के बजाय एक बटन 20 पिक्सेल ऊंचा है; एक नाम को हल करने के बजाय एक आईपी पते को हार्ड कोडिंग; एक सरणी पर गिने जाने के लिए क्योंकि आपको पता है कि यह है, भले ही विधि जो सरणी प्रदान करती है वह इसकी गारंटी नहीं देती है।

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

Answer 17

थोड़ा विवादास्पद लगने के जोखिम पर, मेरा तर्क है कि कोई भी वास्तव में नहीं जानता है कि उनका कोड 100% सही है और त्रुटि के बिना 100% है। यहां तक ​​कि जब आपके पास वास्तव में अच्छा परीक्षण कवरेज है और आप सख्ती से अच्छे बीडीडी / टीडीडी प्रथाओं को लागू कर रहे हैं, तो आप अभी भी कोड विकसित कर सकते हैं जिसमें त्रुटियां हैं, और हां जिसमें दुष्प्रभाव भी हो सकते हैं!

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

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

Answer 18

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

Answer 19

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

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

Comments

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

— जे ट्राना

Answer 20

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

1) "स्टिच" से भरे कोड पर काम करते हुए प्रोजेक्ट बड़ा होता है और टीम मोटिवेशन कम होता है। उस स्थिति में परियोजना अराजकता की ओर तेजी से बढ़ने की संभावना होगी।

2-) परियोजना एक गैर-इष्टतम समाधान के रूप में जानी जाती है और इसका उपयोग नए समाधान के पक्ष में या नए समाधान के रूप में महंगा होने वाले रिफलेक्टर के रूप में हतोत्साहित होने लगता है।

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

Answer 21

वरिष्ठ के साथ चर्चा करें और यदि कोई हो तो विफलताओं के प्रभाव का आकलन करें। उदाहरण के लिए ऐसी स्थिति जहां आप गंदे को ठीक कर सकते हैं 1 दिन और एक मजबूत कोड के लिए डिज़ाइन और वास्तु परिवर्तन की आवश्यकता होती है, जो डिज़ाइन परिवर्तन से प्रभावित सभी वर्कफ़्लो को पूरी तरह से मान्य करने में 4-6 महीने + अतिरिक्त सत्यापन समय लग सकता है।

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

स्वच्छ कोड पहला और सबसे महत्वपूर्ण तरीका है, जहां वृद्धि को बचाने के लिए गंदे कोड के रूप में, ग्राहकों के जाने / न जाने के फैसले, स्टॉपर्स, संगठन की प्रतिष्ठा को दांव पर लगाते हैं और कई और जहां गंदे कोड इसे साफ कोड में शामिल करते हैं।

Comments

इससे पहले किए गए 23 से अधिक अंकों के बारे में कुछ भी स्पष्ट नहीं लगता है और पहले के 23 उत्तरों में समझाया गया है

— gnat