गलत abstraction की बजाय duplication को प्राथमिकता दें (2016)
“गलत abstraction की बजाय duplication को प्राथमिकता दें” code दोहराने और साझा abstractions बनाने के बीच trade-off पर फिर से विचार करता है, और तर्क देता है कि समय से पहले या अनुपयुक्त abstractions अक्सर जितनी complexity और coupling हटाती हैं, उससे अधिक जोड़ देती हैं। Commenters “rule of three,” संयोगवश समानता और वास्तविक shared behavior के बीच अंतर, तथा over-engineered frameworks और फैली हुई copy-paste—दोनों के दीर्घकालिक दर्द—जैसे heuristics पर चर्चा करते हैं। कई लोग नोट करते हैं कि modern tooling और LLMs duplication तथा refactoring की cost profile बदलते हैं, लेकिन मूल चुनौती बनी रहती है: domain के अनुकूल, स्थिर abstractions ढूँढना, उन्हें बहुत जल्दी थोपे बिना।
बहस का दायरा: 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 के बारे में सोचने की ज़रूरत खत्म नहीं करता।