विरासत कोडबेस के लिए गुणवत्ता मानकों को कम करने के खिलाफ कैसे बहस करें? [बन्द है]

Question

हमारे यहां एक बड़ा विरासत कोड आधार है जिसके बुरे कोड की आप कल्पना नहीं कर सकते हैं।

हमने अब कुछ गुणवत्ता मानकों को परिभाषित किया है और पूरी तरह से नए कोडबेस में उन लोगों को पूरा करना चाहते हैं, लेकिन अगर आप विरासत कोड को छूते हैं।

और हम उन लोगों को सोनार (कोड विश्लेषण उपकरण) के साथ लागू करते हैं, जिनके पास पहले से ही कुछ हजारों उल्लंघन हैं।

अब चर्चा विरासत के लिए उन उल्लंघनों को कम करने के लिए हुई। क्योंकि यह विरासत है।

चर्चा पठनीयता के नियमों के बारे में है। जैसे कितने नेस्टेड इफ / फॉर .. यह हो सकता है।

अब मैं विरासत कोड पर हमारी कोडिंग गुणवत्ता कम करने के खिलाफ कैसे तर्क दे सकता हूं?

Comments

उपकरण के थ्रेसहोल्ड को कम करने के बारे में चर्चा है? ... या मैंने इसे गलत समझा। इसे भ्रामक तरीके से लिखा गया है।

— डेगनलीज

मैं $ {कुछ} को $ {किसी} को कैसे समझाऊं?

— gnat

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

— डॉक ब्राउन

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

— बर्नहार्ड हिलर

@keiki: अभी भी स्पष्ट नहीं है: क्या नए कोड आधार को पुराने और नए कोड के लिए अलग-अलग मान्यता नियमों के लिए पर्याप्त रूप से अलग किया गया है? विरासत कोड आधार में आपके द्वारा बदले गए भागों के बारे में क्या? क्या आपकी समस्या यह है कि परिवर्तित भागों को उच्च स्तर पर उठाने से बहुत अधिक प्रयास होते हैं, या क्या आप सोनार के सत्यापन में उन हिस्सों को अलग नहीं कर सकते हैं, जिससे केवल उन परिवर्तित भागों को पूर्ण रूप से सत्यापित करना संभव हो सके?

— डॉक ब्राउन

Answer 1

कोड केवल एक अंत का साधन है। वह अंत क्या भिन्न हो सकता है, लेकिन आम तौर पर यह लाभ है।

यदि यह लाभ है; फिर आप जो कुछ भी दिखाना चाहते हैं, उसे सफलतापूर्वक बहस करने के लिए, इससे लाभ में सुधार होगा - जैसे बिक्री में वृद्धि, रखरखाव की लागत को कम करना, विकास की लागत को कम करना, मजदूरी को कम करना, लागतों को कम करना आदि। लाभ में सुधार; तो आप ज्यादातर सिर्फ यह कह रहे हैं कि यह टॉयलेट के नीचे पैसे फ्लश करने का एक मजेदार तरीका होगा।

Comments

मेरा मानना ​​है कि इस चर्चा में एक और आयाम है जो व्यावसायिकता है, कई पेशों में, यदि आपका बॉस आपसे कोनों में कटौती करने के लिए कहता है, तो आप नैतिक आधार पर ऐसा करने से मना कर सकते हैं (कभी-कभी कानून आपको वापस भी करता है), मैं नहीं। समझें कि सॉफ्टवेयर डेवलपर्स को अलग तरह से व्यवहार क्यों करना चाहिए।

— एलेसेंड्रो टेरुज़ी

@AlessandroTeruzzi आप व्यावसायिकता की परवाह किए बिना कहीं भी (व्यक्तिगत) नैतिक आधार पर कुछ भी करने से इनकार कर सकते हैं। गारंटी नहीं है कि आप उस जगह पर काम करते रहेंगे।

— क्रॉम्स्टर का कहना है कि

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

— मटकाजा

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

— डॉक्टर ब्राउन

@DocBrown I अस्थायी रूप से सहमत है, लेकिन मुझे लगता है कि नंबर-ऑफ-नेस्टेड-ifs- संचालित विकास, एक ला ओपी, एक विरासत कोडबेस को बेहतर बनाने की दिशा में एक प्रभावी दृष्टिकोण नहीं है।

