बॉब मार्टिन की क्लीन कोड बुक के बारे में

(चित्र एक संकेत नहीं है, मैं वास्तव में लेख में एक बिल्ली जोड़ना चाहता था! आखिरकार, यह इंटरनेट पर लोकप्रियता की मुख्य गारंटी है, है ना? :)?

मेरे पास रॉबर्ट मार्टिन की पुस्तकों के लिए बहुत ही मिश्रित दृष्टिकोण है ... उनके पास काफी समझदार और दिलचस्प विचार हैं, लेकिन कभी-कभी उन्हें इतने स्पष्ट रूप से व्यक्त किया जाता है कि उन्हें एक नाजुक प्रोग्रामर मस्तिष्क द्वारा गलत तरीके से माना जा सकता है। यदि पाठक का मस्तिष्क व्यावहारिक रूप से सलाह लेने के लिए पर्याप्त मजबूत है, तो हर मौका है कि वह (मस्तिष्क या प्रोग्रामर) कुछ भी नया नहीं करेगा।


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

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

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

विवादास्पद और संदिग्ध क्षण

क्लीन कोड में कई स्पष्ट रूप से संदिग्ध बिंदु हैं। सबसे पहले, इसमें बहुत सारे कोड होते हैं, जो एक पुस्तक के पन्नों पर पढ़ना बहुत मुश्किल है। अध्याय 15 में 60 पृष्ठों पर कमांड लाइन पार्सर में सुधार की चर्चा की गई है, जिनमें से 40 ठोस जावा कोड हैं। अध्याय 16-17 एक ही प्रारूप में लिखे गए हैं, लेकिन वे छोटे हैं, इसलिए लेखक के तर्क का पालन करना आसान है।

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

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

लेकिन इन सबसे, मैं लेखक के अस्पष्ट रवैये से लेकर राज्य और दुष्प्रभावों तक से भ्रमित हूं।

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

इस सलाह के बावजूद, कई उदाहरणों में लेखक साइड इफेक्ट्स के साथ कोड का उपयोग करता है और सभी तरीकों से तर्कों का उपयोग करके हतोत्साहित करता है, इसके बजाय ऑब्जेक्ट की स्थिति का उपयोग करता है:

private String render(boolean isSuite) /*throws Exception*/ { this.isSuite = isSuite; if (isTestPage()) includeSetupAndTeardownPages(); return pageData.getHtml(); } private void includeSetupAndTeardownPages() throws Exception { includeSetupPages(); includePageContent(); includeTeardownPages(); updatePageContent(); } private void includeSetupPages() /*throws Exception*/ { if (isSuite) includeSuiteSetupPage(); includeSetupPage(); } 

संदेहपूर्ण परिषद
... तर्क परीक्षण के संदर्भ में बहुत सारी समस्याएं पैदा करते हैं। जरा कल्पना करें कि सभी परीक्षण लिपियों को संकलित करना कितना कठिन है जो यह सत्यापित करता है कि कोड तर्कों के सभी संयोजनों के साथ सही ढंग से काम करता है।

चार तर्कों के साथ एक स्थिर विधि और चार क्षेत्रों के साथ किसी वस्तु की आवृत्ति विधि के बीच परीक्षण के संदर्भ में क्या अंतर है? दोनों स्थितियों में सीमा की स्थिति समान है; बस पहले मामले में, हम स्पष्ट रूप से और इसके माध्यम से दूसरे मामले में, सभी इनपुट डेटा को स्पष्ट रूप से खींच रहे हैं।

पुस्तक में कोडिंग शैली पर बहुत ध्यान दिया गया है, जबकि अधिकांश युक्तियां काफी उचित हैं। लेकिन बहुत अस्पष्ट भी हैं:

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

अनुवाद

अनुवाद, इसे हल्के ढंग से करने के लिए, कृपया नहीं। कभी-कभी वह इतना "प्रसन्न" हो जाता है कि उसे यह समझने के लिए मूल में जाना पड़ता है कि क्या कहा जा रहा है:

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

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

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

चूंकि पुस्तक की सामग्री अपेक्षाकृत सरल है, इसलिए अनुवादक केवल छाप को "खराब" करने में सक्षम थे, लेकिन इसे पूरी तरह से खराब नहीं किया।

अच्छी सलाह है

वास्तव में, सब कुछ इतना बुरा नहीं है और "चाचा" बॉब साथी बहुत अच्छी सलाह देते हैं। यहाँ उनमें से कुछ हैं:

नामकरण के बारे में
कार्यान्वयन की जानकारी देने वाले नामों का उपयोग न करें। नाम को अमूर्त के स्तर को प्रतिबिंबित करना चाहिए जिस पर वर्ग या फ़ंक्शन काम करता है।

कोड समझ के बारे में
कोड लिखना आसान है जो अपने लिए समझ में आता है, क्योंकि लेखन के समय, हम हल की जा रही समस्या को गहराई से समझते हैं। अन्य प्रोग्रामर जो इस कोड को बनाए रखेंगे उन्हें यह समझ नहीं होगी।

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

फ़ंक्शन सामग्री के बारे में
फ़ंक्शन के सभी ऑपरेटरों को अमूर्तता के समान स्तर पर होना चाहिए, जो फ़ंक्शन के नाम से वर्णित ऑपरेशन की तुलना में एक स्तर कम होना चाहिए।

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

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

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

सलाह का एक टुकड़ा बहुत खुश है। चलो बस: जादू निरंतर 5280 आपको क्या बताता है? कुछ भी नहीं है? लेखक के अनुसार अजीब बात है, यह उन अर्थों में से एक है जो आसानी से "हार्डकोड" हो सकते हैं!

कुछ संख्याएं इतनी आसानी से पहचानी जा सकती हैं कि उन्हें नामांकित स्थिरांक के पीछे छिपाना नहीं पड़ता - बशर्ते कि उनका उपयोग स्पष्ट कोड के साथ किया जाता है। ... ५२ The० - मील प्रति फीट की संख्या - इतनी अच्छी तरह से ज्ञात और अद्वितीय है कि पाठक तुरंत इसे पहचान लेंगे, भले ही यह किसी भी संदर्भ के बाहर स्थित हो।

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

प्लसस : सभ्य सुझावों की एक सभ्य राशि

नुकसान : कुछ युक्तियां अत्यधिक विवादास्पद हैं; कभी-कभी सलाह असंगत होती है; अनुवाद दोनों पैरों पर लंगड़ा है।

रेटिंग : 4-