क्लीन कोड vs. सॉफ़्टवेयर डिज़ाइन दर्शन

• Robert “Uncle Bob” Martin और John Ousterhout के बीच सितंबर 2024 से फ़रवरी 2025 तक चली सॉफ़्टवेयर डिज़ाइन पर बातचीत
• दोनों ने सॉफ़्टवेयर डिज़ाइन पर पुस्तकें लिखी हैं
• तीन मुख्य विषयों (मेथड की लंबाई, टिप्पणियाँ, Test-Driven Development) पर दोनों के विचार अलग थे
• बातचीत का केंद्र कोड की जटिलता कम करने, पठनीयता बढ़ाने, और उपयुक्त तरीके से टेस्ट लिखने पर था

मेथड की लंबाई

• Uncle Bob (आगे UB) ने इस रुख पर ज़ोर दिया कि “छोटे फ़ंक्शन बेहतर होते हैं, और संभव हो तो उन्हें और छोटा बाँटना चाहिए”
  • एक मेथड को सिर्फ़ एक ही “काम (One Thing)” करना चाहिए
  • लेकिन इसे बहुत चरम रूप में लागू करने पर अत्यधिक विखंडन (over-decomposition) हो सकता है
• John ने कहा कि बहुत छोटे मेथड पूरे फ़्लो को समझना उल्टा कठिन बना सकते हैं
  • अगर बहुत सारे “shallow” मेथड हों, तो किसी एक फ़ीचर को समझने के लिए उससे जुड़े सभी मेथड देखने पड़ते हैं
  • मेथड्स के बीच पारस्परिक निर्भरता (“entanglement”) बढ़ जाती है, जिससे कोड पढ़ने का बोझ बढ़ता है
• PrimeGenerator उदाहरण
  • UB का मूल कोड लगभग 8 छोटे मेथड्स में बँटा था, और वे आपस में इस तरह जुड़े थे कि उसे समझना मुश्किल था
  • John के संस्करण में एक ही मेथड के भीतर पर्याप्त टिप्पणियाँ थीं, ताकि पूरा फ़्लो एक नज़र में समझ आ सके
  • UB ने भी कुछ हद तक माना कि “अत्यधिक विखंडन हुआ था”
• निष्कर्षतः, दोनों मानते हैं कि कोड को विभाजित करना महत्वपूर्ण है, लेकिन “बहुत ज़्यादा छोटा तोड़ना” और “बहुत बड़ा छोड़ देना” के बीच संतुलन बनाना ही असली बात है

टिप्पणियाँ

• UB टिप्पणियों को “आवश्यक बुराई (necessary evil)” के रूप में देखते हैं
  • उनका मानना है कि टिप्पणियाँ अक्सर अपडेट नहीं होतीं या उनमें गलत जानकारी होने का जोखिम रहता है
  • वे पसंद करते हैं कि कोड खुद ही अपनी मंशा स्पष्ट करे, और ज़रूरत पड़े तो बहुत लंबे नाम इस्तेमाल किए जाएँ
• John का कहना है कि टिप्पणियाँ ज़रूरी हैं
  • अगर इंटरफ़ेस (मेथड) का उद्देश्य या implementation intent अंग्रेज़ी में साफ़ लिखा हो, तो दूसरे डेवलपर्स का बेवजह कोड खंगालने में लगने वाला समय बचता है
  • उनके अनुसार “सबसे ख़तरनाक स्थिति वह है जब टिप्पणियाँ न हों और कोड को सीधे खुद समझना पड़े”
• PrimeGenerator के उदाहरण में John ने कहा कि अगर यह बताने वाली टिप्पणी न हो कि “एल्गोरिदम इस तरह क्यों काम करता है”, तो इसे समझना बहुत कठिन हो जाता है
• UB का रुख है कि “अगर टिप्पणी सटीक न हो तो वह उल्टा नुकसान करती है”, जबकि John का मानना है कि “गलत टिप्पणी से भी अधिक हानिकारक है कोई टिप्पणी न होना”
• दोनों किसी हद तक इस बात पर सहमत थे कि “टीम और परिस्थिति के अनुसार उचित स्तर की टिप्पणियाँ होनी चाहिए”, लेकिन कुल मिलाकर John टिप्पणियों के मूल्य को कहीं अधिक महत्व देते हैं

John का PrimeGenerator रिफैक्टरिंग

• John ने मूल 8-मेथड वाले कोड को फिर से एक एकल मेथड, या 2~3 मेथड्स के रूप में पुनर्गठित किया
• ज़रूरी जगहों पर भरपूर टिप्पणियाँ जोड़कर यह समझाया कि “इसे इस तरह क्यों implement किया गया है”
• टिप्पणियों में मुख्य वेरिएबल्स (multiples, primes) की मंशा और एल्गोरिदम के काम करने का तरीका दोनों बताया गया, ताकि कोड जल्दी समझ में आए
• UB ने कहा कि यह कोड भी पूरी तरह सहज नहीं था
  • जटिल एल्गोरिदम को समझाने के लिए फिर भी समय चाहिए था, और लेखक को खुद समीक्षा करते समय कठिनाई महसूस हुई

Bob का PrimeGenerator2 रिफैक्टरिंग

• यह John के कोड का UB द्वारा थोड़ा संशोधित संस्करण था
• कुछ मेथड्स को और अलग करके “आगे की रिफैक्टरिंग” लागू की गई
  • लूप वाले हिस्से में पठनीयता बढ़ी, लेकिन अस्थायी रूप से performance में गिरावट आई
• John ने कहा कि “बहुत छोटे मेथड्स में बाँटने से performance समस्याएँ आ सकती हैं”, और UB ने फिर संशोधन करके performance सुधारी
• फिर भी, क्योंकि UB की पसंद “टिप्पणियों को न्यूनतम रखना” है, John अपनी इस बात पर कायम रहे कि “और स्पष्टीकरण हों तो समझना आसान होगा”

Test-Driven Development

• UB ने TDD के उस तरीके की मज़बूती से वकालत की जिसमें छोटे चक्रों में पहले टेस्ट लिखा जाता है, फिर उस failing test को पास कराने के लिए थोड़ा-थोड़ा कोड जोड़ा जाता है
  • उनका कहना है कि इस तरीके से कोड हमेशा test coverage बनाए रखता है और जटिल debugging से बचा जा सकता है
  • उनका रुख है कि कोड को बार-बार रिफैक्टर करते हुए धीरे-धीरे साफ़ बनाया जाता है
• John को चिंता थी कि TDD बहुत अधिक “tactical approach” बन सकता है
  • उनका तर्क था कि “पहले डिज़ाइन आना चाहिए, लेकिन TDD पहले कोड लिखने (टेस्ट के लिए न्यूनतम implementation) की ओर ले जाता है”
  • उनका मानना है कि अच्छा डिज़ाइन थोड़ा व्यापक दायरे में पहले सोचा जाना चाहिए, और फिर उस कोड के लिए टेस्ट को bundled रूप में लिखना बेहतर है
• UB का कहना है कि “TDD को गलत तरीके से लागू करने पर समस्याएँ हो सकती हैं”, लेकिन सही ढंग से करने पर यह test coverage और redesign (refactoring) दोनों में मदद करता है
• John ने चिंता जताई कि “शुरुआती लोगों के लिए TDD उल्टा कोड को जल्दी अव्यवस्थित बना सकता है”
• अंततः दोनों इस बात पर सहमत थे कि “TDD भी और bundling approach भी, अगर सही ढंग से किया जाए, तो दोनों बेहतरीन कोड दे सकते हैं”, लेकिन कौन बेहतर है, इस पर मतभेद बना रहा

समापन

• John:
  • उन्हें चिंता है कि “Clean Code” बहुत छोटे फ़ंक्शन्स में विभाजन और टिप्पणियों को दबाने पर ज़ोर देता है, जिससे पाठक उसे चरम रूप में अपनाने लग सकते हैं
  • पर्याप्त टिप्पणियाँ न होने पर कोड समझना मुश्किल हो जाता है, और अंततः डेवलपर्स को अधिक समय खर्च करना पड़ता है
  • उन्होंने यह भी कहा कि TDD में बड़े चित्र वाला डिज़ाइन छूट सकता है
• UB:
  • उन्होंने कहा कि “Clean Code” के दूसरे संस्करण में कुछ हद तक सुधार किए गए हैं और John की कुछ राय शामिल की गई है
  • अलग-अलग अनुभवों और दृष्टिकोणों का सम्मान करते हुए उन्होंने इस साझा बिंदु पर ज़ोर दिया कि “सभी को साफ़ और maintainable कोड की दिशा में काम करना चाहिए”
• निष्कर्षतः, दोनों सॉफ़्टवेयर डिज़ाइन के महत्व और “कोड को पढ़ने में आसान बनाना” को सर्वोच्च मूल्य मानते हैं
• हालाँकि मेथड विभाजन के मानदंड, टिप्पणियों के उपयोग, और टेस्ट लिखने के क्रम जैसे मुद्दों पर दोनों की स्थितियाँ अलग हैं
• मुख्य बात यह है कि टीम के माहौल और कोड संरचना के अनुसार संतुलन बनाया जाए, और डिज़ाइन को लगातार बेहतर करने का प्रयास जारी रखा जाए