— brian_o

Answer 2

मैं, मैं और मैं दोनों एक निर्माता और विरासत कोड के अनुरक्षक रहे हैं। यदि आपके उपकरण का "हज़ारों उल्लंघनों" (या उस मामले के लिए भी सैकड़ों) का निर्माण होता है, तो उपकरण को भूल जाएं, यह स्थिति के लिए अनुपयुक्त है ...

मुझे लगता है कि मूल डेवलपर्स लंबे चले गए हैं और चर्चा के लिए अनुपलब्ध हैं। तो कोई भी ऐसा नहीं है जो डिजाइन और कोडिंग शैली के बारे में क्यों और कैसे समझता है। सैकड़ों या हजारों उल्लंघनों को सुधारना कोड की कुछ पंक्तियों को यहां और वहां फिर से लिखने की बात नहीं है। इसके बजाय, निस्संदेह इसे पुन: प्रसंस्करण / पुन: कार्यात्मक-अपघटन की आवश्यकता होती है। आप किसी भी मौजूदा मौजूदा कोडबेस के साथ ऐसा करने की कोशिश करते हैं, बिना इसके मौजूदा डिज़ाइन को समझे बिना, और आप बग्स / समस्याओं / आदि का एक नया सेट पेश करने के लिए बाध्य हैं। अभी आपके पास जो कीड़े हैं उनके मुकाबले एक नया कीड़ा भी बदतर हो सकता है (या आपके उपकरण से भी बदतर है >> सोचता है कि << अब आपके पास है)।

"हजारों उल्लंघनों" को संबोधित करने के लिए एकमात्र समझदार दृष्टिकोण खरोंच से फिर से लिखना होगा। एक लंबा और महंगा प्रयास, और प्रबंधन को बेचने के लिए लगभग असंभव है। और इस मामले में वे शायद सही हैं ...

लीगेसी कोड को आमतौर पर केवल ट्वीक की आवश्यकता होती है। जैसे y2k के लिए, या जब स्टॉक 256 वें से दशमलव तक चला गया। मैंने दोनों कि cr * p का लोड किया। और बहुत सारे अन्य समान सामान। यह आम तौर पर बहुत "पिनपॉइंट" है जिसमें आप कभी-कभी खराब शैली, खराब कार्यात्मक अपघटन, खराब आदि के माध्यम से "पढ़ सकते हैं" और उन स्थानों के संग्रह का पता लगा सकते हैं जिन्हें संशोधित करने की आवश्यकता है। और फिर, "उन स्थानों के बीच" क्या होता है, यानी, क्या अधिक उच्च-स्तरीय प्रवाह है, आपके लिए एक रहस्य बन सकता है। बस यह सुनिश्चित करें कि आप जिस स्थानीयकृत कार्यप्रणाली को बदल रहे हैं, उसे समझें, और फिर किसी भी दुष्प्रभाव के लिए परीक्षण, परीक्षण, परीक्षण करें, आपके स्थानीयकृत ज्ञान का अनुमान लगाने में सक्षम नहीं होंगे।

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

कभी-कभी आप अपनी विरासत कोडबेस को फिर से डिज़ाइन करना और फिर से लिखना चाह सकते हैं, जब व्यवसाय (या अन्य) आवश्यकताएं इस हद तक बदल जाती हैं कि सीट-ऑफ-पैंट्स "ट्विक्स" बस बदली हुई आवश्यकताओं को समायोजित नहीं कर सकती है । और उस बिंदु पर, आप पहले से ही एक नया कार्यात्मक आवश्यकता दस्तावेज़ लिखकर शुरू कर सकते हैं, यह सुनिश्चित करते हुए कि सभी हितधारक ई-बोर्ड हैं। यह मूल रूप से एक पूरी नई बॉलगेम है।

एक और केवल >> गलत << बात करने की कोशिश है विरासत कोड रखरखाव के इलाज के लिए उसी तरह से आप नए विकास के बारे में जाना होगा। और यह एक गलत बात है कि आप जिस रास्ते पर जाना चाहते हैं, ठीक उसी तरह लगता है :) इसके लिए मेरा शब्द लें, कि आप क्या करना चाहते हैं।

Comments

यह एक प्रश्न का उत्तर देता है "क्या विरासत को फिर से लिखा जाना चाहिए"। लेकिन ओपी यह नहीं पूछ रहा है कि चेतावनी को कैसे ठीक किया जाए या फिर से लिखा जाए। प्रश्न गुणवत्ता मानक के बारे में था - मूल रूप से हर बदलाव के लिए एक आवश्यकता थी सत्यापन मान्यताओं की गिनती को बढ़ाने के लिए नहीं।

— बसिलेव्स

यह सीधे प्रश्न को संबोधित करता है, जो पुनर्लेखन के बारे में नहीं है। ओपी 'विरासत कोड रखरखाव के इलाज के लिए उसी तरह बहस करना चाहता है जिस तरह से आप नए विकास के बारे में जाना चाहते हैं।' यह उत्तर कहता है "वाह! आपको ऐसा नहीं करना चाहिए!" ओपी की प्रतिक्रिया या आप सुनना नहीं चाहते थे, लेकिन सवाल के प्रति पूरी तरह उत्तरदायी।

— जोनाथन यूनिस

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

— जॉन फोर्कोश

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

— सुपरकैट

@ सुपरकैट यदि ऐसा किया जा सकता है, तो यह निश्चित रूप से एक अच्छा तरीका है। लेकिन मेरी कई y2k सुधारात्मक परियोजनाओं को याद करते हुए, आपको बस मौजूदा कोड के बीच में "गोता लगाना" और उसके चारों ओर गड़बड़ करना था। पुराने (नए) संभव (बिना बड़े पैमाने पर << फिर से लिखना) में फैक्टरिंग (पुनः) फैक्टरिंग नहीं। उदाहरण के लिए, दो बाइट्स जोड़ने के बजाय चार-बछेड़ा के लिए साल भर के फॉर्मेट किए गए वर्ष, बड़े पैमाने पर डेटाबेस में थोक अपडेट की आवश्यकता होती है, बस yy> 50 को 19yy, और yy <= 50 को 20yy के रूप में व्याख्या करें। लेकिन इसके लिए एकमात्र समझदार कार्यान्वयन में बहुत सारे बदलाव शामिल हैं जो हर जगह उपयोग किए जाते हैं।

— जॉन फोर्कोश

Answer 3

सवाल यह नहीं है कि कोड कितना अच्छा या बुरा है। सवाल यह है कि निवेश से आपको कितना फायदा होता है।

तो आपके पास एक ऐसा उपकरण है जो ऐसी हजारों चीजें ढूंढता है जो उसे पसंद नहीं है। आपके पास उपकरण के परिणामों की अनदेखी करने, या हजारों चीजों को बदलने के लिए काम का निवेश करने का विकल्प है। वो बहुत सारा सामान है। लोगों पर ध्यान केंद्रित नहीं किया जाएगा, बदलाव करते समय नहीं, उनकी समीक्षा करते समय नहीं, और यह ठीक से परीक्षण नहीं किया जाएगा क्योंकि यह लगता है कि हर बदलाव का परीक्षण (या बस प्रयास करने के लिए) करने के लिए उम्र लगती है, इसलिए कीड़े होंगे। इसलिए जब तक आप उन बगों को नहीं ढूंढते और ठीक करते हैं, तब तक आप समग्र नकारात्मक परिणाम के साथ बहुत समय और पैसा लगाते हैं।

दूसरी ओर, उपकरण ऐसी चीजें पा सकते हैं जो उन्हें "पसंद नहीं" हैं, लेकिन वे बग या संभावित बग हैं। यदि विरासत कोड अभी भी व्यापक उपयोग में है, तो सही उपकरण वास्तव में बग ढूंढ सकते हैं। इसलिए एक-एक करके कंपाइलर चेतावनियों को चालू करना, यह जाँचना कि वे उपयोगी हैं (सभी उपयोगी नहीं हैं) और उन चेतावनियों को ठीक करना सार्थक हो सकता है।

Comments

