मेरे काम का मूल्यांकन, मैंने हाल ही में बहुत अच्छा कोड लिखने के बारे में सोचा। यह देखते हुए कि कोई भी बुरा कोड लिखने में रुचि नहीं रखता है , यह सवाल उठता है: यदि आपने गो पर अच्छा कोड लिखा है तो आपको कैसे पता चलेगा ? अगर अच्छे और बुरे के बीच किसी तरह का पैमाना है, तो यह कैसे समझा जाए कि पैमाने के कौन से हिस्से अच्छे हैं? इसके गुण, गुण, विशिष्ट विशेषताएं, पैटर्न और मुहावरे क्या हैं?मुहावरेदार
इन विचारों ने मुझे मुहावरे के लिए प्रेरित किया। यदि हम कुछ "मुहावरेदार" कहते हैं, तो यह कुछ समय की एक निश्चित शैली से मेल खाती है। यदि कोई चीज मुहावरेदार नहीं है, तो यह प्रमुख शैली के अनुरूप नहीं है। वह फैशनेबल नहीं है।इससे भी महत्वपूर्ण बात, जब हम कहते हैं कि किसी का कोड मुहावरेदार नहीं है, तो इसका कारण स्पष्ट नहीं है। मुहावरेदार क्यों नहीं? इसका जवाब डिक्शनरी ने दिया है।मुहावरा (सं।): एक भाषण क्रांति, एक पूरे के रूप में इस्तेमाल की जाती है, आगे के विघटन के अधीन नहीं है और आमतौर पर खुद के लिए अनुमति नहीं देती है।
मुहावरे सामान्य अर्थों की पहचान हैं। किताबें आपको मुहावरेदार नहीं सिखाएंगी, यह केवल तब पता चलता है जब आप किसी समुदाय का हिस्सा बनते हैं।मैं मुहावरेदार गो मंत्र के बारे में चिंतित हूं क्योंकि यह अक्सर प्रतिबंधात्मक है। वह कहती है: "आप हमारे साथ नहीं बैठ सकते।" क्या ऐसा नहीं है कि जब हम किसी और के काम की आलोचना करते हैं तो उसका मतलब क्या होता है? उन्होंने गलत किया। यह ठीक नहीं लगता। यह समय की शैली के अनुरूप नहीं है।मेरा मानना है कि मुहावरेदार गो, अच्छे कोड लिखना सिखाने के लिए उपयुक्त नहीं है, क्योंकि, संक्षेप में, इसका मतलब है कि लोगों को यह बताना कि उन्होंने कुछ गलत किया है। ऐसी सलाह देना बेहतर है जो उस समय किसी व्यक्ति को दूर नहीं करेगी जब वह सबसे अधिक इस सलाह को प्राप्त करना चाहता है।कहावतें
आइए मुहावरेदार समस्याओं से ध्यान भटकाएं। गो प्रोग्रामर में कौन सी अन्य सांस्कृतिक कलाएं निहित हैं? सुंदर गो कहावत पृष्ठ पर जाएं । क्या ये कहावत एक उपयुक्त शिक्षण उपकरण है? क्या वे शुरुआती लोगों को बताते हैं कि अच्छा गो कोड कैसे लिखें?मुझे ऐसा नहीं लगता। मैं लेखक के काम को कमज़ोर नहीं करना चाहता। उन्होंने जो कहा, वह केवल टिप्पणियों का है, अर्थ की परिभाषाओं का नहीं। शब्दकोश फिर से बचाव के लिए आता है:कहावत (सं।): एक छोटा बयान जिसका शाब्दिक या लाक्षणिक अर्थ होता है।
गो कहावत का मिशन भाषा की वास्तुकला का गहरा सार दिखाना है। लेकिन क्या यह सलाह के लिए उपयोगी होगा कि " खाली इंटरफ़ेस कुछ भी नहीं कहता है " एक शुरुआती को जो संरचनात्मक टाइपिंग के बिना एक भाषा से आया है?एक बढ़ते समुदाय में, यह पहचानना महत्वपूर्ण है कि गो छात्रों की संख्या उन लोगों की संख्या से कहीं अधिक है जो इस भाषा में धाराप्रवाह हैं। यही है, ऐसी स्थिति में सीखने के लिए शायद सबसे अच्छा तरीका नहीं है।डिजाइन मान
डान लियू को विंडोज एनटी-विंडोज 2000 विंडोज डेवलपमेंट टीम में डिजाइन संस्कृति पर मार्क लुकोव्स्की द्वारा एक पुरानी प्रस्तुति मिली । मैंने इसका उल्लेख किया क्योंकि लुकोव्स्की ने संस्कृति को आर्किटेक्चर का मूल्यांकन करने और समझौता करने का एक सामान्य तरीका बताया।मुख्य विचार एक अज्ञात वास्तुकला के भीतर मूल्य-आधारित निर्णय करना है । NT टीम में ये मूल्य थे: पोर्टेबिलिटी, विश्वसनीयता, सुरक्षा और एक्स्टेंसिबिलिटी। सीधे शब्दों में कहें, डिजाइन मान समस्याओं को हल करने का एक तरीका है।मान जाओ
गो के स्पष्ट मूल्य क्या हैं? मुख्य अवधारणा या दर्शन क्या हैं जो यह निर्धारित करते हैं कि कैसे प्रोग्रामर दुनिया की व्याख्या करते हैं? उन्हें कैसे घोषित किया जाता है? उन्हें कैसे पढ़ाया जाता है? उनका पालन कैसे किया जाता है? वे समय के साथ कैसे बदलते हैं?आप एक गो प्रोग्रामर को गो डिज़ाइन के मूल्यों को कैसे परिवर्तित करते हैं? या आप कैसे एक अनुभवी गो-प्रो, भावी पीढ़ियों के लिए अपने मूल्यों की घोषणा करते हैं? और इसलिए कि आप समझते हैं, ज्ञान हस्तांतरण की यह प्रक्रिया वैकल्पिक नहीं है? नए प्रतिभागियों और नए विचारों की आमद के बिना, हमारा समुदाय मायोपिक और मुरझा जाता है।अन्य भाषाओं का मान
मैं जो कहना चाहता हूं, उसके लिए रास्ता तैयार करने के लिए, हम अन्य भाषाओं पर, उनके डिजाइन मूल्यों पर ध्यान दे सकते हैं।उदाहरण के लिए, C ++ और Rust में यह माना जाता है कि एक प्रोग्रामर को ऐसी सुविधा के लिए भुगतान नहीं करना चाहिए जिसका वह उपयोग नहीं करता है । यदि प्रोग्राम भाषा के कुछ संसाधन-गहन सुविधा का उपयोग नहीं करता है, तो प्रोग्राम को इस सुविधा को बनाए रखने की लागत को वहन करने के लिए मजबूर नहीं किया जा सकता है। यह मान भाषा से मानक पुस्तकालय में अनुमानित है और इसका उपयोग C ++ में लिखे गए सभी कार्यक्रमों की वास्तुकला के मूल्यांकन के लिए एक मानदंड के रूप में किया जाता है।जावा, रूबी और स्मॉलटाक में मुख्य मूल्य - सब कुछ एक वस्तु है। यह सिद्धांत संदेश स्थानांतरण, सूचना छिपाने और बहुरूपता के संदर्भ में कार्यक्रम डिजाइन को रेखांकित करता है। एक प्रक्रियात्मक या कार्यात्मक प्रतिमान के अनुरूप आर्किटेक्चर को इन भाषाओं में गलत माना जाता है। या, जैसा कि एक गो प्रोग्रामर कहेगा, मुहावरेदार नहीं।आइए अपने समुदाय पर वापस जाएं। गो प्रोग्रामर्स के प्रोफेसरों के लिए कौन से डिज़ाइन मूल्य हैं? इस विषय पर चर्चा अक्सर खंडित होती है, इसलिए अर्थ का एक सेट तैयार करना आसान नहीं होता है। समझौते तक पहुंचना अनिवार्य है, लेकिन चर्चा में भाग लेने वाले प्रतिभागियों की बढ़ती संख्या के साथ इस तक पहुंचने की कठिनाई तेजी से बढ़ती है। लेकिन अगर किसी ने हमारे लिए यह मुश्किल काम किया तो क्या होगा?ज़ेन अजगर गो
कुछ दशक पहले, टिम पीटर्स ने बैठकर PEP-20 - The Zen of Python लिखा था । उन्होंने उन डिजाइन मूल्यों को प्रलेखित करने की कोशिश की, जो गिदो वान रोसुम ने उदार जीवनकाल पायथन डिक्टेटर के रूप में पालन किया।आइए पायन के ज़ेन को देखें और देखें कि क्या हम गो डिजाइनर के डिज़ाइन मूल्यों से बाहर निकल सकते हैं।एक अच्छा पैकेज एक अच्छे नाम से शुरू होता है
आइए तेज के साथ शुरू करें:नाम स्थान एक महान विचार है, चलो उन्हें बड़ा बनाते हैं!
पायथन का ज़ेन, रिकॉर्ड 19।
पर्याप्त रूप से पर्याप्त: पायथन प्रोग्रामर को नामस्थान का उपयोग करना चाहिए। बहुत सारे स्थान।गो शब्दावली में, एक नाम स्थान एक पैकेज है। इसमें कोई संदेह नहीं है कि बंडलिंग डिजाइन और पुन: उपयोग के पक्ष में है। लेकिन ऐसा करने के तरीके के बारे में भ्रम हो सकता है, खासकर यदि आपके पास किसी अन्य भाषा में कई वर्षों का प्रोग्रामिंग अनुभव है।गो में, प्रत्येक पैकेज को किसी चीज़ के लिए डिज़ाइन किया जाना चाहिए। और नाम इस गंतव्य को समझने का सबसे अच्छा तरीका है। पीटर के विचारों को सुधारते हुए, गो के प्रत्येक पैकेज को एक चीज़ के लिए डिज़ाइन किया जाना चाहिए।विचार नया नहीं है, मैं पहले ही इस बारे में बात कर चुका हूं । लेकिन इस दृष्टिकोण का उपयोग क्यों किया जाना चाहिए, और दूसरा नहीं, जिसमें विस्तृत वर्गीकरण की जरूरतों के लिए पैकेज का उपयोग किया जाता है? यह सभी परिवर्तनों के बारे में है।— , .
परिवर्तन उस गेम का नाम है जिसमें हम भाग ले रहे हैं। हम, प्रोग्रामर के रूप में, परिवर्तन का प्रबंधन करते हैं। यदि हम इसे अच्छी तरह से करते हैं, तो हम इसे वास्तुकला कहते हैं। और अगर यह खराब है, तो हम इसे तकनीकी ऋण या विरासत कोड कहते हैं।यदि आप एक प्रोग्राम लिखते हैं जो इनपुट डेटा के एक निश्चित सेट के साथ एक बार बहुत अच्छा काम करता है, तो किसी को भी इसमें कोई दिलचस्पी नहीं होगी कि इसमें अच्छा कोड है, क्योंकि केवल इसके काम का परिणाम व्यवसाय के लिए महत्वपूर्ण है।लेकिन ऐसा होता नहीं है । कार्यक्रमों, आवश्यकताओं और इनपुट डेटा परिवर्तन में बग होते हैं, और बहुत कम कार्यक्रम एकल निष्पादन अपेक्षा के साथ लिखे जाते हैं। यही है, आपका कार्यक्रम समय के साथ बदल जाएगा । शायद यह कार्य आपको दिया जाएगा, लेकिन सबसे अधिक संभावना है कि कोई और इसे करेगा। किसी को इस कोड के साथ जाने की जरूरत है।हम कार्यक्रमों को बदलना आसान कैसे बनाते हैं? हर जगह इंटरफेस जोड़ें? क्या स्टब्स बनाने के लिए सब कुछ उपयुक्त है? निर्भरता को कसकर तैनात करें? शायद, कुछ प्रकार के कार्यक्रमों के लिए, ये तकनीक उपयुक्त हैं, लेकिन कई के लिए नहीं। हालांकि, अधिकांश कार्यक्रमों के लिए, एक लचीली वास्तुकला का निर्माण डिजाइन की तुलना में अधिक है।और अगर घटकों के विस्तार के बजाय हम उन्हें बदल देंगे? यदि घटक वह नहीं करता है जो निर्देशों में निर्दिष्ट है, तो इसे बदलने का समय है।एक अच्छा पैकेज एक अच्छा नाम चुनने के साथ शुरू होता है। इसे एक छोटी प्रस्तुति पर विचार करें जो केवल एक शब्द के साथ एक पैकेज के कार्य का वर्णन करती है। और जब नाम अब आवश्यकता को पूरा नहीं करता है, तो एक प्रतिस्थापन ढूंढें।सादगी मायने रखती है
सरल जटिल से बेहतर है।
पायथन का ज़ेन, प्रवेश 3।
PEP-20 का दावा है कि परिसर की तुलना में सरल बेहतर है, और मैं पूरी तरह से सहमत हूं। कुछ साल पहले मैंने लिखा था:अधिकांश प्रोग्रामिंग लैंग्वेज पहले सरल होने की कोशिश करती हैं, लेकिन बाद में शक्तिशाली होने का फैसला करती हैं।
मेरी टिप्पणियों के अनुसार, कम से कम उस समय, मैं एक ऐसी भाषा को याद नहीं कर सकता था जिसे मैं जानता था कि इसे उतना सरल नहीं माना जाएगा। औचित्य और प्रलोभन के रूप में, प्रत्येक नई भाषा के लेखकों ने सरलता की घोषणा की। लेकिन मैंने पाया कि सरलता गो (रूबी, स्विफ्ट, एल्म, गो, नोडोड्स, पायथन, रस्ट) के रूप में एक ही उम्र की कई भाषाओं का मुख्य मूल्य नहीं था। शायद यह एक पीड़ादायक जगह से टकराएगा, लेकिन शायद इसका कारण यह है कि इनमें से कोई भी भाषा सरल नहीं है। या उनके लेखक उन्हें सरल नहीं मानते थे। सरलता को मुख्य मूल्यों की सूची में शामिल नहीं किया गया था।आप मुझे पुराने जमाने का मान सकते हैं, लेकिन यह सादगी फैशन से बाहर कब गई? वाणिज्यिक सॉफ्टवेयर उद्योग इस मूलभूत सत्य को लगातार और खुशी से क्यों भूल रहा है?सॉफ्टवेयर आर्किटेक्चर बनाने के दो तरीके हैं: इसे इतना सरल बनाना कि खामियों की कमी स्पष्ट हो, और इसे इतना जटिल बना दिया जाए कि इसमें स्पष्ट खामियां न हों। पहली विधि अधिक कठिन है।
चार्ल्स होयर, द एम्परर्स ओल्ड क्लॉथ्स, ट्यूरिंग अवार्ड लेक्चर, 1980
सरल का मतलब आसान नहीं है, हम जानते हैं कि। सृजन में आसानी के बजाय अक्सर उपयोग में आसानी सुनिश्चित करने के लिए यह अधिक प्रयास करता है।सादगी विश्वसनीयता की कुंजी है।
एड्स्जर डेज्स्ट्रा, EWD498, 18 जून, 1975
सादगी के लिए प्रयास क्यों? गो कार्यक्रमों का सरल होना क्यों महत्वपूर्ण है? सरल का मतलब कच्चा है, इसका मतलब है पठनीय और पालन करने में आसान। सरल का अर्थ कला-विहीन नहीं है, इसका अर्थ है विश्वसनीय, समझदार और समझने योग्य।प्रोग्रामिंग का मूल जटिलता प्रबंधन है।
ब्रायन कर्निगन, सॉफ्टवेयर टूल्स (1976)
क्या पायथन सरलता के अपने मंत्र का अनुसरण करता है, यह एक बहस का सवाल है। हालाँकि, गो, सादगी एक मुख्य मूल्य है। मुझे लगता है कि हम सभी सहमत होंगे कि गो सरल कोड में स्मार्ट कोड के लिए बेहतर है।पैकेज स्तर के राज्यों से बचें
निहितार्थ की तुलना में स्पष्ट है।
पायथन का ज़ेन, प्रविष्टि 2
यहाँ, पीटर्स, मेरी राय में, बल्कि तथ्यों का पालन करने के बजाय सपने देखता है। पायथन में, बहुत स्पष्ट नहीं है: सज्जाकार, डंडर विधि, आदि। निस्संदेह, ये शक्तिशाली उपकरण हैं, और वे एक कारण के लिए मौजूद हैं। प्रत्येक सुविधा के कार्यान्वयन पर, विशेष रूप से जटिल, किसी ने काम किया। लेकिन ऐसी विशेषताओं का सक्रिय उपयोग कोड को पढ़ते समय ऑपरेशन की लागत का मूल्यांकन करना मुश्किल बनाता है।सौभाग्य से, हम Go प्रोग्रामर वैकल्पिक रूप से कोड को स्पष्ट कर सकते हैं। शायद, आपके लिए, अभिव्यक्ति नौकरशाही और क्रियाशीलता का पर्याय हो सकती है, लेकिन यह एक सतही व्याख्या है। यह केवल वाक्यविन्यास पर ध्यान केंद्रित करने, लाइनों की लंबाई और अभिव्यक्ति के लिए DRY सिद्धांतों के आवेदन पर ध्यान देने के लिए एक गलती होगी। मुझे कनेक्टिविटी और राज्यों के संदर्भ में खोजकर्ता प्रदान करना अधिक महत्वपूर्ण लगता है।कनेक्टिविटी दूसरे पर एक की निर्भरता का एक उपाय है। यदि एक दूसरे से निकटता से संबंधित है, तो दोनों एक साथ चलते हैं। एक को प्रभावित करने वाली क्रिया सीधे दूसरे में परिलक्षित होती है। एक ऐसी ट्रेन की कल्पना करें जिसमें सभी कारें जुड़ी हों - या बल्कि, जुड़ी हुई हों - एक साथ। स्टीम ट्रेन जहां जाती है, वहां कारें होती हैं।संयोजकता को सामंजस्य शब्द - सामंजस्य द्वारा भी वर्णित किया जा सकता है। यह इस बात का मापक है कि कोई दूसरे से कितना संबंधित है। एक टांका लगाने वाली टीम में, सभी प्रतिभागी एक-दूसरे के लिए इतने अनुकूल होते हैं, जैसे कि वे विशेष रूप से बनाए गए हों।सुसंगतता क्यों महत्वपूर्ण है? जैसा कि ट्रेन के मामले में, जब आपको कोड का एक टुकड़ा बदलने की आवश्यकता होती है, तो आपको बाकी संबंधित कोड को बदलना होगा। उदाहरण के लिए, किसी ने अपने एपीआई का एक नया संस्करण जारी किया है, और अब आपका कोड संकलित नहीं करता है।एक एपीआई बाध्यकारी का एक अपरिहार्य स्रोत है। लेकिन इसे और अधिक कपटी रूपों में प्रस्तुत किया जा सकता है। हर कोई जानता है कि अगर एपीआई के हस्ताक्षर बदल गए हैं, तो एपीआई से स्थानांतरित डेटा भी बदल जाएगा। यह सभी फ़ंक्शन हस्ताक्षर के बारे में है: मैं एक प्रकार के मूल्यों को लेता हूं और अन्य प्रकारों के मूल्यों को वापस करता हूं। और अगर एपीआई डेटा को अलग तरीके से स्थानांतरित करना शुरू कर देता है? क्या होगा यदि प्रत्येक एपीआई कॉल का परिणाम पिछली कॉल पर निर्भर करता है, भले ही आपने अपनी सेटिंग्स को नहीं बदला हो?इसे राज्य कहा जाता है, और राज्य प्रबंधन कंप्यूटर विज्ञान में एक समस्या है।package counter
var count int
func Increment(n int) int {
count += n
return count
}
यहां हमारे पास एक साधारण पैकेज है counter। काउंटर बदलने के लिए, आप कॉल कर सकते हैं Increment, यदि आप शून्य मान के साथ वृद्धि करते हैं, तो आप मूल्य वापस भी प्राप्त कर सकते हैं।मान लें कि आपको इस कोड का परीक्षण करने की आवश्यकता है। प्रत्येक परीक्षण के बाद काउंटर को रीसेट कैसे करें? और अगर आप समानांतर में परीक्षण चलाना चाहते हैं, तो यह कैसे किया जा सकता है? और मान लीजिए कि आप कार्यक्रम में कई काउंटरों का उपयोग करना चाहते हैं, तो क्या आप सफल होंगे?बिलकूल नही। जाहिर है, समाधान variableके प्रकार में परिवर्तनशील है।package counter
type Counter struct {
count int
}
func (c *Counter) Increment(n int) int {
c.count += n
return c.count
}
अब कल्पना करें कि वर्णित समस्या केवल काउंटर तक सीमित नहीं है, यह आपके अनुप्रयोगों के मुख्य व्यवसाय तर्क को भी प्रभावित करती है। क्या आप इसे अलगाव में परीक्षण कर सकते हैं? क्या आप समानांतर में परीक्षण कर सकते हैं? क्या आप एक ही समय में कई उदाहरणों का उपयोग कर सकते हैं? यदि उत्तर सभी प्रश्नों के लिए नहीं है, तो इसका कारण पैकेट स्तर पर स्थिति है।इन स्थितियों से बचें। पैकेज चर का उपयोग करने के बजाय संयोजकता के साथ प्रकार प्रदान करके कनेक्टिविटी और दुःस्वप्न दूरस्थ क्रियाओं की संख्या कम करें।असफलता के लिए योजनाएं बनाएं, सफलता नहीं
बगलों को कभी चुपचाप पास मत करो।
पायथन का ज़ेन, प्रविष्टि 10
यह उन भाषाओं के बारे में कहा जाता है जो समुराई-शैली के अपवाद से निपटने को प्रोत्साहित करते हैं: एक जीत के साथ वापस आते हैं या बिल्कुल वापस नहीं आते हैं। अपवादों पर आधारित भाषाओं में, फ़ंक्शन केवल मान्य परिणाम लौटाते हैं। यदि फ़ंक्शन ऐसा नहीं कर सकता है, तो नियंत्रण प्रवाह पूरी तरह से अलग तरीके से जाता है।जाहिर है, अनियंत्रित अपवाद एक असुरक्षित प्रोग्रामिंग मॉडल है। त्रुटियों की उपस्थिति में आप विश्वसनीय कोड कैसे लिख सकते हैं यदि आप नहीं जानते कि कौन से भाव अपवाद छोड़ सकते हैं? जावा जाँच किए गए अपवादों की अवधारणा के साथ जोखिम को कम करने की कोशिश करता है। और जहां तक मुझे पता है, अन्य लोकप्रिय भाषाओं में इस समाधान के कोई एनालॉग नहीं हैं। कई भाषाओं में अपवाद हैं, और जावा को छोड़कर हर जगह, उन्हें चेक नहीं किया गया है।जाहिर है, गो ने एक अलग रास्ता अपनाया। गो प्रोग्रामर्स का मानना है कि विश्वसनीय कार्यक्रम ऐसे हिस्सों से बने होते हैं जो सफल रास्तों को संसाधित करने से पहले विफलताओं को संभालते हैं। यह देखते हुए कि भाषा सर्वर विकास के लिए बनाई गई थी, बहु-थ्रेडेड प्रोग्रामों का निर्माण, साथ ही प्रोग्राम जो नेटवर्क पर डेटा दर्ज करने की प्रक्रिया करते हैं, प्रोग्रामर को अप्रत्याशित और क्षतिग्रस्त डेटा, टाइमआउट और कनेक्शन विफलताओं के साथ काम करने पर ध्यान केंद्रित करना चाहिए। बेशक, अगर वे विश्वसनीय उत्पाद बनाना चाहते हैं।मेरा मानना है कि त्रुटियों को स्पष्ट रूप से नियंत्रित किया जाना चाहिए, यह भाषा का मुख्य मूल्य होना चाहिए।
पीटर बर्गोन , गोएथम # 91
मैं पीटर के शब्दों में शामिल हो गया, उन्होंने इस लेख के लेखन में एक प्रेरणा के रूप में कार्य किया। मेरा मानना है कि गो अपनी सफलता को स्पष्ट त्रुटि से निपटने के लिए मानता है। प्रोग्रामर मुख्य रूप से संभावित क्रैश के बारे में सोचते हैं। सबसे पहले, हम "क्या अगर" जैसी समस्याओं को हल करते हैं। परिणाम ऐसे कार्यक्रम हैं जिनमें विफलताओं को कोड लिखने के चरण में संभाला जाता है, न कि ऑपरेशन के दौरान जैसा कि होता है।इस कोड की क्रियाif err != nil {
return err
}
उस समय होने वाली प्रत्येक विफल स्थिति को जानबूझकर संभालने के महत्व को रेखांकित करता है। इसकी कुंजी प्रत्येक त्रुटि को स्पष्ट रूप से संभालने का मूल्य है।गहराई से निवेश करने की तुलना में जल्दी लौटने के लिए बेहतर है
सिबलिंग
द ज़ेन ऑफ़ पायथन के घोंसले से बेहतर है , एंट्री 5
यह बुद्धिमान सलाह एक ऐसी भाषा से आती है जिसमें इंडेंटेशन नियंत्रण प्रवाह का मुख्य रूप है। गो शब्दावली में हम इस टिप की व्याख्या कैसे करते हैं? गोफमट गो कार्यक्रमों में पूरी जगह खाली जगह का प्रबंधन करता है, इसलिए हमारे पास यहां करने के लिए कुछ नहीं है।मैंने पैकेज नामों के बारे में ऊपर लिखा है। शायद संकुल के एक जटिल पदानुक्रम से बचने के लिए सलाह दी जाती है। मेरे अनुभव में, जितना अधिक एक प्रोग्रामर गो पर एक कोड आधार को अलग और वर्गीकृत करने की कोशिश करता है, पैकेज के चक्रीय आयात का जोखिम उतना अधिक होता है।मेरा मानना है कि द ज़ेन ऑफ पायथन से पांचवीं प्रविष्टि का सबसे अच्छा उपयोग एक फ़ंक्शन के अंदर एक नियंत्रण प्रवाह बनाना है । दूसरे शब्दों में, एक नियंत्रण प्रवाह से बचें जिसके लिए बहु-स्तरीय इंडेंटेशन की आवश्यकता होती है।प्रत्यक्ष दृश्यता एक सीधी रेखा है जिसके साथ दृश्य कुछ भी अस्पष्ट नहीं है।
मई रायर, कोड: बाएं किनारे पर खुश पथ संरेखित करें
मेयर ने इस विचार को दृष्टि की सीधी रेखा में प्रोग्रामिंग के रूप में वर्णित किया है:- यदि पूर्व शर्त पूरी नहीं हुई है तो जल्दी लौटने के लिए नियंत्रण कथनों का उपयोग करें।
- फ़ंक्शन के अंत में सफल वापसी के बयान को रखना, और सशर्त ब्लॉक के अंदर नहीं।
- कार्यों और विधियों को निकालकर समग्र घोंसले के स्तर को कम करें।
यह सुनिश्चित करने की कोशिश करें कि महत्वपूर्ण कार्य कभी भी स्क्रीन के दाहिने किनारे पर दृष्टि की रेखा से बाहर नहीं जाते हैं। इस सिद्धांत का एक साइड इफेक्ट है: आप लाइनों की लंबाई के बारे में टीम के साथ व्यर्थ विवादों से बचेंगे।हर बार जब आप इंडेंट करते हैं, तो आप प्रोग्रामर के प्रमुखों के साथ एक और पूर्व शर्त जोड़ते हैं, जिससे उनके 7 memory 2 अल्पकालिक मेमोरी स्लॉट में से एक पर कब्जा हो जाता है। नेस्टिंग को गहरा करने के बजाय, फ़ंक्शन के सफल पथ को स्क्रीन के बाईं ओर के करीब रखने का प्रयास करें।अगर आपको लगता है कि कुछ धीरे चल रहा है, तो इसे एक बेंचमार्क साबित करें
अस्पष्टता के चेहरे पर अनुमान लगाने का मोह छोड़ दें।
पायथन 12 का ज़ेन
प्रोग्रामिंग गणित और तर्क पर आधारित है। ये दोनों अवधारणाएं शायद ही कभी भाग्य के तत्व का उपयोग करती हैं। लेकिन हम, प्रोग्रामर के रूप में, हर दिन कई धारणाएँ बनाते हैं। यह चर क्या करता है? यह विकल्प क्या करता है? अगर मैं यहाँ नील पास करूँ तो क्या होगा? यदि मैं दो बार रजिस्टर को कॉल करता हूं तो क्या होगा? आधुनिक प्रोग्रामिंग में, आपको बहुत कुछ ग्रहण करना होगा, विशेष रूप से अन्य लोगों के पुस्तकालयों का उपयोग करते समय।एपीआई का उपयोग करना आसान होना चाहिए और गलत तरीके से उपयोग करना मुश्किल है।
जोश बलोच
एक प्रोग्रामर की मदद करने के लिए सबसे अच्छे तरीकों में से एक मुझे पता है जब एपीआई बनाने के लिए मानक उपयोग विधियों पर ध्यान केंद्रित करना है । कॉलर को यथासंभव सामान्य ऑपरेशन करने में सक्षम होना चाहिए। हालांकि, इससे पहले कि मैंने बहुत कुछ लिखा और एपीआई को डिजाइन करने के बारे में बात की, इसलिए यहां रिकॉर्ड 12 की मेरी व्याख्या है: प्रदर्शन के विषय के बारे में अनुमान न लगाएं ।नुट की सलाह के प्रति आपके दृष्टिकोण के बावजूद, गो की सफलता का एक कारण इसके निष्पादन की प्रभावशीलता है। इस भाषा में प्रभावी कार्यक्रम लिखे जा सकते हैं, और इसके लिए धन्यवाद, लोग करेंगेजाओ चुनें। प्रदर्शन से जुड़ी कई गलत धारणाएं हैं। इसलिए, जब आप कोड प्रदर्शन में सुधार करने के तरीकों की तलाश कर रहे हैं, या "ठंडे बस्ते में डालने से रोकने के लिए", "सीजीओ महंगा है," या "हमेशा म्यूटेक्स के बजाय परमाणु संचालन का उपयोग करें" जैसे फॉर्च्यून-युक्तियों का पालन करें।पुराने कुत्ते के कारण अपने कोड को जटिल न करें। और अगर आपको लगता है कि कुछ धीरे-धीरे काम कर रहा है, तो पहले बेंचमार्क की मदद से इसे सुनिश्चित करें। गो के पास बढ़िया मुफ्त बेंचमार्किंग और प्रोफाइलिंग टूल हैं। अपने कोड के प्रदर्शन में अड़चन खोजने के लिए उनका उपयोग करें।गोरूटिन शुरू करने से पहले, पता करें कि यह कब बंद होगा
मुझे लगता है कि मैंने पीईपी -20 से मूल्यवान वस्तुओं को सूचीबद्ध किया है और शायद अच्छे स्वाद से परे उनकी व्याख्या का विस्तार किया है। यह अच्छा है, क्योंकि हालांकि यह एक उपयोगी बयानबाजी उपकरण है, हम अभी भी दो अलग-अलग भाषाओं के बारे में बात कर रहे हैं।जी, ओ, एक अंतरिक्ष, और फिर एक फ़ंक्शन कॉल लिखें। तीन बटन दबाता है, यह छोटा नहीं हो सकता। तीन बटन क्लिक, और आपने उपप्रकार लॉन्च किया।
रोब पाईक, सादगी जटिल है , dotGo 2015
अगले दो युक्तियां मैं गोरआउट्स को समर्पित करता हूं। गोर्यूटिन भाषा की एक विशिष्ट विशेषता है, उच्च-स्तरीय प्रतिस्पर्धा के लिए हमारी प्रतिक्रिया। उनका उपयोग करना बहुत आसान है: goऑपरेटर के सामने एक शब्द रखना और आप फ़ंक्शन को अतुल्यकालिक रूप से चलाते हैं। कोई निष्पादन सूत्र, कोई पूल निष्पादक, कोई आईडी नहीं, कोई पूर्ण स्थिति ट्रैकिंग नहीं।गोरीटिन सस्ते हैं। छोटी संख्या में निष्पादन थ्रेड्स (जो आपको प्रबंधित करने की आवश्यकता नहीं है) में मल्टीप्लेक्स गोरोइन्ट्स को रनटाइम वातावरण की क्षमता के कारण, आप आसानी से सैकड़ों हजारों या लाखों गोरआउट बना सकते हैं। यह आपको ऐसे आर्किटेक्चर बनाने की अनुमति देता है जो निष्पादन के धागे या इवेंट कॉलबैक के रूप में अन्य प्रतिस्पर्धी मॉडल का उपयोग करते समय अव्यावहारिक होगा।लेकिन गोरक्षक कितने भी सस्ते क्यों न हों, वे आजाद नहीं थे। उनके स्टैक में कम से कम कुछ किलोबाइट होते हैं। और जब आपके पास लाखों गोरआउट होते हैं, तो यह ध्यान देने योग्य हो जाता है। मेरे कहने का मतलब यह नहीं है कि आपको लाखों गोरोइन का उपयोग करने की आवश्यकता नहीं है, अगर वास्तुकला आपको इस ओर धकेलती है। लेकिन अगर आप इसका उपयोग करते हैं, तो उनकी निगरानी करना बेहद जरूरी है, क्योंकि इतनी मात्रा में गोरोइन बहुत सारे संसाधनों का उपभोग कर सकते हैं।गोरीटाइन गो में स्वामित्व का मुख्य स्रोत हैं। उपयोगी होने के लिए, गोरोइन को कुछ करना चाहिए। यही है, लगभग हमेशा इसमें एक संसाधन का लिंक होता है, वह है, स्वामित्व जानकारी: लॉक, नेटवर्क कनेक्शन, चैनल के अंत में भेजने वाले डेटा बफर। जब गोरोइनिन रहता है, तो ताला आयोजित किया जाता है, कनेक्शन खुला रहता है, बफर सहेजा जाता है, और चैनल प्राप्तकर्ता नए डेटा की प्रतीक्षा करेंगे।संसाधनों को मुक्त करने का सबसे सरल तरीका उन्हें गोरोइन जीवन चक्र से जोड़ना है। जब यह पूरा हो जाता है, तो संसाधनों को मुक्त कर दिया जाता है। और चूंकि गोरोइन चलाना बहुत आसान है, इससे पहले कि आप "गो और स्पेस" लिखें, सुनिश्चित करें कि आपके पास इन सवालों के जवाब हैं:- गोरोइन किस स्थिति में रुकता है? गो गोरेइन को समाप्त करने के लिए नहीं कह सकता। किसी विशिष्ट कारण से, रुकने या बाधित होने का कोई कार्य नहीं है। हम गोरक्षकों को रोकने का आदेश नहीं दे सकते, लेकिन हम विनम्रता से पूछ सकते हैं। यह लगभग हमेशा चैनल के संचालन से संबंधित होता है। जब यह बंद हो जाता है, तो चैनल से बाहर निकलने के लिए रेंज को लूप किया जाता है। चैनल बंद करते समय, आप इसे चुन सकते हैं। एक बंद चैनल के रूप में एक गोरोइन से दूसरे में संकेत सबसे अच्छा व्यक्त किया जाता है।
- ? , , : ?
- , ? , - . , . . , .
संभवतः आपके किसी भी गंभीर गो कार्यक्रम में, संगामिति का उपयोग किया जाता है। यह अक्सर एक कार्यकर्ता पैटर्न की समस्या की ओर जाता है - प्रति कनेक्शन एक गोरोइन।एक प्रमुख उदाहरण नेट / http है। सुनने वाले सॉकेट के मालिक सर्वर को रोकना काफी सरल है, लेकिन इस सॉकेट द्वारा उत्पन्न होने वाले गोरआउट के बारे में क्या? net / http अनुरोध ऑब्जेक्ट के अंदर एक संदर्भ ऑब्जेक्ट प्रदान करता है जिसका उपयोग श्रोता को यह बताने के लिए किया जा सकता है कि अनुरोध को रद्द करने की आवश्यकता है, और इसलिए गोरोइन को बाधित करें। लेकिन यह स्पष्ट नहीं है कि यह कैसे पता लगाया जाए कि यह सब कब करना है। कॉल करना एक बात है context.Cancel, यह जानना कि रद्द करना पूरा हो गया है।मुझे अक्सर नेट / http के साथ गलती लगती है, लेकिन इसलिए नहीं कि यह खराब है। इसके विपरीत, यह गो कोडबेस में सबसे सफल, सबसे पुराना और सबसे लोकप्रिय एपीआई है। इसलिए, इसकी वास्तुकला, विकास और दोषों का सावधानीपूर्वक विश्लेषण किया जाता है। इस चापलूसी पर विचार करें, आलोचना नहीं।इसलिए, मैं अच्छे अभ्यास के जाल के रूप में नेट / http लाना चाहता हूं। चूंकि प्रत्येक कनेक्शन को प्रकार के अंदर बनाए गए गोरआउट द्वारा संसाधित किया जाता है, इसलिए net/http.Serverनेट / http पैकेज के बाहर का प्रोग्राम प्राप्त सॉकेट द्वारा बनाए जाने वाले गोरआउट्स को नियंत्रित नहीं कर सकता है।वास्तुकला का यह क्षेत्र अभी भी विकसित हो रहा है। आप गो डेवलपमेंट टीम के गो run.Group-किट या एर्रग्रुप को याद कर सकते हैं , जो एसिंक्रोनस रूप से निष्पादित कार्यों के निष्पादन, रद्द करने और प्रतीक्षा करने के लिए एक रूपरेखा प्रदान करता है।उन सभी के लिए जो कोड लिखते हैं जिन्हें अतुल्यकालिक रूप से निष्पादित किया जा सकता है, आर्किटेक्चर बनाने का मुख्य सिद्धांत यह है कि गोरोनाइट चलाने की जिम्मेदारी कॉलर को स्थानांतरित की जानी चाहिए। उसे चुनने दें कि वह कैसे चलाना चाहता है, ट्रैक करें और अपने कार्यों के पूरा होने की प्रतीक्षा करें।अपने पैकेज एपीआई के व्यवहार को अवरुद्ध करने के लिए परीक्षण लिखें
आप उम्मीद कर सकते हैं कि इस लेख में मैं परीक्षण का उल्लेख नहीं करूंगा। क्षमा करें, कुछ और समय।आपके परीक्षण इस बात पर एक समझौता है कि आपका कार्यक्रम क्या करता है और क्या नहीं करता है। यूनिट परीक्षणों को पैकेज स्तर पर अपने एपीआई के व्यवहार को अवरुद्ध करना चाहिए। टेस्ट कोड के रूप में वर्णन करते हैं कि पैकेज क्या करने का वादा करता है। यदि प्रत्येक इनपुट रूपांतरण के लिए एक इकाई परीक्षण होता है, तो आप, कोड के रूप में , और दस्तावेज़ीकरण नहीं, कोड क्या करेगा पर एक समझौते को परिभाषित किया है।इस समझौते को मंजूरी देना परीक्षण लिखने जितना ही सरल है। किसी भी चरण में, आप कर सकते हैं राज्य आत्मविश्वास के एक उच्च डिग्री के साथ व्यवहार है कि लोगों पर भरोसा करने से पहले किए गए बदलाव किए गए परिवर्तनों के बाद समारोह के लिए जारी रहेगा कि।टेस्ट एपीआई व्यवहार को अवरुद्ध करते हैं। सार्वजनिक एपीआई को जोड़ने, बदलने या हटाने वाले किसी भी परिवर्तन में परीक्षणों में परिवर्तन शामिल होना चाहिए।संयम एक गुण है
गो केवल 25 कीवर्ड के साथ एक सरल भाषा है। एक तरह से, यह भाषा में निर्मित सुविधाओं पर प्रकाश डालता है। ये ऐसी विशेषताएं हैं जो भाषा को खुद को बढ़ावा देने की अनुमति देती हैं: सरल प्रतियोगिता, संरचनात्मक टाइपिंग, आदि।मुझे लगता है कि हम सभी एक बार में गो की सभी विशेषताओं का उपयोग करने की कोशिश करके भ्रमित हैं। चैनलों के उपयोग से आप में से कितने लोग इतने प्रेरित हुए थे कि आप उन्हें जहाँ भी इस्तेमाल कर सकते थे? मुझे पता चला कि परिणामी कार्यक्रमों का परीक्षण करना मुश्किल है, वे नाजुक और बहुत जटिल हैं। और आप?गोरोनेस के साथ मेरा भी यही अनुभव था। काम को छोटे टुकड़ों में विभाजित करने की कोशिश करते हुए, मैंने गोरोइनिन का अंधेरा बनाया, जिसे नियंत्रित करना मुश्किल था, और इस तथ्य को पूरी तरह से खो दिया कि उनमें से ज्यादातर हमेशा काम पूरा करने के लिए अपने पूर्ववर्तियों की उम्मीद के कारण अवरुद्ध थे। कोड पूरी तरह से सुसंगत था, और मुझे एक छोटा लाभ प्राप्त करने के लिए जटिलता को बढ़ाना पड़ा। आपमें से कितने लोगों ने इसका सामना किया है?मैं एम्बेडिंग के साथ भी ऐसा ही था। पहले तो मैंने इसे विरासत में उलझा दिया। फिर वह एक नाजुक आधार वर्ग की समस्या में भाग गया, कई जटिल प्रकारों को मिलाकर जो पहले से ही कई कार्यों को और भी अधिक जटिल विशाल प्रकारों में मिला रहा था।यह कम से कम प्रभावी सलाह हो सकती है, लेकिन मैं इसका उल्लेख करना महत्वपूर्ण मानता हूं। सलाह समान है: संयम रखें, और गो की क्षमताएं कोई अपवाद नहीं हैं। जब भी संभव हो, goroutines, चैनल, एम्बेडिंग संरचनाएं, अनाम फ़ंक्शंस, पैकेजों की एक बहुतायत और इंटरफेस का उपयोग न करें। स्मार्ट की तुलना में सरल समाधान का उपयोग करें।रखरखाव के मामलों में आसानी
अंत में, मैं आपको PEP-20 से एक और प्रविष्टि दूंगा:पठनीयता मायने रखती है।
पायथन का ज़ेन, रिकॉर्ड 7
सभी प्रोग्रामिंग भाषाओं में कोड पठनीयता के महत्व के बारे में बहुत कुछ कहा गया है। गो को बढ़ावा देने वाले लोग सादगी, पठनीयता, स्पष्टता, उत्पादकता जैसे शब्दों का उपयोग करते हैं। लेकिन ये सभी एक अवधारणा के पर्याय हैं - रखरखाव की सुविधा।वास्तविक लक्ष्य कोड बनाना है जिसे बनाए रखना आसान है। वह कोड जो लेखक को रेखांकित करता है। एक कोड जो न केवल समय के निवेश के रूप में, बल्कि भविष्य के मूल्य प्राप्त करने के आधार के रूप में मौजूद हो सकता है। इसका मतलब यह नहीं है कि पठनीयता महत्वपूर्ण नहीं है, बस रखरखाव की सुविधा अधिक महत्वपूर्ण है ।गो उन भाषाओं में से एक नहीं है जो एकल-लाइन कार्यक्रमों के लिए अनुकूलित हैं। और उन भाषाओं में से एक नहीं जो न्यूनतम लाइनों वाली कार्यक्रमों के लिए अनुकूलित हैं। हम डिस्क पर स्रोत कोड के आकार के लिए, या संपादक में प्रोग्राम लिखने की गति के लिए अनुकूलन नहीं करते हैं। हम अपने कोड को ऑप्टिमाइज़ करना चाहते हैं ताकि पाठकों के लिए यह अधिक समझ में आए। क्योंकि यह वो है जिसे उसके साथ रहना होगा।यदि आप अपने लिए एक कार्यक्रम लिखते हैं, तो शायद यह केवल एक बार लॉन्च किया जाएगा, या आप केवल एक ही हैं जो इसका कोड देखते हैं। इस मामले में, कुछ भी करें। लेकिन अगर एक से अधिक व्यक्ति कोड पर काम करता है, या यदि इसका उपयोग लंबे समय तक किया जाता है और आवश्यकताएं, क्षमताएं या रनटाइम बदल सकते हैं, तो प्रोग्राम को बनाए रखने के लिए सुविधाजनक होना चाहिए। यदि सॉफ़्टवेयर को बनाए नहीं रखा जा सकता है, तो इसे फिर से नहीं लिखा जा सकता है। और यह आखिरी बार हो सकता है जब आपकी कंपनी गो में निवेश करती है।आपके जाने के बाद साथ देने के लिए आप जिस पर मेहनत करते हैं वह सुविधाजनक होगा? आज के बाद आने वालों के लिए आप अपने कोड के रखरखाव की सुविधा कैसे दे सकते हैं?