क्या आधुनिक सॉफ्टवेयर विकास में अच्छा कोड असंभव है? [बन्द है]


19

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

मेरा प्रश्न निम्नलिखित है: ध्यान में रखते हुए हमारे पास अधिक शक्तिशाली भाषा और उपकरण हैं।

  • अच्छा कोड लिखना अधिक कठिन क्यों है?
  • क्या कारक, समय और जटिलता इसके लिए योगदान करते हैं?
  • क्या कार्यप्रणाली सही तरीके से प्रचलित नहीं है?

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

जवाबों:


34

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

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

अच्छा कोड लिखना कठिन क्यों है?

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

क्या यह केवल उल्लेख कारकों, समय और जटिलता के कारण है?

हां, हमारे उपकरणों की शक्ति बढ़ने के साथ साध्य जटिलता निश्चित रूप से बढ़ी है (और बढ़ रही है)। दूसरे शब्दों में, हम सीमाओं को आगे बढ़ाते हैं। मेरे लिए जो अनुवाद करता है ताकि आज की सबसे बड़ी चुनौतियों को हल करना उतना ही कठिन हो जितना 30 साल पहले उस दिन की सबसे बड़ी चुनौतियों को हल करना था।

OTOH के बाद से क्षेत्र इतना बड़ा हो गया है, वहाँ और अधिक "छोटी" या "ज्ञात" समस्याएं हैं जो 30 साल पहले थी। ये समस्याएँ तकनीकी रूप से (होनी चाहिए) अब एक चुनौती नहीं हैं, लेकिन ... यहाँ उपरोक्त कहावत है :-(

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

क्या यह है कि कार्यप्रणाली सही तरीके से प्रचलित नहीं है?

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


2
व्याकरण नाज़ी या कुछ भी नहीं लेकिन 'अवास्तविक' (दूसरे पैराग्राफ में) एक शब्द नहीं है। मुझे लगता है कि आपका मतलब 'अवास्तविक' है।

मैं केवल "जूनियर" मुद्दे का समर्थन कर सकता हूं। मैं उनमें से एक हूं और मैं निश्चित रूप से चाहता हूं कि मेरी मदद करने के लिए मेरे पास एक संरक्षक था। यह शुक्र है कि इंटरनेट आज है, और अमेज़ॅन और एसओ मदद करते हैं, लेकिन फिर भी ...
मैथ्यू एम।

1
+1: नोट के अलावा, उपकरण / प्रौद्योगिकियों / कार्यप्रणाली में तेजी से परिवर्तन और विकास के कारण, एक निश्चित सीमा तक हम सभी जूनियर कम से कम एक वर्ष में दो बार होते हैं। अनुभव बस कुछ घूंटों को कुछ जारों की तुलना में अधिक तेजी से उठने की अनुमति देता है।
स्टीवन एवर्स

मैं इस प्रश्न को गंभीरता से लेने से इनकार करता हूं जब तक कि हमारे पास सुंदर कोड को बदसूरत से अलग करने के लिए कोई औपचारिक नियम नहीं हैं।
शबून

17

अवास्तविक समय सीमा के तहत कोडिंग और तकनीकी ऋण से निपटने के मुद्दों को वेनबर्ग '71 और ब्रूक्स '72 के बाद से जाना जाता है। इससे पहले कि ऑनलाइन खुदाई करना कठिन हो जाता है, लेकिन मुझे यकीन है कि पुरानी सीडीसी, आईबीएम और नासा रिपोर्ट एक ही बात कह रहे हैं।


1
+ "तकनीकी ऋण" और संदर्भों के लिए।
आमिर रज़ाई

10

मुझे लगता है कि "गुड कोड" के लिए हम सभी के अपने विचार और सीमाएं हैं। हालाँकि, ऐसे कई मुद्दे हैं जो सभी योगदान करते हैं:

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

अंत में, मुझे लगता है कि "अच्छा" या "सर्वश्रेष्ठ" का पीछा करना बेहतर है। अगर हमने वहां सबसे अच्छा कोड देखा, तो क्या हम इसे इस तरह से पहचानेंगे?


1
+1 अच्छी बात। "अच्छे कोड" से मैंने सही कोड का संदर्भ नहीं दिया। सही कोड मौजूद नहीं है। "अच्छा कोड" एक ऐसा कोड है जो आपको सिरदर्द नहीं देता है, यह उदाहरण के लिए अच्छी तरह से सोचा गया है।
आमिर रज़ाई २11'११

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

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

8

अच्छा कोड लिखना कठिन क्यों है?

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


+1 बहुत अच्छा बिंदु, नए उपकरण उत्पादकता को बढ़ाते हैं जिससे अधिक जटिलता हो सकती है।
आमिर रज़ाई 20

1
+1। जिसे "लॉकी एब्स्ट्रक्शन का कानून" के रूप में भी जाना जाता है। :)
बॉबी टेबल्स