मैं एक बार एक परियोजना के लिए आया था जो जल्दी से किया गया था (संकलक चेतावनी को अनदेखा किया गया था)। प्रोजेक्ट गड़बड़ था, बग था। एक नंबर बह निकला था। टीम 2 सप्ताह से तलाश कर रही थी। मैंने सभी चेतावनी झंडों के साथ संकलक वातावरण स्थापित किया (गिनती 500 से कई हजार चेतावनियों तक गई)। मैं सभी चेतावनियों से गुजरा। सिर्फ 3h के बाद मुझे 0 चेतावनी मिली थी। किसी कारण से कोड काम किया। लेकिन हमें पता नहीं क्यों। मैंने अपनी शाखा में हर परिवर्तन के लिए कोड दिया है। थोड़ी खोज के बाद मैंने इसे पाया। एक अनुमानित रूप से घोषित फ़ंक्शन, जिसने सी को रिटर्न वैल्यू बनाया।

— कोडमोंकी

Answer 4

अगर यह नहीं टूटा है तो इसे ठीक न करें

यह व्यावहारिक रूप से प्रत्येक सॉफ़्टवेयर डेवलपर और प्रबंधक पर टैटू होना चाहिए ताकि वे इसे कभी न भूलें।

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

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

बेशक, कभी-कभी आप पाते हैं कि यह वास्तव में एक अकल्पनीय कलुगी है और "छोटे" संशोधन को समायोजित करने का एकमात्र तरीका खरोंच से फिर से लिखना है। जिस स्थिति में आपको वापस जाना है जो कोई भी बदलाव के लिए कह रहा है और उसे बताएं कि इसकी लागत क्या होगी (पुनर्लेखन के लिए डॉलर या मानव-घंटे दोनों में, और अपरिहार्य नए कीड़े के लिए खून पसीना और आँसू में)।

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

Comments

क्या आप पश्चिमी डिजिटल मतलब है ? क्या यह याद था ? क्या आप अपनी कहानी का समर्थन करने के लिए कोई स्रोत प्रदान कर सकते हैं?

— मोनिका

बहुत यकीन है कि वह डिजिटल उपकरण कॉर्प का मतलब है एक बेहोश टिमटिमाहट जो अभी भी हेवलेट पैकर्ड के काले दिल में गहराई से रह सकता है।

— जॉन हस्कल

हां - डिजिटल को DEC के रूप में भी जाना जाता है।

— nigel222

Answer 5

विरासत कोड के लिए गुणवत्ता स्तर को कम करने का कोई मतलब नहीं है। चेतावनी को तुरंत ठीक करने की भी आवश्यकता नहीं है। बस यह सुनिश्चित करें कि आपकी परियोजना के हर घटक में आपके सभी "नए" परिवर्तन उच्च गुणवत्ता मानक का पालन कर रहे हैं। यानी नो कमिटमेंट में कभी भी चेतावनी की संख्या नहीं बढ़नी चाहिए।

यह एक समान और मृत सरल दृष्टिकोण है।

यह पुराने विरासत कोड को काम करने देता है (क्योंकि इसमें कोई अनावश्यक संशोधन नहीं किया गया है)। यह सुनिश्चित करता है कि नया कोड उच्च गुणवत्ता का हो। कोई अतिरिक्त लागत शामिल नहीं है।

Comments

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

— जॉन फोर्कोश

मैंने कमिट किया है, लाइन या फंक्शन नहीं। माना जाता है कि आप अपने आस-पास के क्षेत्र में पर्याप्त गंदगी साफ करते हैं।

— बसिलेव्स

Answer 6

जोखिम नियंत्रण…।

• सॉफ़्टवेयर की वास्तविक जीवन उपयोग द्वारा बड़ी विरासत कोडबेस में कोड का कम से कम परीक्षण किया गया है।
• यह बहुत अवांछित है बड़ी विरासत कोडबेस में कोड स्वचालित इकाई परीक्षणों द्वारा कवर किया गया है।
• इसलिए बड़े विरासत कोडबेस में ठंड के लिए कोई भी परिवर्तन उच्च जोखिम है।

लागत…।

• जब आप कोड लिख रहे हों तो कोड कोड को पास करना सस्ता होता है
• बाद की स्थिति में ऐसा करना बहुत अधिक महंगा है

लाभ

• आप आशा करते हैं कि कोडिंग मानकों को बनाए रखने से कोड का बेहतर डिज़ाइन हो सकता है।

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

• सरल कोड स्पष्ट है और समझने में आसान है, जब तक कि जटिल कोड किसी ऐसे व्यक्ति द्वारा छोटे तरीकों में विभाजित नहीं किया जाता है जो इसे नहीं समझता है…

सिफ़ारिश करना…।

