क्या पहले से मौजूद खराब प्रथाओं, या अच्छी प्रथाओं का उपयोग करना बेहतर है जो पुराने कोड के साथ अच्छी तरह से फिट नहीं हैं?


25

मैं यह सोच रहा था क्योंकि मैं एक मौजूदा 3 पार्टी सॉफ्टवेयर के लिए एक एक्सटेंशन लिखने की कोशिश कर रहा था, और उनके डेटाबेस को बुरी तरह से विकृत किया गया है। मुझे उनकी मौजूदा तालिकाओं का उपयोग करने और नए क्षेत्रों का एक गुच्छा जोड़ने की आवश्यकता थी।

मेरे पास उनकी डिज़ाइन शैली में या तो नई तालिकाएँ बनाने का विकल्प था (जिसमें लगभग सभी भविष्यवाणियाँ एक बड़ी तालिका में होती हैं), या पूरी तरह से तालिकाओं का एक नया सेट बनाना और नए के बीच डेटा को सिंक्रनाइज़ करने के लिए ट्रिगर जैसे कुछ अतिरिक्त का उपयोग करना। पुराने टेबल।

मैंने मौजूदा खराब डिज़ाइन शैली का उपयोग करने के पहले विकल्प के साथ जाना समाप्त कर दिया, लेकिन मुझे इस प्रश्न के साथ छोड़ दिया गया: क्या पहले से मौजूद खराब प्रथाओं के साथ जाना बेहतर है, या अच्छी प्रथाओं को लागू करना जो मौजूदा कोड के साथ अच्छी तरह से नहीं खेलते हैं? क्या कुछ परिस्थितियाँ हैं जहाँ मुझे एक को दूसरे पर चुनना चाहिए?

नोट: अब तक कई जवाबों को धीरे-धीरे खराब कोड को फिर से भरना है, हालांकि मैं ऐसा करने में असमर्थ हूं। कोड हमारा नहीं है, और यह अक्सर विक्रेता द्वारा अद्यतन किया जाता है। मैं केवल इस पर निर्माण कर सकता हूं।



धन्यवाद पीटर, उस सवाल को नहीं देखा। यह बहुत कुछ ऐसा ही है जो मैं पूछ रहा हूं, सिवाय इसके कि लगता है कि उत्तर मौजूदा कोड को फिर से भरने से संबंधित प्रतीत होते हैं, मौजूदा खराब कोड को जोड़कर नहीं। मैं मौजूदा कोड को रिफलेक्टर नहीं कर सकता, मैं केवल इस पर निर्माण कर सकता हूं।
राहेल

इस बात पर निर्भर करता है कि आप अपने वर्तमान नियोक्ता के साथ कितने समय तक रहना चाहते हैं?)
अय्यूब

जवाबों:


21

आपको बेहतर डिज़ाइन चुनना चाहिए अगर:

  1. आप भविष्य के कोडिंग का एक बड़ा हिस्सा लेने जा रहे हैं

  2. बेहतर डिजाइन लंबे समय में ग्राहक के लिए अधिक महंगा नहीं है। उदाहरण के लिए, मैंने उन परियोजनाओं के लिए बहु-महीने "रिफैक्टोरिंग" देखा है, जो साल के अंत तक बंद कर दिए गए थे।

आपको "वही खराब शैली" चुननी चाहिए यदि:

  1. आप बस मदद कर रहे हैं। यह सोचना अवास्तविक है कि आप किसी मौजूदा समूह को ले सकते हैं और यदि परियोजना में अंशकालिक भरण-पोषण कर रहे हैं तो उन्हें उच्चतर डिजाइन मानकों तक ले जाएंगे। बेहतर डिजाइन व्यक्तिपरक है और लगभग हमेशा एक सीखने की अवस्था है। यदि उस नए डिज़ाइन को टीम के बाकी सदस्यों द्वारा नहीं सीखा गया है, तो परियोजना शैली के एक मैश-मैश के साथ समाप्त हो जाएगी, और आपका बेहतर डिज़ाइन कोड सामान के ढेर में समाप्त हो सकता है, क्योंकि कोई भी नहीं बदलता है क्योंकि वे समझ नहीं सकते हैं यह। ऊपर दिए गए आपके उदाहरण में, अगर थर्ड पार्टी सॉफ्टवेयर के अपडेट हैं तो क्या होगा?

  2. "बेहतर" डिज़ाइन का त्याग करने से आपको एक ठोस व्यवसाय लाभ मिलेगा। जैसे फीचर एक्स को बुरी तरह से जोड़ने से आपको एक बड़ा अनुबंध मिलेगा, लेकिन समय सीमा गायब होने से आप कुछ भी नहीं कर सकते हैं। यह वह जगह है जहाँ mgmt और तकनीकी टीम के बीच ऐतिहासिक संघर्ष सामने आता है। जैसे घर का नवीनीकरण करना, किसी को यह तय करना होता है कि भुगतान कब करना है। आप शुरू में एक साल तक बिना बिजली या प्लंबिंग के साथ कर्ज चुका सकते हैं। या आप उन उपयोगिताओं के लाभ के साथ 3x का भुगतान कर सकते हैं।


खराब डिजाइन पर अच्छे डिजाइन के साथ जाने के बेहतरीन उदाहरण और इसके विपरीत, धन्यवाद :)
राहेल

11

लंबे समय में, अच्छी प्रथाओं का उपयोग करना बेहतर है। यह समय और प्रयास को बचाएगा क्योंकि परिवर्तनों को लागू करने में कम समय लगेगा।

यदि संभव हो तो, अच्छा अभ्यास करने के लिए रिफ्लेक्टर के लिए थोड़ा कदम उठाएं (उदाहरण के लिए: SQL में जो एक को सामान्यीकृत करने के लिए denoramlized तालिकाओं को तोड़ रहा होगा और पुराने तालिका नामों के साथ विचारों का उपयोग कर रहा होगा)।

आप ध्यान देंगे कि मैंने लंबे समय में कहा था - "गुणवत्ता, समय, पैसा" त्रिकोण यहां भी लागू होता है (यानी - दो का चयन करें)। यदि आपके पास पुरानी प्रथाओं के साथ जाने का समय नहीं है, लेकिन इसका मतलब यह होगा कि आप समस्या को जोड़ रहे हैं और आपके डिजाइन को भी ठीक करने की आवश्यकता होगी।

यदि आप काम करते रहते हैं और खराब डिज़ाइन का कोड जोड़ते रहते हैं, तो आप कभी भी ऐसे कोडबेस के साथ समाप्त नहीं होंगे जो अच्छे डिज़ाइन का उपयोग करता है। जितना संभव हो उतना अच्छा डिजाइन और रिफ्लेक्टर का उपयोग करने की कोशिश करें।


मैंने SQL डेटा के लिए उस समाधान के बारे में कभी नहीं सोचा था। दुर्भाग्य से, मुझे उनके कोड आधार को संपादित करने की अनुमति नहीं है क्योंकि वे अभी भी नियमित अपडेट जारी करते हैं। मुझे जो कुछ भी जोड़ना है वह पूरी तरह से अलग होना है।
राहेल

1
@ राचेल - यदि आप नई तालिकाओं के नियंत्रण में हैं, तो उनके लिए अच्छे डिजाइन का उपयोग करें (मैं मान रहा हूं कि पुराने डिजाइन के अपडेट नई तालिकाओं को प्रभावित नहीं करेंगे)। जब आपको अपना कोड बदलने की आवश्यकता होगी, तो आपके रखरखाव की लागत कम होगी।
Oded

सॉफ़्टवेयर फ़्रीक्वेंसी के अपडेट में डेटाबेस अपडेट और नए फ़ील्ड शामिल हैं, इसलिए मौजूदा तालिकाओं को हटाना और उन्हें फिर से लिखना क्योंकि विचार मेरे लिए एक व्यवहार्य विकल्प नहीं है। उपयोगकर्ता अभी भी इन तालिकाओं का उपयोग करने वाले सॉफ़्टवेयर के मौजूदा हिस्से का उपयोग करते हैं, उन्हें बस एक एक्सटेंशन की आवश्यकता होती है। यदि यह एक 3-पक्ष विक्रेता के बजाय हमारा कोड था, तो मैं इसे एक दिल की धड़कन में लागू करूंगा :) हालांकि मेरे मूल प्रश्न के लिए समग्र दृष्टिकोण।
राहेल

1

खैर, मुझे लगता है कि यह प्रत्येक मामले पर बहुत निर्भर करता है। यदि प्रदर्शन और डिजाइन इसकी अनुमति देता है, तो बेहतर प्रथाओं का उपयोग करना बेहतर होता है। लेकिन अगर उदाहरण के लिए, यदि वह तालिका एक उच्च पहुँच तालिका है, तो पुनर्जन्म के लिए ट्रिगर बनाने से प्रदर्शन पर नकारात्मक प्रभाव पड़ सकता है।

अब, आपका ग्राहक यह नहीं देख सकता है कि आपने एक बेहतर डिज़ाइन का उपयोग किया है, वह सिर्फ यह देखेगा कि आपके समाधान ने उसके सिस्टम को धीमा कर दिया है। इस प्रकार का निर्णय केस के आधार पर किया जाना चाहिए, और आपको निर्णय लेने के लिए अपने अनुभव और मापदंड का उपयोग करना चाहिए।

मुझे लगता है कि आपने शायद सही चुनाव किया है।


1

जितना संभव हो, आपको अपने एप्लिकेशन कोड को खराब डेटा डिज़ाइन से अलग करना चाहिए।

क्या आप उनकी टेबल अपडेट कर रहे हैं? यदि नहीं, तो SQL तालिकाओं को अपने अनुप्रयोग के लिए सुविधाजनक तरीके से प्रस्तुत करने के लिए बनाएँ। एसक्यूएल दृश्य लिखना आसान है, और अनुप्रयोग कोड की तुलना में परीक्षण करना बहुत आसान है।

यदि आपको विरासत तालिकाएँ अद्यतन करनी हैं, तो अद्यतनों को प्रबंधित करने के लिए संग्रहीत प्रक्रियाओं को लिखने पर विचार करें। वे लिखने के लिए थोड़ा अधिक जटिल हैं, लेकिन उन्हें तुरंत परीक्षण किया जा सकता है।


1

पुराने कोड को सिंक में रखने के लिए जब आप ट्रिगर्स के साथ एक डेटाबेस को सामान्य करते हैं तो यह एक अच्छा समाधान है यदि यह अस्थायी है। लक्ष्य को पुराने कोड को बदलना चाहिए, लेकिन तीसरे पक्ष के साथ काम करते समय, यह संभव नहीं है। आपको उनके स्कीमा परिवर्तनों के शीर्ष पर रहना होगा।

बुरे कोड पर अधिक से अधिक सुविधाओं को जमा करना लगातार समस्याएं पैदा करने वाला है। कार्य-परिवेश आदर्श बन जाते हैं। उपयोगकर्ता निराश हो जाएंगे क्योंकि परिवर्तन बहुत लंबा होने वाला है और संभवत: अन्य बग या सीमाओं का परिचय देते हैं। जो प्रोग्रामर बनना चाहता है, वह कहता है कि हम ऐसा नहीं कर सकते, इसके बजाय हमें ऐसा नहीं करना चाहिए?

कुछ कोड अकेले छोड़ दिए जा सकते हैं; हमारे पास हमेशा वह विलासिता नहीं है।


-1

आप यहां तकनीकी ऋण से निपट रहे हैं। संक्षेप में, तकनीकी ऋण का अभिप्राय ब्याज से है, जिसे आपको समय के साथ चुकाना होगा, और किसी समय आपको इसे वापस करना होगा।

डिवेलपर्स के समय में पैसा खर्च होता है, इसलिए तकनीकी ऋण को वास्तविक ऋण की तरह ही देखा जा सकता है, और वास्तविक धन खर्च होता है।

आपके पास मूल रूप से दो मुख्य समाधान हैं, और बीच में कई समाधान हैं। आप यह तय कर सकते हैं कि आप अब उस ऋण को वापस नहीं करना चाहते हैं, और ब्याज का भुगतान करना जारी रख सकते हैं। जाहिर है, यह लंबे समय में अधिक खर्च होगा, लेकिन आपको अभी परिणाम देने की अनुमति देता है। आप उस ऋण को वापस करने का विकल्प भी चुन सकते हैं, इसलिए जब तक आप इसे वापस नहीं करेंगे तब तक आप आगे नहीं बढ़ेंगे, लेकिन अंत में, आप ब्याज से मुक्त हैं।

आमतौर पर आपके पास डिलीवरी के लिए समय सीमा होती है, और समय सीमा छूटने से आपके ग्राहक का अविश्वास बढ़ जाएगा, और अंततः आप इसे ढीला कर देंगे। यह तकनीकी ऋण को डुबोने का एक वैध कारण हो सकता है: आप विचार करते हैं कि तकनीकी ऋण के अतिरिक्त छूट के लायक ग्राहक के साथ आपका क्या लाभ है।

आप जानते हैं कि अंत में, आपको नई पद्धति को अपनाना होगा, इसके अलावा, आपको अधिक से अधिक ऋण मिलेगा और आप अंततः दिवालिया हो जाएंगे (अब, जब लोग खरोंच से फिर से शुरू करने का फैसला करते हैं या जब परियोजना बुरी तरह से विफल हो जाती है)।

आपको यह योजना बनानी होगी कि आप मौजूदा कोडबेस को कैसे बदलेंगे और समय के साथ नए अभ्यास में बदलाव करेंगे, और दैनिक आधार पर बदलाव को थोड़ा बदल देंगे। कुछ बिंदु पर, जब थेक रिफैक्टरिंग अन्य नुकसान की ओर ले जाएगा, तो विचार करें कि कौन सा नुकसान सबसे खराब है और सबसे अच्छे के लिए जाना।

समय के साथ रिफैक्टरिंग की लागत नहीं बढ़ेगी (यह तकनीकी ऋण के हित हैं)। तो यह अंततः महंगा विकल्प बन जाएगा।

सुनिश्चित करें कि आपका बॉस तकनीकी ऋण की अवधारणा को समझता है। एहतियात के साथ भी, आप तकनीकी ऋण पैदा करेंगे। कुछ बिंदु पर, इसे वापस करने के लिए उपयोग किए जाने वाले धन के रूप में। जब आप उद्देश्य पर तकनीकी ऋण बनाते हैं, तो आपके पास इसके लिए एक वैध कारण होता है, और ऋण को निवेश के रूप में देखें (वास्तविक ऋण की तरह)। किसी भी अन्य मामलों में, बस उद्देश्य पर तकनीकी ऋण न करें।

आप डीबी को विकसित करने और थ्रोज़ एवोल्यूशन को तैनात करने के तरीकों पर दिलचस्पी ले सकते हैं: http://richarddingwall.name/2011/02/09/the-road-to-automated-database-deployment

वैसे, यह एक कठिन काम है, इसलिए शुभकामनाएं। यह इसके योग्य है !


-1

यह एक विशिष्ट समस्या है: "क्या मुझे अपने काम के लाभों को अभी या बाद में पुनः प्राप्त करने की आवश्यकता है?" और मुझे नहीं लगता कि उस उत्तर का कोई सामान्य समाधान हो सकता है। केवल आप ऐसे निर्णय में शामिल सभी कारकों (तकनीकी और मानव) को जानते हैं।

हालाँकि आपकी समस्या एक दिलचस्प सवाल उठाती है:

क्या स्वचालित कोड रीफैक्टरिंग पर्याप्त प्रगति कर रहा है ताकि कोड एकरूपता को अधिक महत्व दिया जाए?

अंत में, खराब डिज़ाइन को बदलना या मरना चाहिए। या फिर, यह एक बुरा डिजाइन नहीं है। यहां वास्तविक सवाल रिफैक्टिंग की लागत के बारे में है। यह आपके प्रश्न से स्पष्ट लगता है कि आप (या आपके नियोक्ता) अभी कीमत का भुगतान करने के लिए तैयार नहीं हैं, और प्रौद्योगिकी की वर्तमान स्थिति में, कभी भी नहीं चाहते हैं।

हालाँकि, कोड रिफैक्टिंग ऑटोमेशन कुछ प्रगति कर रहा है। यदि संकलक आज बायनेरिज़ को ऑप्टिमाइज़ कर सकते हैं, तो कौन कहता है कि वे कल कोड का अनुकूलन नहीं करेंगे? कुछ बिंदुओं पर, कुछ उपकरण आने वाले हैं, जिससे डेवलपर्स और डिज़ाइनर अपने कोड को बहुत आसानी से रीफ़ैक्टर कर सकते हैं, ताकि नई आवश्यकताओं के अनुकूल हो सकें। आखिरकार, विरासत कोड से निपटना आज की सबसे बड़ी चुनौतियों में से एक है।

यदि ऐसा कोई उपकरण मौजूद है (मुझे आश्चर्य नहीं होगा कि यह पहले से ही है), तो इस तरह का निर्णय लेते समय इसे ध्यान में रखना अच्छा होगा।


-2

अच्छी प्रथाएं हमेशा गरीबों को परेशान करती हैं। यदि आपका कोडबेस गलत तरीके से कोड के साथ लिट गया है, तो आपको अपने सामान को उसी शैली में नहीं बनाना चाहिए, आपको कोड को ठीक से लिखना चाहिए और फिर बाकी सभी को सही तरीके से शिक्षित करने का प्रयास करना चाहिए।


एक डेवलपर के रूप में आपको पूर्ण बयानों के खतरे को जानना चाहिए।
whatsisname

मैं गलत प्रथाओं से निपटने और कोड को गलत तरीके से लिखने के खतरे को भी जानता हूं, और IMO यह सबसे बुरा खतरा है।
वेन मोलिना
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.