क्लीन कोड: एक एजाइल सॉफ्टवेयर क्राफ्ट्समैनशिप हैंडबुक

स्वच्छ कोड: एजाइल सॉफ्टवेयर क्राफ्ट्समैनशिप की एक पुस्तिका
Robert C. Martin
श्रेणियाँ: प्रोग्रामिंग
प्रकाशन वर्ष: 2010
पढ़ाई का वर्ष: 2020
मेरा मूल्यांकन: अच्छा
पढ़ने की संख्या: 2
कुल पृष्ठ: 466
सारांश (पृष्ठ): 0
प्रकाशन की मूल भाषा: अंग्रेजी
अन्य भाषाओं में अनुवाद: रूसी, स्पेनिश, पुर्तगाली, चीनी

सामान्य जानकारी

यह किताब प्रोग्रामिंग के प्रचारक और अनुभवी डेवलपर रॉबर्ट मार्टिन द्वारा लिखी गई है। यह किताब इस बारे में है कि कैसे बेहतर और सही तरीके से साफ और सटीक कोड लिखा जाए। हम संक्षेप में इस किताब का अवलोकन करेंगे।

अध्यायों का संक्षिप्त अवलोकन

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

इसके बाद, यह बताया जाता है कि चर (variables) को बेहतर तरीके से कैसे नामित किया जाए: यह कि उन्हें प्रोग्रामर के इरादों को व्यक्त करना चाहिए, और चर को पढ़ते समय यह पहले से स्पष्ट होना चाहिए कि उसमें क्या संग्रहीत है और किस प्रकार का डेटा है। कहा जाता है कि ऐसे अमूर्त नामों से बचना चाहिए जैसे कि List, Data आदि। इसके बाद, विधियों और कक्षाओं (methods and classes) के नामकरण पर संक्षेप में चर्चा की जाती है — हालांकि यह अन्य अध्यायों का विषय है, और लेखक इसे नीचे और अधिक विस्तार से समझाएंगे। कई सुझाव दिए गए हैं, जिनमें से अधिकांश पूरी तरह से तार्किक और स्वस्थ हैं। एक तरफ यह एक साधारण और स्पष्ट अध्याय है, लेकिन दूसरी तरफ यह शुरुआत करने वालों के लिए बहुत उपयोगी हो सकता है।

इसके बाद, हम फ़ंक्शंस पर आते हैं। यहां सबसे अधिक बहस वाले विषय शुरू होते हैं — कि एक फ़ंक्शन को कितनी पंक्तियों का होना चाहिए, और उसमें कितने पैरामीटर होने चाहिए। निश्चित रूप से, इसका उत्तर स्पष्ट है: जितना छोटा और सरल फ़ंक्शन होगा, उतना बेहतर। हालांकि, व्यावहारिक रूप से ऐसा हमेशा नहीं होता। इसके अलावा, एक पूरी तरह से तार्किक और स्वस्थ विचार है कि एक फ़ंक्शन को केवल एक विशिष्ट कार्य ही करना चाहिए। यानी, उदाहरण के लिए, एक फ़ंक्शन को न केवल औसत (average) निकालना चाहिए, बल्कि परिणाम को स्क्रीन पर भी प्रदर्शित करना चाहिए। यह SOLID सिद्धांतों जैसा है। इसके अलावा, इस अध्याय में लेखक शर्तों (if, else, switch), लूप्स, try/catch संरचना के साथ काम करने के बारे में सुझाव देते हैं। निश्चित रूप से, उन्होंने फ़ंक्शंस के नामकरण और DRY (कोड को दोहराने से बचने) के सिद्धांतों को भी छुआ है।

फ़ंक्शंस के बाद, एक और विवादास्पद विषय आता है — टिप्पणियाँ: उन्हें कहां और कैसे डाला जाए, और कहां वे बिल्कुल अवांछनीय हो सकती हैं। कानूनी, पत्रिका और कुछ अन्य प्रकार की टिप्पणियों को लेखक ने समझाया है, और दिखाया है कि वे वास्तव में कहां उपयुक्त हैं।