• यदि कोड के एक खंड में बहुत सारे बग दिखाए गए हैं, या अतिरिक्त कार्यों को जोड़ने के लिए बहुत सारे बदलावों की आवश्यकता है, तो 100% समझने में समय व्यतीत करें कि यह क्या करता है।
• कोड के उस सेक्शन में अच्छी यूनिट टेस्ट को जोड़ने के लिए भी समय व्यतीत करें, क्योंकि आपको उनके लिए एक सिद्ध आवश्यकता है।
• फिर आप कोड को फिर से भरने पर विचार कर सकते हैं (अब आप समझ गए हैं) इसलिए इसने नए कोड की जाँच भी कर ली।

व्यक्तिगत रूप से अनुभव…।

• एक प्रोग्रामर के रूप में काम करने के अन्य 20 वर्षों में, मैंने कभी ऐसा मामला नहीं देखा है जहां एक नए कोडिंग मानक परीक्षक से सभी आउटपुट को हटाने के लिए नेत्रहीन बदलते पुराने को ठेकेदारों के आय में वृद्धि के अलावा कोई लाभ था जो ऐसा करने के निर्देश दिए गए हैं।
• इसी तरह जब पुराने कोड को कोड रिव्यू पास करने के लिए किया जाना है (टिक इट / आईएसओ 9001 गलत किया गया) तो पुराने कोड को नए कोडिंग मानक की तरह देखने की आवश्यकता है।
• मैंने कई मामलों को देखा है जहां नए कोड पर मानक जाँच उपकरणों का उपयोग करके चल रही लागतों को कम करके बहुत लाभ हुआ है।
• मैंने कभी भी किसी कंपनी को पुराने कोड को बनाए रखने की लागतों में असफल नहीं देखा है जो कि कई ग्राहकों के साथ एक उत्पाद में उपयोग किया जाता है।
• मैंने कंपनी को बाज़ार से बहुत धीमा होने के कारण ग्राहकों से आय प्राप्त नहीं करने के कारण विफल देखा है।

Answer 7

उपकरण के थ्रेसहोल्ड को कम करने के बारे में चर्चा है? ... या मैंने इसे गलत समझा। इसे भ्रामक तरीके से लिखा गया है। यदि ऐसा नहीं है, तो कृपया मेरे उत्तर को त्याग दें।

IMHO यह उपकरण की संवेदनशीलता को कम करने के लिए एक अच्छा विचार है। क्यूं कर? क्योंकि यह कोड के सबसे बालों वाले टुकड़ों को उजागर करेगा। विकल्प हजारों उल्लंघनों के साथ रिपोर्ट तैयार कर रहा है, जो इसके विशाल आकार से बेकार हो रहा है।

... इसके अलावा, बस इसमें शामिल लोगों के साथ इसके बारे में बात करें और उनके कारणों को भी सुनें।

Answer 8

मैं नए साफ कोड से विरासत कोड को अलग करने की कोशिश करूंगा। उदाहरण के लिए ग्रहण आप उन्हें विभिन्न परियोजनाओं में लगाकर कर सकते हैं जो एक दूसरे का उपयोग करते हैं। 'स्वच्छ'-परियोजना और 'विरासत'-परियोजना ।

इस तरह आप सोनार में विभिन्न गुणवत्ता मानकों के साथ दोनों परियोजनाओं का विश्लेषण कर सकते हैं। नियमों के महत्व में मानकों को केवल अलग होना चाहिए। नियम अपने आप में समान होने चाहिए। इस तरह आप में देख सकते हैं 'legacy'-परियोजना क्या करना होगा' तय 'के मानकों को पूरा करने clean'-परियोजना' ।

जब भी आप कुछ विरासत कोड को उच्च मानकों पर उठाने में कामयाब रहे तो आप इसे 'क्लीन-प्रोजेक्ट' में स्थानांतरित कर सकते हैं।

हर दिन के काम में आप हर उस वर्ग को उठाने के लिए पूरा नहीं कर सकते हैं जिसे आप समय के अंतराल के कारण 'क्लीन-प्रोजेक्ट' मानकों पर छूते हैं। लेकिन आपको हर बार जब आप इसे छूते हैं तो विरासत कोड को थोड़ा सुधारने की कोशिश करके आपको छोटे चरणों में वहां पहुंचने की कोशिश करनी चाहिए।