🐍 🕒 👷 पांच प्रसिद्ध समझाया प्रोग्रामिंग उद्धरण 👍🏾 ☝️ 🏢

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

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

1. अप्रत्यक्षता

"सभी प्रोग्रामिंग समस्याओं को अप्रत्यक्ष स्तर का एक अतिरिक्त स्तर बनाकर हल किया जाता है" - डेविड विलर

यहां कंप्यूटर साइंस थ्योरी और एप्लिकेशन की एक उद्धरण है, जिसे हर कोई दोहराना पसंद करता है और कम ही लोग समझाना पसंद करते हैं। फिर भी, यह मेरी पसंदीदा प्रोग्रामिंग सच्चाइयों में से एक है - यह उपयुक्त रूप से प्रोग्रामिंग के बहुत सार को प्रकट करता है।

परोक्ष की भावना बनाने का सबसे आसान तरीका परतों की कल्पना करना है। उदाहरण के लिए, कल्पना कीजिए कि आपके पास एक छोटी परियोजना है जिसमें आपको घटक A को घटक B के अंदर रखने की आवश्यकता है:

दोनों घटक मानकीकृत हैं, इसलिए उन्हें घटकों में बदलना और संचालन के सिद्धांत को बदलने से काम नहीं चलेगा। आप एक अलग ऐड-ऑन घटक ( PlugTwoProngVariant) बना सकते हैं , लेकिन यह बहुत काम और अनावश्यक दोहराव है। एक बेहतर समाधान है: इन दो घटकों के बीच एक एडेप्टर परत जोड़ें जो दोनों के साथ सफलतापूर्वक बातचीत करता है और उनके बीच एक मध्यस्थ के रूप में कार्य करता है।

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

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

पर एक बोनस उद्धरण

एक शक्तिशाली उपकरण है, लेकिन आपको जटिलता के लिए भुगतान करना होगा। लोग प्रसिद्ध उद्धरण के तुरंत बाद बयान का हवाला देते हैं:

"यह आमतौर पर एक नई समस्या पैदा करता है।" - डेविड व्हीलर।

यह इस सच्चाई के लिए धन्यवाद है कि प्रोग्रामर लंबे समय से व्यवसाय में बने हुए हैं।

2. शुद्धता के बारे में

"सादगी विश्वसनीयता के लिए एक पूर्वापेक्षा है" - एद्गर दिज्क्स्ट्रा

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

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

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

एक विषय पर एक बोनस उद्धरण

कोड को सरल रखने के सर्वोत्तम तरीकों में से एक यह याद रखना है कि कम अधिक है। Dijkstra माप की एक नई इकाई प्रदान करता है जो हमें हमेशा यह याद दिलाता है:

"यदि हम कोड की पंक्तियों की संख्या को गिनना चाहते हैं, तो हमें उन्हें लिखित रूप में नहीं समझना चाहिए, लेकिन जैसा कि खर्च किया गया है" - एद्स्गर दिवास्त्र

3. पठनीयता और पुनर्लेखन के बारे में

"कोड लिखने की तुलना में पढ़ने के लिए कठिन है" - जोएल स्पोल्स्की

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

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

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

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

विषय पर बोनस उद्धरण

यदि आप अभी भी पठनीयता के महत्व पर संदेह करते हैं, तो मार्टिन फाउलर समस्या को अधिक व्यापक रूप से देखने में मदद करेंगे:

“कोई भी मूर्ख कोड लिख सकता है जिसे कंप्यूटर समझ सकता है। अच्छे प्रोग्रामर ऐसे कोड लिखते हैं जिन्हें लोग समझ सकते हैं। ”- मार्टिन फाउलर

दूसरे शब्दों में, प्रोग्रामर का कार्य केवल काम करने वाले कोड को जारी करना नहीं है, बल्कि आंतरिक तर्क के साथ कोड है।

4. पुनरावृत्ति के बारे में

“दोहराओ मत। ज्ञान के प्रत्येक टुकड़े में प्रणाली में एक अद्वितीय, स्पष्ट, विश्वसनीय प्रतिनिधित्व होना चाहिए "- एंडी हंट और डेविड थॉमस

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

इस बग को विधि के साथ टाला जा सकता है।GetTeamUniform()

हालांकि, दोहराव ने न केवल कोड में कहर बरपा दिया। प्रसिद्ध DRY सिद्धांत (डोन्ट रिपीट योरसेल्फ) के इस संस्करण में डुप्लिकेट को समाप्त करने के सिद्धांत की व्यापक रूप से व्याख्या की गई है, जिसमें अन्य स्थानों को शामिल किया गया है जहाँ दोहराव अपना रास्ता बना सकते हैं। अब वार्तालाप कोड में डुप्लिकेट के बारे में नहीं है - हम पूरे सिस्टम में दोहराव के बारे में भी बात कर रहे हैं। और सिस्टम विभिन्न स्वरूपों में ज्ञान को कूटबद्ध करता है। विशेष रूप से, ये हैं:

ऑपरेटर्स
कोड टिप्पणियाँ
डेवलपर्स या ग्राहकों के लिए प्रलेखन
डेटा स्कीमा (उदा। डेटाबेस टेबल)
अन्य विनिर्देश - परीक्षण योजना, प्रक्रिया संगठन दस्तावेज़, विधानसभा नियम

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

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

विषय में बोनस उद्धरण।

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

"कोड कभी झूठ नहीं होता है, लेकिन टिप्पणियों के साथ ऐसा होता है" - रॉन जेफ्रीस

5. जटिल समस्याओं के बारे में

"कंप्यूटर विज्ञान में, केवल दो जटिल समस्याएं हैं - कैश को अमान्य करना और नामों के साथ आना" - फिल कारटन

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

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

बुरे नामों की कई किस्में हैं। हम सभी उन चरों के साथ मिले जो डेटा प्रकारों ( myString, obj), संक्षिप्तीकरण ( pcजैसे उत्पाद सूची), कुछ तुच्छ कार्यान्वयन विवरण ( swappable_name, formUserInput), या यहां तक कि नामहीन ( ret_value,tempArray) एक जाल में गिरना और एक चर का नाम देना आसान है जो आप इसके साथ कर रहे हैं, और इसकी सामग्री से नहीं। और तार्किक डेटा प्रकारों के मूल्यों के साथ, परेशानी यह है: इसका क्या मतलब है progress- यह प्रगति पहले ही शुरू हो चुकी है, कि आपको इंटरफ़ेस में प्रगति के बारे में जानकारी, या सामान्य रूप से कुछ और प्रदर्शित करने की आवश्यकता है?

स्रोत: कमेंट्री डॉट कॉम

स्थानांतरण

«results_tmp_2? ?.. , ? !» — «, … , results_tmp_2. »

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

विषय में बोनस उद्धरण।

« – , » —

पांच प्रसिद्ध समझाया प्रोग्रामिंग उद्धरण

1. अप्रत्यक्षता

2. शुद्धता के बारे में

3. पठनीयता और पुनर्लेखन के बारे में

4. पुनरावृत्ति के बारे में

5. जटिल समस्याओं के बारे में

More articles: