गलत abstraction की बजाय duplication को प्राथमिकता दें (2016)

बहस का दायरा: Duplication बनाम Abstraction

• कई लोग मूल विचार से सहमत हैं: समय से पहले की गई, या “गलत” abstractions, छोटी-सी स्थानीय duplication से भी ज़्यादा नुकसानदेह हो सकती हैं।
• कुछ लोग यह आपत्ति उठाते हैं कि बड़े पैमाने की duplication catastrophic बन सकती है, खासकर लंबे समय तक चलने वाले, multi-customer या multi-team systems में।
• कई लोगों का तर्क है कि यह slogan अक्सर गलत समझा जाता है; इसका मतलब time से पहले या संयोगवश abstractions से बचना है, न कि हमेशा के लिए copy-paste करने का लाइसेंस।

Duplication कब उपयोगी है

• दोहराई गई implementations सही abstraction खोजने का एक tool हो सकती हैं: “इसे दो या तीन बार लिखो, फिर refactor करो” (rule of three / WET)।
• शुरुआती चरण में duplication को सस्ता और सुरक्षित माना जाता है, खासकर जब business requirements और domain boundaries अभी स्पष्ट नहीं हैं।
• कुछ लोग कई flags और conditionals वाली brittle “god abstraction” की बजाय isolated, थोड़ी duplicated flows पसंद करते हैं।

Abstractions कब गलत हो जाती हैं

• उदाहरण: over-generic frameworks, forced polymorphism, microservice “distributed monoliths,” Redux-heavy frontends, और DRY को चरम तक ले जाना।
• गलत abstractions आम तौर पर:
  • वास्तविक साझा concepts की बजाय accidental similarities को encode करती हैं।
  • छिपी हुई coupling फैलाती हैं, जिससे हर बदलाव जोखिम भरा और global हो जाता है।
  • boolean/config parameters और complex call chains जमा करती हैं।
• कुछ लोग मानते हैं कि “de minimis” scale से आगे फैली व्यापक duplication से बेहतर कोई भी maintainable abstraction है; जबकि कुछ इससे strongly असहमत हैं।

Heuristics और Thumb Rules

• आम heuristics:
  • एक occurrence के बाद abstract न करें; दो के बाद विचार करें; तीन के बाद कार्रवाई करें, अगर वे वास्तव में एक ही concept का प्रतिनिधित्व करते हों और उन्हीं कारणों से बदलते हों।
  • ऐसी abstractions को प्राथमिकता दें जो अपनी interface से ही स्पष्ट और self-justifying हों, केवल callers के ज्ञान पर निर्भर न हों।
  • गहरे, centralized “clever” frameworks की बजाय loose coupling और simple support libraries को तरजीह दें।
  • भविष्य में replacement को आसान बनाने के लिए abstract करें, speculative reuse के लिए नहीं।

LLMs और Cost Curve

• कुछ लोग कहते हैं कि LLMs duplication को बनाना और refactor करना सस्ता कर देते हैं, जिससे tradeoff सरल, अधिक duplicated code की ओर झुक सकता है।
• कुछ अन्य लोगों का अनुभव है कि LLMs और अधिक duplication लाते हैं और refactoring के दौरान सभी instances को मिस कर सकते हैं, इसलिए abstractions फिर भी महत्वपूर्ण हैं।
• सामान्य दृष्टिकोण: AI economics बदलता है, लेकिन abstraction बनाम duplication के बारे में सोचने की ज़रूरत खत्म नहीं करता।