पहले, थोड़ी सी पृष्ठभूमि। मैं आयु -> दर से एक लुकिंग कोडिंग कर रहा हूं। 7 आयु वर्ग हैं, इसलिए 7 पंक्तियों के साथ लुकअप टेबल 3 कॉलम (From | To | Rate) है। मान शायद ही कभी बदलते हैं - वे विधायी दर (पहले और तीसरे स्तंभ) हैं जो 3 साल तक एक ही रहे हैं। मुझे लगा कि इस तालिका को हार्ड-कोडिंग के बिना स्टोर करने का सबसे आसान तरीका यह है कि यह एक वैश्विक कॉन्फ़िगरेशन तालिका में डेटाबेस में है, सीएसवी युक्त एक एकल पाठ मान के रूप में (इसलिए "65,69,0.05,70,74,0.06" है 65-69 और 70-74 टियर संग्रहित किया जाएगा)। फिर उपयोग करने के लिए अपेक्षाकृत आसान है।
तब मुझे एहसास हुआ कि इसे लागू करने के लिए मुझे एक नई तालिका बनानी होगी, इसके चारों ओर लपेटने के लिए एक रिपॉजिटरी, रेपो के लिए डेटा लेयर टेस्ट, कोड के चारों ओर यूनिट टेस्ट जो CSV को टेबल में अनफ्लैट करता है, और लुकअप के चारों ओर परीक्षण करता है। इस सभी कार्य का एकमात्र लाभ लुकअप तालिका को हार्ड-कोड करने से बचना है।
जब उपयोगकर्ताओं से बात कर रहे हैं (जो वर्तमान में लुकिंग टेबल का सीधे उपयोग करते हैं - एक हार्ड कॉपी देखकर) राय बहुत अधिक है कि "दरें कभी नहीं बदलती हैं।" जाहिर है कि यह वास्तव में सही नहीं है - दरें केवल तीन साल पहले और पिछली चीजों में बनाई गई थीं जो "कभी नहीं बदलते हैं" को बदलने की आदत पड़ गई है - इसलिए मेरे लिए रक्षात्मक कार्यक्रम के लिए मुझे निश्चित रूप से लुकअप तालिका को स्टोर नहीं करना चाहिए। आवेदन पत्र।
सिवाय जब मुझे लगता है कि YAGNI । मैं जिस सुविधा को लागू कर रहा हूं वह यह निर्दिष्ट नहीं करती है कि दरें बदल जाएंगी। यदि दरों में बदलाव होता है, तो वे अभी भी शायद ही कभी बदलेंगे कि रखरखाव भी एक विचार नहीं है, और यह सुविधा वास्तव में महत्वपूर्ण नहीं है कि दर परिवर्तन और अद्यतन किए गए एप्लिकेशन के बीच देरी होने पर कुछ भी प्रभावित होगा।
यदि मैंने लुक-कोड को हार्ड-कोड कर दिया है, तो मैंने बहुत कुछ तय कर लिया है कि मूल्य का कुछ भी खो नहीं जाएगा, और मैं इस विशेष सुविधा के लिए अपने दृष्टिकोण के बारे में चिंतित नहीं हूं। मेरा प्रश्न यह है कि एक पेशेवर के रूप में क्या मैंने उस निर्णय को उचित ठहराया है? हार्ड-कोडिंग मान खराब डिज़ाइन है, लेकिन एप्लिकेशन से मूल्यों को हटाने की परेशानी में जाने से YAGNI सिद्धांत का उल्लंघन होता है।
संपादित करें प्रश्न को स्पष्ट करने के लिए, मैं वास्तविक कार्यान्वयन के बारे में चिंतित नहीं हूं। मुझे चिंता है कि मैं या तो एक त्वरित, बुरा काम कर सकता हूं, और YAGNI कहकर इसे सही ठहरा सकता हूं, या मैं अधिक रक्षात्मक, उच्च प्रयास वाला तरीका अपना सकता हूं, यहां तक कि सबसे अच्छे मामले में अंततः कम लाभ होता है। एक पेशेवर प्रोग्रामर के रूप में एक डिजाइन को लागू करने का मेरा निर्णय जो मुझे पता है कि त्रुटिपूर्ण है बस एक लागत / लाभ विश्लेषण के लिए नीचे आते हैं?
संपादित करें जबकि मुझे लगता है कि सभी उत्तर बहुत दिलचस्प थे क्योंकि मुझे लगता है कि यह किसी व्यक्ति के डिजाइन विकल्पों के लिए नीचे आता है, मुझे लगता है कि सबसे अच्छे उत्तर @ कॉर्बिन और @ ईजेड हार्ट थे क्योंकि वे उन चीजों को लाते हैं जिन्हें मैंने प्रश्न में नहीं माना था:
- डेटाबेस बनाम 'कुशलता से YAGNI को कुशलतापूर्वक लागू करने' को स्थानांतरित करके 'हार्ड-कोडेड मानों को सही ढंग से हटाने' का झूठा द्वैतवाद। ऐप कॉन्फ़िगरेशन में लुकअप टेबल को डालने का एक तीसरा विकल्प था, जो सही तरीके से ओवरहेड को लाइक नहीं करता है, और YAGNI की दक्षता के बिना। हम आम तौर पर या तो / या निर्णय तक ही सीमित नहीं होते हैं, और फिर यह एक लागत / लाभ निर्णय के लिए नीचे आता है।
- कोड पीढ़ी डेटाबेस में हार्ड-कोडित मानों को स्थानांतरित करने के ओवरहेड को कम कर सकती है, और एक तरह से CSV को तालिका में संसाधित करने के लिए मेरे अति-इंजीनियर निर्णय को भी हटा देती है। संभावित रूप से यह भी उत्पन्न कोड के साथ एक लंबी अवधि के रखरखाव के मुद्दे को जोड़ता है यदि लुकअप विधि के लिए बुनियादी आवश्यकताएं बदल जाती हैं। यह सब सिर्फ लागत / लाभ विश्लेषण को प्रभावित करता है, और यह संभावना है कि अगर मेरे पास वह स्वचालन उपलब्ध होता तो मैं इस तरह के हार्ड-कोडिंग पर भी विचार नहीं करता।
मैं @ कॉर्बिन के उत्तर को सही के रूप में चिह्नित कर रहा हूं क्योंकि यह मेरी विकास लागत की धारणाओं को बदल देता है, और मैं शायद निकट भविष्य में अपने शस्त्रागार में कुछ कोड पीढ़ी के उपकरण जोड़ूंगा।