एक प्रोग्रामर के लिए कोड लिखना शुरू करने से पहले एल्गोरिथ्म को डिजाइन करना बेहतर क्यों है?


12

क्या एक उपयुक्त एल्गोरिथ्म वास्तव में गुणवत्ता और अंततः एक कार्यक्रम की दक्षता में सुधार करने में मदद करता है?

क्या हम अभी भी एल्गोरिथ्म के बिना एक अच्छी गुणवत्ता कार्यक्रम का उत्पादन कर सकते हैं?

क्या आधुनिक प्रोग्रामिंग में एक उपयुक्त एल्गोरिथ्म जरूरी है?


5
परिभाषा के अनुसार कुछ एल्गोरिथ्म है, भले ही यह कितना बुरा हो यह अच्छा है

5
मेरे पास बहुत ज्यादा सोचने के बजाय कोड कोड के अलावा कोई विकल्प नहीं है। अधिकांश समय किसी भी मानक द्वारा कोई शानदार एल्गोरिथ्म नहीं है; मैं सिर्फ एक बदबूदार हल्दी को चमकाने की कोशिश कर रहा हूं;)
नौकरी

13
मैं विश्वास नहीं कर सकता कि यह एक गंभीर प्रश्न है। देखें en.wikipedia.org/wiki/Algorithm
स्टीवन ए लोव

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

9
मैं कहता हूं कि ... हमेशा लक्ष्यहीन होकर गाड़ी चलाना बेहतर है जब तक कि आप दुर्घटना से अपनी मंजिल नहीं पा लेते या गैस से बाहर नहीं निकल जाते।
jmq

जवाबों:


29

मुझे लगता है कि यह प्रश्न कुछ ऐतिहासिक परिप्रेक्ष्य को दर्शाता है।

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

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

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


1
क्या जवाब दिया। आपको यहाँ पाना मेरा सौभाग्य है !!!
जेरिस

5
इसके अलावा कंप्यूटर प्रोग्रामर की तुलना में बहुत अधिक महंगा था, इसलिए यह प्रोग्रामर को कठिन काम करने के लिए समझ में आया!

2
आप सही हैं कि हम जिस चीज के लिए अनुकूलन कर रहे हैं वह बदल गई है। लेकिन अब हम लोगों से कहीं अधिक जटिल प्रणालियों में हेरफेर करने की उम्मीद कर रहे हैं। योजना, संगठन और रखरखाव के बारे में विचार की कमी अभी भी आपको मार डालेगी।
btilly

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

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

14

बस कुछ इंगित करने के लिए:

एक एल्गोरिथ्म स्वयं आपकी समस्या का सामान्य चरण-दर-चरण समाधान है। इसलिए, यदि आपने समस्या हल कर ली है, तो आपने वास्तव में एक एल्गोरिथ्म का उपयोग किया है।

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

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

संपादित करें:

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

  • मेरा व्यक्तिगत पसंदीदा यहाँ छद्म कोड है, और केवल प्रश्न में एल्गोरिथ्म की एक सामान्य अमूर्त रूपरेखा को कवर करना है - छद्मकोड के साथ विवरण में प्राप्त करना हास्यास्पद है , यही वास्तविक कोड है।

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

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

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

  • आम तौर पर, किसी भी मतलब के लिए आपको केवल एक निश्चित एल्गोरिथ्म के पीछे के विचार को स्केच करना होता है।


किसी के एल्गोरिथ्म को प्रस्तुत करने के कई अलग-अलग तरीके हैं, जो आप सुझाते हैं? और क्यों?
जर्विस

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

लिंक कहां है?
जेरिस

4

एक अच्छा सादृश्य यह है कि आपको खाना पकाने शुरू करने से पहले एक नुस्खा पता होना चाहिए। ठीक है, आप इसे घुमा सकते हैं जैसे ही आप जाते हैं, लेकिन आपको अभी भी जानना होगा कि आप शुरू करने से पहले क्या बनाना चाहते हैं। अगर मैं एक मेमना स्टू बनाना चाहता हूं तो मैं बहुत अलग चीजें करूंगा जैसे कि मैं रोटी की रोटी खाना चाहता हूं।


एल्गोरिथम = विचार ???
जेरिस

एल्गोरिथ्म == नुस्खा !!

लेकिन अलग-अलग रसोइयों में एक ही नुस्खा के अनुसार खाना पकाने के अलग-अलग तरीके होते हैं।
जेरिस

ज़रूर, जब मैं रोटी सेंकता हूँ तो यह अलग हो जाता है जब मेरी पत्नी रोटी खाती है। लेकिन मूल भाग समान हैं (आटा, पानी, खमीर, नमक)
ज़ाचरी के

वहाँ भी दुकानें हैं जहाँ आप बस एक पेशेवर बेकर
जेके

3

कोड लागू एल्गोरिदम। एल्गोरिथ्म को डिजाइन किए बिना कोड लिखने की कोशिश करना दीवारों के निर्माण से पहले एक घर को पेंट करने की कोशिश करना है। प्रोग्रामिंग की शुरुआत से एल्गोरिदम एक "MUST" रहा है।


ठीक। घर को पेंट करना एबीसी जितना आसान है, आप घर के अस्तित्व के बिना योजना शुरू कर सकते हैं।
जेरिस