6

क्या आधुनिक सॉफ्टवेयर विकास में अच्छा कोड असंभव है?

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

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

हमने ऐसा किया है, हमने जटिलता की समस्या को हल कर दिया है, लेकिन इससे बड़ी समस्या को हमने पहले नहीं हटाया है।

हमें संभालना अभी भी बहुत जटिल है।

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

हम कभी ऐसा नहीं कर पाएंगे।

और अगर हम नहीं कर सकते हैं हम गुणवत्ता कोड का उत्पादन कभी नहीं करेंगे।

प्रबंधक मॉड्यूल की चापलूसी देखेंगे, लेकिन प्रति मॉड्यूल आंतरिक मुद्दों और सीमाओं को नहीं जान पाएंगे।

मॉड्यूल प्रोग्रामर स्थानीय सीमाओं को जानेंगे लेकिन बड़ी तस्वीर के संदर्भ में इसका अनुकूलन नहीं कर पाएंगे।

प्रबंधकों और प्रोग्रामर (और प्रोग्रामर के बीच भी) के बीच समझ को संप्रेषित करने का कोई तरीका नहीं है। और यहां तक ​​कि अगर वहाँ थे, मानव मस्तिष्क की क्षमता को संभाल नहीं सका।

हम कोशिश करते रहें (एक निरर्थक व्यायाम) को छोड़कर बहुत कम है। चलो कोड को कम या ज्यादा चालू रखें और जीवन का आनंद लें।


मुझे यह उत्तर पसंद है, यदि केवल इस तरह के निराशावादी, घातक स्वर में नहीं लिखा गया होता ...
तिमवी

1
@ टिमवी: निराशावादी नहीं। आपको बोझ से राहत दिलाने वाला था। :)

4

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

मैं किसी विशेष विक्रेता को चुनना नहीं चाहता, लेकिन विंडोज 1.0 से विंडोज 7 की तुलना करें। बाद वाले में हजारों गुना अधिक कोड है, लेकिन क्रैश के बीच का समय सौ गुना बढ़ गया है। हमें विंडोज 3.1 के बाद से एक वर्ड दस्तावेज़ में एक्सेल स्प्रेडशीट को एम्बेड करने में सक्षम होना चाहिए था, लेकिन इन दिनों यह वास्तव में कम या ज्यादा काम करता है।

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


घृणित विषय पर जाने से नफरत है, लेकिन व्यक्तिगत रूप से मैं तर्क दूंगा कि विंडोज 1.0 से 3.11 वास्तव में बहुत स्थिर थे, उनकी जटिलता की कमी के कारण। विंडोज के सबसे क्रैश संस्करण 95, 98 और एमई थे। बेशक, कौन से संस्करण अन्य तरीकों से "अच्छे" थे, यह अलग बात है।
तिमवी

कम-पावर सिस्टम के बजाय मिनीकंप्यूटर या मेनफ्रेम पर कोडिंग के बारे में क्या? आपके द्वारा संदर्भित मुद्दे Intel 8086 मॉडल से संबंधित हैं ...
पॉल नाथन

@ पाओल, 8086 की समस्याएं वे थीं जिनसे मैं सबसे अधिक जुड़ा था, इसलिए वे मेरे दिमाग में बहुत बड़े थे। हालाँकि मेनफ़्रेम पर भी सॉफ्टवेयर लिखने के उपकरण आधुनिक मानकों द्वारा आश्चर्यजनक रूप से क्रूड थे। संपादकों आमतौर पर edlin के करीब थे क्योंकि वे emacs थे। 1982 के अंत में मैं आईबीएम हार्डवेयर पर NUROS (नेब्रास्का यूनिवर्सिटी रिमोट ऑपरेटिंग सिस्टम) का उपयोग कर रहा था। जॉब्स को प्रोग्राम किया गया और 'वर्चुअल' पंच कार्ड का उपयोग करके चलाया गया। और हमें Y2K कीड़े को नहीं भूलना चाहिए, ज्यादातर भंडारण पर कथित बाधाओं द्वारा बड़े लोहे पर निर्भर होता है।
चार्ल्स ई। ग्रांट

2

आधुनिक अनुप्रयोग 20-30 साल पहले की तुलना में अधिक जटिल हैं , क्योंकि उनका पर्यावरण समृद्ध और अधिक बहुमुखी है।

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

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

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

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