[mhj5730]

मेरे पास Clean series की कई किताबें हैं, लेकिन वे बस एक तरह की meta-cognitive reference के तौर पर ही ठीक लगती हैं। अगर उन्हें सिद्धांत या नियम की तरह लिया जाए तो यह बहुत थकाऊ हो जाता है, और व्यावहारिक भी नहीं रहता। Uncle Bob हमेशा SOLID principles की बात करते हैं, लेकिन व्यक्तिगत रूप से मुझे उनमें बहुत ज़्यादा practical content नहीं लगता।

[ahwjdekf]

मेरे हिसाब से Code Complete, Clean Code सबसे ज़्यादा overhyped किताबों की रैंकिंग में संयुक्त रूप से पहले स्थान पर हैं।

[carnoxen]

क्या Software Philosophy का अनुवादित संस्करण आया है? खोजने पर मुझे नहीं मिल रहा।

[mageia]

विडंबना यह है कि अच्छे कोड पर यह बताने वाली किताबों की बजाय, शायद व्यंग्यात्मक अंदाज़ में यह सिखाने वाली किताब कि कोड को maintenance के लिए मुश्किल कैसे बनाया जाए, ज़्यादा आसानी से समझ में आएगी।

[aer0700]

आजकल मुझे लगता है कि clean code से ज़्यादा बहस उन लोगों से हुई है जो किसी खास tech stack या architecture के इतने fan होते हैं कि जैसे अगर यह tech stack या architecture अपनाया नहीं गया तो बहुत बड़ी मुसीबत हो जाएगी। लगता है कि चीज़ों को स्थिति देखकर लागू करना सही है; हर चीज़ हर हाल में अच्छी नहीं होती।

[yadameda]

यह एक शानदार चर्चा है।

[spilist2]

वैसे सोचूँ तो, मैं जूनियर्स को John की philosophy of sw design की सिफारिश करता हूँ, लेकिन clean code की खास तौर पर सिफारिश नहीं की थी।

[bbulbum]

मुझे लगता है कि किसी भी headline का आँख मूंदकर पालन करने के बजाय, उसके संदर्भ को अच्छी तरह समझकर लागू करना ज़्यादा महत्वपूर्ण है।

[savvykang]

कोडिंग self-help किताबें उन शुरुआती लोगों के लिए ठीक हो सकती हैं जिनके पास तकनीक या implementation methods को लेकर अभी कोई ठोस दृष्टिकोण नहीं है, लेकिन मेरा मानना है कि अनुभव बढ़ने के साथ उनकी उपयोगिता कम होती जाती है। इसकी वजह यह है कि हर project और environment पर लागू होने वाला कोई पूर्ण सत्य नहीं होता, और कई बार ऐसे हालात भी आते हैं जहाँ सामान्य सिद्धांत काम नहीं करते। दूसरे सामान्य क्षेत्रों की self-help किताबों की सलाह की तरह, उनसे थोड़ा फासला रखते हुए सिर्फ वही सलाह अपनाना बेहतर लगता है जो परिस्थिति के अनुकूल हो, और सलाह का अंधाधुंध पीछा नहीं करना चाहिए।

[nicewook]

मुझे John की बात से थोड़ा ज़्यादा सहमति है.
मुझे लगता है कि असली बात यह है कि दोनों में से किसी की बात को डॉग्मा की तरह बिना शर्त मानने के बजाय यह समझते हुए आगे बढ़ना चाहिए कि वे ऐसा क्यों कहते हैं।

[leojineoo]

यह नहीं भूलना चाहिए कि clean code कोई लक्ष्य नहीं, बल्कि एक साधन है।

[ilikeall]

आखिरकार, संतुलन ही सबसे ज़रूरी है।

[elddytbt]

उपयोगी है 👍🏻

[GN⁺]

Hacker News राय