2
@ जर्विस: इसी तरह, आप अन्य भागों के लिए एल्गोरिथ्म को निर्दिष्ट किए बिना कोड के कुछ हिस्सों की योजना बना सकते हैं (उदाहरण के लिए, आप यह तय कर सकते हैं कि यह कैसे काम करेगा, यह तय किए बिना डेटा को सॉर्ट करने के लिए एक फ़ंक्शन होगा - लेकिन आपको समय से तय करने की आवश्यकता है छँटाई कोड लिखें)।
जेरी कॉफिन

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

3

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

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

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


1

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

बाद में आप कोड को फिर से संशोधित कर सकते हैं यदि प्रोफाइलिंग से पता चलता है कि उस क्षेत्र में एक प्रदर्शन मुद्दा है।


1

कारण यह है कि गलत तरीके से ठीक करने से पहले यह गलत है कि आपने गलत कोड लिखा है।

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

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


आपका कहना बिल्कुल सही है।
जेरिस

1

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


मैं आपसे सहमत हुँ।
जेरिस

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

0

वर्गों में एक एल्गोरिथ्म डिज़ाइन करें, फिर उन अनुभागों को विभाजित करें और उनमें से प्रत्येक को व्यक्तिगत रूप से कोड करें। इस तरह आप दोनों दृष्टिकोणों को मिला सकते हैं:

  1. अपनी भाषा क्षमताओं का उपयोग करके अल्‍गर्थम को काम में लाएं
  2. कोड से पहले सोचने की कोशिश करें, इसलिए आपका विचार भाषा में विलय नहीं होगा (एक दिन आपको अपने एल्गोरिथ्म को किसी अन्य भाषा में ले जाने की आवश्यकता है और आप स्पेगेटी में संयुक्त राष्ट्र को समाप्त कर देंगे)

याप! मुझे पता है कि एल्गोरिथ्म भाषा-स्वतंत्र है। यह सच है कि समान एल्गोरिथ्म को व्यक्त करने के लिए आप किसी भी मौजूदा प्रोग्रामिंग भाषा का उपयोग कर सकते हैं।
जर्विस

0

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

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

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


0

जब आप बैठते हैं और कोडिंग शुरू करते हैं, तो आपके मन में एक एल्गोरिथ्म होता है, चाहे "डिज़ाइन किया गया हो" या नहीं।

यदि आप बैठ गए और कोई पूर्ण एल्गोरिथ्म को ध्यान में रखते हुए कोडिंग शुरू कर रहे हैं, तो आप निम्नलिखित में से एक करेंगे:

1) चाबियाँ बेतरतीब ढंग से mashing। यह संभवतः एक संकलक त्रुटि का उत्पादन करेगा

2) संकलित कोड लिखना जो संभवत: कुछ भी करता है सिवाय इसके कि आप इसे करना चाहते हैं

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

इसलिए लोग आमतौर पर अपने सिर में एक एल्गोरिथ्म के साथ कार्यक्रम करते हैं। हो सकता है कि इसे पेपर या किसी अन्य माध्यम से हटा दिया गया हो।

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


0

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

क्या एक उपयुक्त एल्गोरिथ्म वास्तव में गुणवत्ता और अंततः एक कार्यक्रम की दक्षता में सुधार करने में मदद करता है?

क्या एक उपयुक्त भवन योजना / योजनाबद्ध कुशलता से एक गुणवत्तापूर्ण घर बनाने में मदद करती है?

क्या हम अभी भी एल्गोरिथ्म के बिना एक अच्छी गुणवत्ता कार्यक्रम का उत्पादन कर सकते हैं?

क्या आप एक उचित निर्माण योजना के बिना कुशलता से एक अच्छी गुणवत्ता का घर बना सकते हैं? के अनुसार अनंत बंदर प्रमेय , संभवतया, हाँ (सिर्फ एक लाख के रूप में अनंत काल के लिए यादृच्छिक पर टाइपिंग बंदरों अंत में शेक्सपियर का पूरा काम टाइप करेंगे।

क्या आधुनिक प्रोग्रामिंग में एक उपयुक्त एल्गोरिथ्म जरूरी है?

यदि आप एक कोड बंदर नहीं बनना चाहते हैं और आप यह सुनिश्चित करना चाहते हैं कि आप ऐसे सॉफ़्टवेयर न वितरित करें, जो दिखते हैं और जैसे काम करते हैं, हाँ, यह बहुत जरूरी है। हर परियोजना जिसे मुझे निस्तारण करना था (क्योंकि कोड umaintainable shit की तरह दिखता था) ने उस प्रश्न के नकारात्मक उत्तर के साथ अपरिवर्तनीय शुरुआत की है।

वास्तव में, आधुनिक प्रोग्रामिंग चरवाहे प्रोग्रामिंग सॉफ्टवेयर इंजीनियर से दूर चला गया है जहां यदि आवश्यक हो तो किसी प्रकार की योजना बनाना चाहिए।

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


-2

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

पहले किसी तरह का टेस्ट और बेंचमार्क लगाएं।

फिर कुछ भी लिखो, कुछ भी। जब तक आप समय से बाहर नहीं निकलते हैं या सुधार नहीं कर सकते हैं तब तक रिफ्लैक्टर-रीराइट करें।

जबकि कई लोगों को लगता है कि कोई कंप्यूटर पर वास्तव में कंप्यूटर पर कुछ भी किए बिना चीजें कर सकता है, मुझे लगता है कि यह सबसे आम म्याँमार में से एक है। वास्तुकला अंतरिक्ष यात्री।

इसके अलावा, आप अपने अहंकार को लिखे जाने से पहले अनुकूलित नहीं कर सकते।

IOW, "धातु के करीब रहें"।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.