+1 "आधुनिक अनुप्रयोग 20-30 साल पहले की तुलना में अधिक जटिल हैं"
अमीर रेजाई

2

यह मुझे लगता है कि उपलब्ध प्रोसेसर की गति, मेमोरी, डिस्क और प्रोग्रामर समय को भरने के लिए सॉफ़्टवेयर का विस्तार हुआ है। कोई कह सकता है कि ऐसा इसलिए है क्योंकि सॉफ्टवेयर बहुत कुछ पूरा करता है। खैर, मुझे यकीन है कि यह बहुत कुछ पूरा करता है, लेकिन इस ब्लोट को सही ठहराने के लिए पर्याप्त नहीं है।

मुझे लगता है कि याद रखने लायक विज्ञान का प्राचीन नियम है:

प्रकृति एक निर्वात का पालन करती है।

फ्रेंकोइस रबेलस (फ्रेंच भिक्षु और व्यंग्यकार 1494-1553)


1

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

तो हम क्यों नहीं?

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


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

टिमवी: मैं नवाचार के खिलाफ बहस नहीं कर रहा हूं। बस यही कारण है कि अच्छा कोड लिखना इतना कठिन लगता है।
user281377

1

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


एंबेडेड सिस्टम लोग विधानसभा की एक सभ्य राशि लिखते हैं।
पॉल नाथन

@ पाओल नाथन ट्रू
रोबॉटहूमंस

0

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

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

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

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


एक युवा कंपनी की तरह लगता है जिसने अभी तक नहीं सीखा है कि सबसे सस्ता यह पहली बार सही कर रहा है ...

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

0

अच्छे कोड के निर्माण में लोगों ने कैसे बदतर कर दिया है?

उदाहरण के लिए यदि आप .NET और C # जैसी भाषा लेते हैं, (और मुझे पता है कि यह एकमात्र प्लेटफॉर्म / भाषा नहीं है), तो मैं तर्क दूंगा कि कोडिंग अच्छी तरह से दूर हो गई है, विजुअल स्टूडियो के भीतर कई चीजों के स्वचालन के कारण बहुत आसान है वातावरण।

यदि कुछ भी हो, तो बस इतना ही कि अब हमारे पास बहुत ही परिष्कृत IDE है जो हमें कोडिंग और विकास प्रक्रिया के माध्यम से मार्गदर्शन करने में सक्षम है, "अच्छे कोड" को प्राप्त करना आसान बना रहा है।

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

मेरे दो सेंट।


0

हां, हम एक ऐसे उद्योग के रूप में प्रैक्टिस नहीं कर रहे हैं जिसे अच्छी कार्यप्रणाली के रूप में जाना जाता है। संदर्भ: स्टीव मैककॉनेल की कॉन्स्ट्रेक्स सॉफ्टवेयर सॉफ्टवेयर डेवलपमेंट की कम हैंगिंग फ्रूट


-2

कोड की गुणवत्ता बेहतर नहीं हुई है

कृपया "अच्छे कोड" की व्याख्या में न फंसें

महान तार्किक तनातनी।

कोड बेहतर नहीं होता है क्योंकि लोग "अच्छे" की परिभाषा को आगे बढ़ाते हैं।

यदि आप "अच्छे कोड" पर चर्चा कर सकते हैं, तो आप तुलना नहीं कर सकते हैं और आप वास्तव में यह तय नहीं कर सकते कि यह "चुनौती" है या नहीं।


मेरे लिए "अच्छा कोड" ऐसा है कि यह बग की संख्या कम कर देता है। अब इसे कई तरीकों से पूरा किया जा सकता है।
अमीर रज़ाई २ 27'११

@Amir Rezaei: "अच्छे कोड" की परिभाषा व्यक्तिगत है। " "एक अच्छा कोड 'ऐसा है कि यह बग की संख्या को कम करता है" कृपया बस चुनें एक परिभाषा चुनें और अपने प्रश्न को केवल एक परिभाषा में शामिल करने के लिए अपडेट करें ।
S.Lott

वैसे "'अच्छा कोड' ऐसा है कि यह बग की संख्या को कम करता है" मेरा व्यक्तिगत विचार "अच्छा कोड" है। मुझे लगता है कि हर कोई जानता है कि परियोजना को कब सफाई की जरूरत है या नहीं
अमीर रज़ाई २ 27'११

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

अच्छा कोड: यह संकलित, परीक्षण पारित, उपयोगकर्ता अनुमोदन प्राप्त किया और उत्पादन में डाल दिया गया था। बस उम्मीद है कि कोई भी इसे बदलना नहीं चाहता।
जेएफओ
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.