कोड को बहुत जल्दी DRY न करें

 (testing.googleblog.com)
15 पॉइंट द्वारा GN⁺ 2024-05-31 | 10 टिप्पणियां | WhatsApp पर शेयर करें

कोड में दोहराव को बहुत जल्दी हटाना क्यों नहीं चाहिए

  • DRY(Don't Repeat Yourself) सिद्धांत को बहुत सख्ती से लागू करने पर "Premature" abstraction पैदा हो सकता है, जिससे भविष्य के बदलाव और अधिक जटिल हो सकते हैं
  • यह सोचना चाहिए कि क्या दोहराव सच में अनावश्यक है, या वह ऐसा functionality है जो समय के साथ स्वतंत्र रूप से विकसित होगा
    • कोई function या class एक जैसा दिखे, तब भी उसके context और business requirements अलग हो सकते हैं
    • कोड को छोटा बनाने से अधिक महत्वपूर्ण यह है कि क्या function का उद्देश्य समय के साथ बना रहता है
  • abstraction का जोखिम: अगर features के अलग-अलग तरह से विकसित होने की संभावना है, तो abstraction उल्टा नुकसानदेह हो सकता है
    • abstraction डिज़ाइन करते समय, ऐसे behavior को बहुत जल्दी एक साथ नहीं जोड़ना चाहिए जो लंबे समय में अलग-अलग विकसित हो सकते हैं
  • जब संदेह हो, तो behavior को अलग रखना चाहिए जब तक समय के साथ इतना स्पष्ट common pattern न दिखे कि coupling उचित लगे
    • छोटे पैमाने पर, Premature abstraction की जटिलता सुलझाने की तुलना में दोहराव को संभालना अधिक सरल हो सकता है
    • development के शुरुआती चरण में थोड़ा-बहुत दोहराव स्वीकार करके abstraction का इंतज़ार करना चाहिए
  • भविष्य की requirements का अनुमान लगाना अक्सर संभव नहीं होता
    • YAGNI(You Aren't Gonna Need It) सिद्धांत पर विचार करना चाहिए
    • हो सकता है दोहराव कभी समस्या न बने, या समय के साथ वह पर्याप्त रूप से सोची-समझी abstraction की आवश्यकता को स्पष्ट कर दे

संबंधित पढ़ाई

10 टिप्पणियां

 
bbulbum 2024-06-03

शुरुआत में DRY का इस्तेमाल तब करना चाहिए जब कुछ बार-बार दोहराया जा रहा हो और उसे कम करना हो,
लेकिन अगर कोड के बारे में पहले से ही DRY को आधार मानकर सोचा जाए, तो यह शायद गलत लागू करना लगता है.

Hacker News की राय में
DRY सिद्धांत की गलतफ़हमी: DRY का मतलब code duplication नहीं, बल्कि information/knowledge duplication को रोकना है. अगर ध्यान सिर्फ code duplication पर रहे, तो यह अनावश्यक optimization तक ले जा सकता है.
मुझे यही राय सबसे ज़्यादा सही लगती है.
 
wedding 2024-06-03

क्या संक्रमण के दौर में हम ऐसी चिंताएँ बहुत नहीं करते? परफेक्ट code जैसा कुछ नहीं होता, इसलिए हर दिन इस पर सोचना शायद हमारा काम ही है। मुझे लगता है कि यह case by case होता है।
 
aer0700 2024-06-01

हाल में बहुत अधिक abstraction वाली संरचनाओं पर संदेह भरी नज़र रखने वाले लेख अक्सर दिख रहे हैं.
MSA, clean code, SOLID, DRY वगैरह...
मुझे लगता है कि लोग ऐसे शब्दों से थकान महसूस करने लगे हैं.
असल में ये सब तो बस ऐसे संकेतक हैं जिन्हें देख कर हम पढ़ने में आसान, समझने में आसान, memory leak रहित, error-free और तेज़ code लिखने के बारे में सोच सकते हैं...
इन्हें बस संतुलित तरीके से, अपने मौजूदा business context के हिसाब से अच्छी तरह लागू कर लेना चाहिए.
 
kandk 2024-06-01

बहुत अच्छा लेख है।
मुझे लगता है कि waterfall model से agile model में बदलाव के समय यह और भी ज़्यादा महत्वपूर्ण हो जाता है।
agile अपनाने के बावजूद हम भविष्य का बहुत ज़्यादा अनुमान लगाने की कोशिश करते हैं।
 
iolothebard 2024-06-01

कितनी जल्दीबाज़ी को “जल्दबाज़” कहा जाए?
 
kandk 2024-06-01

जवाब बहुत आसान है। अगर आप इसे बस शुरुआत से ही करते हैं, तो वह "जल्दबाज़ी" है।
थोड़ा अधिक मुश्किल सवाल यह है कि इसे कब करना "जल्दबाज़ी नहीं" कहलाएगा।
 
iolothebard 2024-06-23

शब्दों का खेल जैसा है, लेकिन अगर शुरू से ही ऐसा न करें तो वह "गैर-जल्दबाज़" ही होगा ^^;
 
kandk 2024-06-23

हाँ, खासकर agile में
 
GN⁺ 2024-05-31
Hacker News राय

  • DRY सिद्धांत का शुरुआती उपयोग: शुरुआत से ही DRY सिद्धांत लागू करना अच्छा है। मिलते-जुलते डेटा को अलग-अलग संभालने के बजाय एक साझा codebase का उपयोग करना अधिक प्रभावी है.

  • best practice की प्राथमिकता: सभी best practice एक जैसी नहीं होतीं। पठनीयता और cohesion को प्राथमिकता देना महत्वपूर्ण है। कोड लिखना सबसे उपयुक्त practice चुनने की प्रक्रिया है.

  • DRY सिद्धांत की गलतफहमी: DRY का मतलब code duplication नहीं, बल्कि information/knowledge duplication को रोकना है। सिर्फ code duplication पर ध्यान देने से अनावश्यक optimization हो सकता है.

  • reusability की समस्या: कुछ खास functionality दूसरी परिस्थितियों में फिर से उपयोग नहीं हो पाती। दोहराव वाले काम से बचने के लिए बेहतर approach की ज़रूरत होती है.

  • जटिल DRY solution की समस्या: कभी-कभी दोहराया गया code, जटिल DRY solution से बेहतर होता है। बहुत जल्दी DRY लागू करने से अनपेक्षित structural समस्याएँ पैदा हो सकती हैं.

  • DRY कोई best practice नहीं है: दोहराव अक्सर इस बात का संकेत होता है कि abstraction की ज़रूरत है। बिना सोचे-समझे DRY लागू करना mid-level engineers की आम गलतियों में से एक है.

  • सरल code उदाहरण: दो functions को एक function में जोड़ा जा सकता है। refactoring के फायदे और नुकसान को स्पष्ट रूप से समझाना महत्वपूर्ण है.

  • DRY code की maintenance समस्या: DRY code जटिल हो सकता है और उसकी maintenance कठिन हो सकती है। दूसरी ओर, WET code सरल होता है लेकिन उसमें बदलाव अधिक अनुमानित होते हैं.

  • DRY सिद्धांत के दुष्प्रभाव: DRY सिद्धांत codebase को इतना जटिल बना सकता है कि maintenance मुश्किल हो जाए। कुछ clean code किताबों ने उद्योग पर नकारात्मक प्रभाव डाला है.

  • generalization और performance: generalization का performance पर नकारात्मक असर पड़ सकता है। खास data pattern के अनुरूप code duplication, performance optimization में मदद कर सकता है.