अगर आप सोचते हैं कि टिप्पणियों का विषय विवादास्पद है, तो आप फ़ॉर्मेटिंग के बारे में क्या कहेंगे? यह छोटा सा अध्याय टिप्पणियों के बाद आता है। और अगर ऐसा लगता है कि बात केवल टैब्स और स्पेस के बारे में होगी — तो ऐसा नहीं है। यह अध्याय कहीं अधिक सूचनापूर्ण है। लेखक विभिन्न ग्राफ़िक्स भी प्रदान करते हैं।

"ऑब्जेक्ट्स और डेटा संरचनाओं के साथ काम करना" — यही अगला अध्याय का नाम है। एब्स्ट्रैक्शन, डेटा असममितता, डेमेट्री का कानून, DTO, सक्रिय रिकॉर्ड (Active Record) और कुछ अन्य विषयों को इस छोटे से अध्याय में समझाया गया है। यह संक्षेप में समझाया गया है, और ध्यान इस पर केंद्रित है कि प्रोग्रामर इन अवधारणाओं से पहले से परिचित है।

इसके बाद, त्रुटियों (errors) का विश्लेषण करने वाला अध्याय आता है। इस किताब के कई उदाहरण Java में हैं, इसलिए आप Golang की शैली में त्रुटियों को संभालने को नहीं देखेंगे (if के माध्यम से), बल्कि मुख्य रूप से try/catch पर ध्यान दिया गया है। अगर कुछ अध्याय पहले फ़ॉर्मेटिंग पर चर्चा कर रहे थे, तो अब त्रुटियों की हैंडलिंग के बारे में चर्चा की जाएगी।

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

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

फिर आता है "कक्षाएँ" (Classes)। फिर से, यदि आप कक्षाओं को कोड को सुधारने के हिस्से के रूप में देखते हैं (जैसा कि डॉ. बоб करते हैं), तो इस खंड में सामग्री पर्याप्त हो सकती है। लेकिन यह तब तक है, जब तक डेवलपर्स OOP से परिचित हैं। अन्यथा, यदि आप ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग को गहरे से अध्ययन करना चाहते हैं, तो यह खंड शायद बहुत सूचनापूर्ण या कठिन हो सकता है।

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

इसके बाद आता है मल्टीथ्रेडिंग का अध्याय। यह ज्यादातर सिद्धांत है, व्यावहारिकता से ज्यादा: कोड कम है, मुख्य रूप से सैद्धांतिक सामग्री है, और वह भी केवल सतही स्तर पर।

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

अंतिम अध्याय एक तरह का सारांश है, जो उन सभी सुझावों का संकलन है जिनकी चर्चा पहले की गई थी: टिप्पणियों से लेकर फ़ंक्शंस और परीक्षणों तक।

निष्कर्ष

किताब के फायदे

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

किताब के नुक्सान

  1. सभी सुझावों को अंधाधुंध पालन नहीं करना चाहिए। कम से कम कुछ थे, या शायद कई "सुझाव", जिनसे मैं पूरी तरह से सहमत नहीं था या बिलकुल भी सहमत नहीं था।
  2. किताब खुद छोटी नहीं है — 450 पृष्ठों से थोड़ा अधिक। और बड़ी किताबें पढ़ना कई लोगों के लिए आसान नहीं होता।
  3. कोड सुधारने के उदाहरण (पंक्तियाँ जोड़ने और हटाने) को बेहतर तरीके से प्रस्तुत किया जा सकता था। वर्तमान में, परिवर्तन केवल बोल्ड (जोड़ा गया) और स्ट्राइकथ्रू (हटाया गया) के रूप में दिखाए गए हैं, शायद git-클ाइंट्स की शैली में प्रस्तुति अधिक आदतवाली होती।
  4. उदाहरण के रूप में Java का उपयोग किया गया है। मुझे इस पर कोई आपत्ति नहीं है और मुझे समझने में कोई कठिनाई नहीं हुई, लेकिन जो लोग इस भाषा से परिचित नहीं हैं, उनके लिए यह एक नकारात्मक हो सकता है।
  5. मुझे 2010 में प्रकाशित किताब मिली थी। शायद इसके अधिक ताजगी से पुनः प्रकाशित संस्करण हों। मैंने जो किताब पढ़ी, वह थोड़ा पुरानी हो चुकी है। इसे केवल अद्यतन करने की आवश्यकता नहीं थी, बल्कि इसे और भी बेहतर बनाया जाना चाहिए था।

कुल मिलाकर निष्कर्ष

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

Вверх