कोड में रिब्यूज़, और उन्हें डिक्रिप्ट कैसे करें। सीक्रेट पॉवर ऑफ़ आइडेंटिफ़ायर

शुद्ध कोड अच्छी तरह से लिखे गए गद्य की तरह पढ़ता है।
स्वच्छ संहिता में ग्रैडी बुच

कोड के रूप में रिबास

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

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

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

यहाँ है कैसे पहेलियाँ पढ़ें:

कोड एक रिब्यू की तरह है

रिब्यू के साथ प्रोग्राम कोड में कुछ समान है: इसका अपना "क्या" और "कैसे" भी है। और इसे कभी-कभी डिक्रिप्ट भी करना पड़ता है।

किसी कोड का "क्या" उसका उद्देश्य, अर्थ, वह प्रभाव और अंतिम परिणाम है जो हम उससे उम्मीद करते हैं। वह वास्तव में क्या कर रहा है

"कोड के" कैसे - किस ठोस तरीके से यह अपने "क्या" को पूरा करेगा, क्या विशिष्ट असाइनमेंट, गुणन, तुलना के साथ; एल्गोरिथ्म का कार्यान्वयन, प्रोसेसर को निर्देश। यह एक अनुमत कोड भाषा है, इसका अर्थ अर्थपूर्ण अर्थ है।

मार्टिन फाउलर इसके बारे में इस तरह से बात करता है ( "फंक्शन लेंथ" , मूल ):

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

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

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

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

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

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

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

यहां तक ​​कि प्रत्येक रिब्यू से एक छोटा सा लोड एक समस्या में बदल सकता है अगर ऐसे कई रिब्यूज हों। आप शायद उस कोड के पार आ गए हैं जिसका पढ़ना बस समाप्त हो रहा है। जानें: कोड में विद्रोह आपकी थकान के लिए जिम्मेदार हैं। Rebuse कोड लेखन की प्रक्रिया में सीधे अपने स्वयं के लेखक की थकान को बढ़ाता है। आखिरकार, कोड लिखते समय, प्रोग्रामर भी लगातार पढ़ता है कि क्या लिखा गया था। इस तथ्य के बावजूद कि लेखक अपनी खुद की पहेली को डिक्रिप्ट नहीं करता है, लेकिन बस याद रखता है, वे अभी भी एक लोड बनाते हैं। जाल यह है कि लेखक केवल अपने कोड में पहेलियाँ नहीं देखता है ! शाम को अपने कोड में पहेली से छुटकारा पाने के लिए शुरू करने पर आप शाम को कितना मानसिक प्रयास कर सकते हैं, यह कल्पना करने की कोशिश करें!

इसलिए, लिखने और पढ़ने के कोड से थकान को कम करने के लिए, आपको पहेलियाँ से बचने की आवश्यकता है। लेकिन यह कैसे करें?

कोड की भाषा। पहचानकर्ता शक्ति

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

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

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

रीबस न होने के लिए कोड में कौन से उपकरण हैं?

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

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

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

जब चर और विधियों का नाम अच्छी तरह से चुना जाए तो कोड की पंक्तियों को पढ़ना कितना आसान है:

pageData.hasAttribute("Test") dom_tree.to_html() emails_str.split(',') 

इन छोटे वाक्यांशों को देखते हुए, यह समझना आसान है कि वे किस बारे में बात कर रहे हैं। हमें पता है कि हमें क्या परिणाम मिलता है, क्योंकि पहचानकर्ता हमें इसके बारे में बताते हैं। अब कल्पना करें कि प्रत्येक कॉल के स्थान पर इसका कार्यान्वयन है - ऐसे "एन्क्रिप्टेड" कोड की रीडिंग स्पीड कितनी घट जाएगी?

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

रीबस विधि

जब मैंने प्योर कोड पढ़ा, तो मुझे समय-समय पर विचार आया: "व्हाट द हेल!"।

अपने 40 साल के अनुभव की ऊंचाई से, रॉबर्ट मार्टिन ने हमें कोड को बेहतर बनाने के टिप्स दिए। उदाहरण के लिए:

पहला नियम: फ़ंक्शंस कॉम्पैक्ट होना चाहिए। दूसरा नियम: फ़ंक्शन और भी अधिक कॉम्पैक्ट होना चाहिए।

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

और बॉब प्रत्येक फ़ंक्शन को लिखने की पेशकश भी करता है ताकि वह केवल एक ऑपरेशन करे। इसके अलावा, यह एक ऑपरेशन क्या है - यह भी बहुत स्पष्ट नहीं है। हमें अमूर्तता के एकल स्तर के सिद्धांत की मदद करने के लिए कॉल करना होगा, जो स्थिति को और अधिक भ्रमित करता है। यह सब बहुत धूमिल है।

मार्टिन फाउलर अधिक व्यावहारिक हैं।

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

मूल

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

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

किसी भी मामले में आपको आँख बंद करके रीफैक्टरिंग विधियों को लागू नहीं करना चाहिए। यह बहुत स्पष्ट है, लेकिन कैसे समझना चाहिए कि जब वास्तव में रिफैक्टिंग की आवश्यकता होती है, और कब नहीं? रिब्यूस विधि कहती है: यदि रीफैक्टरिंग के बाद, रिब्यूस गायब नहीं होता है, तो रीफैक्टरिंग की आवश्यकता नहीं है ।

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

कोड में पहेलियाँ डिकोड करने का एक उदाहरण (बहुत सफल नहीं)

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