• कुछ लोग खास चीज़ों को लेकर बहुत कट्टर हो सकते हैं। समझ नहीं आता कि लोग इन्हें किसी धर्मग्रंथ की तरह क्यों मान लेते हैं

  • मुझे ऐसे लोगों के साथ काम करना पड़ा है जो 80-character line limit पार होते ही नाराज़ हो जाते थे
  • यह प्रवृत्ति सिर्फ programming style, pattern, और idiom तक सीमित नहीं है, बल्कि tech stack और solution architecture में भी और ज़्यादा दिखती है
  • किताबों या ब्लॉग में पढ़ी बातों को ज्यों का त्यों दोहराने वाले लोगों से बातचीत करना बहुत निराशाजनक होता है
  • NoSQL और microservices के उभार के समय यह खास तौर पर बुरा था, और PaaS/SaaS तथा containerization में भी यह अब तक महसूस होता है
  • ऐसी apps, lambdas, या transformation jobs जो बस बुनियादी काम करती हैं, अक्सर सिर्फ maintenance burden बढ़ाती हैं और कोई खास value नहीं देतीं
  • किसी किताब या ब्लॉग के लेखक और मुझमें फर्क सिर्फ इतना है कि उन्होंने लिख दिया। यह हमेशा याद रखना चाहिए कि उनकी राय तथ्य नहीं होती

• अगर आप किसी ऐसे project में काम करें जो Uncle Bob की सिफारिशों को आँख मूंदकर मानता हो, तो उसकी सीमित उपयोगिता जल्दी समझ आ जाती है

  • उन्होंने software engineering को बेहतर बनाने की कोशिश में कुछ text लिखे, लेकिन वे बहुत खराब सलाहों से भरे हुए हैं
  • उनकी सफलता का बड़ा हिस्सा guide ढूंढ रहे junior developers की अंतहीन ज़रूरत पर टिका है
  • बहुत ज़्यादा indirection वाला code काम करना मुश्किल बना देता है

• Clean Code एक अच्छे software engineer के toolbox का सिर्फ एक हिस्सा है

• कुछ लोग functions को तब अलग नहीं करते जब वे reusable हों या logically meaningful हों, बल्कि बस पास-पास की lines को जोड़कर उसे "refactoring" कह देते हैं

  • जब मैंने कॉलेज के दिनों में Clean Code पढ़ी थी, तब मुझे Uncle Bob का यही सामान्य vibe महसूस हुआ था
  • शायद यह उस सोच से आता है कि function को X lines का होना चाहिए
  • modern IDE की inline features के लिए आभारी हूँ, जिनकी मदद से code को समझने के लिए उसे फिर से संरचित किया जा सकता है

• comments की अहमियत पर एक महत्वपूर्ण उदाहरण छूट जाता है

  • USB device driver software लिखते समय device को गलत state में पहुँचा देना बहुत आसान होता है
  • हर बार जब मैं कोई workaround लागू करता हूँ, तो उसे document करने के लिए comment जोड़ता हूँ
  • comment के बिना किसी और के लिए code के इरादे को समझना मुश्किल होता है

• मैं "A Philosophy of Software Design" की ज़ोरदार सिफारिश करता हूँ

  • इसका मुख्य विचार यह है कि abstraction की quality को complexity के अनुपात से मापा जाए
  • programming advice पर लिखी दूसरी किताबें पढ़ने के बाद भी मेरा code बेहतर नहीं हुआ

• यह Clean Code आंदोलन से पहले software industry की असली समस्याओं के जवाब के रूप में आया था

  • Clean Code ने चीज़ों को बेहतर दिशा में आगे बढ़ाया, लेकिन बाद में इसे ज़रूरत से ज़्यादा सुधार दिया गया
  • पता नहीं लोग फिर से बहुत बड़े methods और गहराई तक nested conditionals की ओर लौटेंगे या नहीं

• Bob की comments को लेकर राय अजीब है

  • गलत comments को लेकर यह paranoia बेतुका है
  • अस्पष्ट code की वजह से मैंने बहुत समय बर्बाद किया है
  • अजीब diagrams बनाने के बजाय algorithm को संक्षेप में समझा देना या एक link दे देना कहीं आसान होता

• समय के साथ Uncle Bob की किताबों से आगे निकल जाना स्वाभाविक है

  • Clean Code की guidelines मानते हुए मैंने "over-decomposition" के बारे में सीखा
  • छोटे-छोटे functions आखिर में कुछ खास करते ही नहीं
  • अगर अच्छा code लिखना है, तो अच्छा code पढ़ना चाहिए और अपनी पसंद व समझ विकसित करनी चाहिए

• Clean Code नाम को लेकर भी आपत्ति है

  • code की "cleanliness" को objective तरीके से मापा नहीं जा सकता
  • "clean code" लिखना अपने-आप में अच्छा है, यह अवचेतन धारणा ही समस्या पैदा करती है
  • "Uncle Bob" की बुनियाद शुरू से ही flawed थी