रिफैक्टिंग लेखक ने मानव-पठनीय पहचानकर्ताओं (वर्ग के नाम, तरीके और चर) को पूरी तरह से लागू करने के लिए संकेत दिया कि कोड वास्तव में क्या करता है। यह एक दया है कि हर जगह यह सफलतापूर्वक नहीं निकला, और कुछ जगहों पर पिछली पहेलियों के बजाय नई पहेलियां दिखाई दीं।

उदाहरण के लिए, इस मार्ग में सबसे अधिक इस्तेमाल की जाने वाली विधि शामिल करें

 private void include(String pageName, String arg) throws Exception { WikiPage inheritedPage = findInheritedPage(pageName); if (inheritedPage != null) { String pagePathName = getPathNameForPage(inheritedPage); buildIncludeDirective(pagePathName, arg); } } 

नाम बिल्कुल भी प्रतिबिंबित नहीं करता है कि कार्यान्वयन में क्या हो रहा है। क्या और कहाँ शामिल हैं?

इस विधि के लिए कॉल को देखते हुए:

 include("TearDown", "-teardown"); 

यह कहना असंभव है कि कोड का लेखक किस परिणाम को प्राप्त करने जा रहा है।

अगला: buildIncludeDirective क्या करता है? नाम से देखते हुए, उसे किसी प्रकार का समावेश निर्देश तैयार करना चाहिए, और इसलिए क्या? उसे वापस लाओ? लेकिन नहीं। वह इसे समग्र परिणाम में जोड़ देता है।

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

 pageData.setContent(newPageContent.toString()); 

गुप्त अद्यतन से बहुत स्पष्ट है

एक मनोरंजन के रूप में, मैं पाठकों को सुझाव देता हूं कि वे देखें कि अन्य खराब स्थान रिफैक्टेड कोड में क्या हैं।

बॉब को सही ठहराने के लिए, मैं कह सकता हूं कि यह कोड अब फिटनैस के मौजूदा संस्करण में नहीं है। जाहिर है, बदले में, वह भी, एक बार refactored था।

निष्कर्ष

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

अच्छे कोड को प्रोग्रामर के सवालों के जवाब देने चाहिए - वह (कोड) यहाँ क्यों है, वह यहाँ क्या कर रहा है, वह परिणाम प्राप्त कर रहा है। ये उत्तर केवल पहचानकर्ताओं का उपयोग करके दिए जा सकते हैं।

कोड किस तरह के उत्तर नहीं देना चाहिए, इसका एक उदाहरण के रूप में, मैं एक मजेदार पुस्तक से एक अंश देना चाहता हूं।

"मैं रोनन, विक्टर ऑफ एविल हूं," उन्होंने धीरे से कहा। - और यह टैरल है। हम आपको कुछ चाहते हैं
प्रश्न पूछें। अगर तुम झूठ बोलते हो, तुम मर जाते हो। मिल गया
", चाचा, हमेशा के लिए," उन्होंने सांस ली। - कृपया। मैं यह सब कहूँगा
"यह अच्छा है," रोनन ने जारी रखा। - नाम?
- रोनन, एविल के विजेता।
- हाँ, मेरा नहीं, बेवकूफ!
"आह, हाँ, तो टारले," ऑर्को ने माफी मांगी।
- और मेरा नहीं! मुड़े हुए टारले। - आपका नाम, क्लब! पहला नाम!
"नाम वह नाम है जिसका उपयोग मैं खुद को दूसरों से अलग करने के लिए करता हूं," ऑर्क ने कहा।
- अच्छा, यह नाम यहाँ दें! यल तरल।
ओर्का अचानक बौखला गया।
- आह! दाना!
"तो दाना, तुम यहाँ क्या कर रहे हो?"
"मैंने इसे अपनी पैंट में डाल दिया," सच जवाब आया।
रोनेन ने घृणा में अपनी नाक सिकोड़ ली।
"नहीं, मैं पूछता हूं कि आपका orcs का गिरोह यहां क्या कर रहा है!"
पिंपल की आँखें तेजी से चारों ओर घूम गईं, दृश्य के चारों ओर।
उन्होंने कहा, "ज्यादातर लोग यहां बिना सिर के हैं।"
टार्ले ने रोनन को कंधे पर छुआ।
"मुझे कोशिश करने दो," उसने आत्मविश्वास से कहा और भयभीत orc की ओर मुड़ गया। - मुझे बताओ,
दाना, "वह जारी रखा," आप यहाँ क्यों हैं?
- ओह, चाचा, और मत पूछो। मेरे लिए अस्तित्ववादी दर्शन सिर्फ एक अंधेरा जंगल है।
"सुनो, तुम ड्रैगन burp," वह muffledly बढ़ी। - आपका orcs का गिरोह एक विशेष था
यहाँ आने का कारण क्या है, जंगल में?
- बहुत सारे पेड़ हैं।
रोनन की आँखें डबडबा आईं और टार्ले पलट गया। दाना, यह महसूस करते हुए कि इसने वह उत्तर नहीं दिया है जो अपेक्षित था, आगे गुनगुनाने लगा।
- और यदि आप कारण के बारे में जानना चाहते हैं, और जंगल के बारे में नहीं, तो यह सब है क्योंकि वह व्यक्ति पब में है
हमें यहां आने और तुम्हें मारने के लिए भुगतान किया।
जेम्स बिब्बी, रोनन द बार्बेरियन