एक जटिल विरासत ऐप में नए बग को पेश करने की बाधाओं को कम करने के लिए मैं क्या दृष्टिकोण अपना सकता हूं?

Question

जहां मैं काम करता हूं, मुझे अक्सर एक पुरानी प्रणाली (.NET 1) में व्हाट्सएप कोड विकसित करना पड़ता है (.NET 1) व्हॉट्स कोड पूरा स्पेगेटी होता है - थोड़ा नाम चर नाम, प्रोग्राम संरचना और न ही टिप्पणियों के साथ दिया जाता है।

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

मुझे इसके कोड पर काम करने में डर लगता है क्योंकि मुझे कुछ और तय करने में ही कुछ दिन लग जाता है। यह स्पष्ट रूप से मुझे अक्षम दिखता है - तो मैं इससे कैसे निपट सकता हूं?

Comments

संबंधित प्रश्न: programmers.stackexchange.com/questions/66438/…

— Matthieu

Answer 1

उन हिस्सों के लिए परीक्षण लिखना शुरू करें जिन पर आप काम कर रहे हैं। आप एक वर्कफ़्लो की कोशिश कर सकते हैं जो कुछ इस तरह से होता है:

1. जिस हिस्से को आप बदलने वाले हैं, उसके लिए परीक्षण लिखें। यह आपको यह समझने में भी मदद करेगा कि मौजूदा कोड कैसे व्यवहार करता है।
   • यदि आवश्यक हो तो परीक्षण का समर्थन करने के लिए रिफैक्टर कोड, लेकिन आप समय कम होने पर गैर-यूनिट परीक्षण लिखना चाह सकते हैं।
2. यह सुनिश्चित करने के लिए अपने परीक्षण चलाएं कि आप उम्मीद के मुताबिक काम कर रहे हैं।
3. अपने बदलाव करें। निरंतर कोड सुधार की भावना में जरूरत पड़ने पर रिफ्लेक्टर, लेकिन दूर नहीं किया जाता है।
4. यह सुनिश्चित करने के लिए अपने परीक्षण फिर से चलाएं कि आपने एक ही कार्यक्षमता बनाए रखी है।

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

तुम भी माइकल फेदर सहायक द्वारा विरासत कोड के साथ प्रभावी ढंग से काम कर पा सकते हैं ।

Comments

+1 के लिए "... लेकिन आप समय कम होने पर गैर-यूनिट परीक्षण लिखना चाह सकते हैं।"

— मार्की

अच्छा उत्तर। @ m.edmondson आपको यह भी पता चल सकता है कि आप रिफ्लेक्टर के रूप में कोड के कुछ भाग 'विशाल' हैं क्योंकि हर जगह दोहराव है और जैसे ही आप रिफ्लेक्टर करते हैं, यह छोटा और सरल दोनों हो जाता है।

— एल्ब

Answer 2

मुझे अंकल बॉब मार्टिन के लड़के स्काउट नियम का पालन करना पसंद है :

"जब आपके पास एक बड़ा गन्दा विरासत वाला वडा है, तो आपको क्या करना है ... आपको जो करना है वह गन्दा बनाना बंद कर देगा और उन्हें साफ करना शुरू कर देगा।

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

पुनरावृति से पुनरावृत्ति तक, और रिलीज़ से रिलीज़ होने तक, आप नई सुविधाओं और कार्यक्षमता को जोड़ना जारी रखते हुए इस सिस्टम को साफ़ करने जा रहे हैं। और कोई रास्ता नहीं है।"

Answer 3

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

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

Comments

मैं सहमत हूं - और अतीत में मैंने इन 'छोटे' रिफ्लेक्टर्स को शामिल किया है क्योंकि मुझे कोड को समझने के लिए बस जरूरत है - फिर भी आमतौर पर कोई व्यक्ति "आप इसे पूरी तरह से तोड़ चुके हैं" ...

— billy.bob

@ m.edmondson: आह। ठीक है, अगर उनके पास यूनिट परीक्षणों का एक व्यापक सूट था, तो बस चल रहा था जो सत्यापित करेगा कि रिफ्लेक्टर अच्छा था या नहीं। यह कैसा लगता है, उनके पास ऐसा नहीं है इसलिए आपको इकाई परीक्षण स्वयं लिखना होगा। मुझे पता है कि यह आसान नहीं है और इस समस्या का कोई वास्तविक निश्चित जवाब नहीं है (कम से कम एक ऐसा नहीं है जो मैंने पाया है, हालांकि मैं यह देखने के लिए देख रहा हूं कि अन्य लोग क्या सुझाव देते हैं जैसे मैं वहां भी हूं)।

— फ्रस्ट्रेटेडविथफोर्मेसडिजेनर

Answer 4

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

और यूनिट परीक्षण (या, उम्मीद है, मौजूदा परीक्षण सूट का विस्तार) बनाने से यह कम संभावना है कि आप अनजाने में कुछ तोड़ सकते हैं।

Answer 5

एक और टिप। जब कीड़े खुद को प्रकट करते हैं, और पट्टी लगाने के बाद वहां नहीं रुकते हैं!

पांचों से पूछें, लाल गोली लें और देखें कि खरगोश छेद कितना गहरा जाता है, और मूल कारण को ठीक करें (और वहां नीचे का रास्ता)।

आप सिस्टम के बारे में बहुत कुछ सीखते हैं। यह तय करने में मदद करता है कि क्या तय करना है और क्या करना है। और कुछ ऐसी यात्राओं के बाद आपके पास स्पेगेटी के अखंड ढेर को मजबूत करने के लिए कुछ ठोस "सपोर्ट बीम" होते हैं।

Answer 6

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

// old code
...

if (!File.ReadAllText("c:\patch_control.txt").Contains("StrangeUIBugFix=0"))
{
    // new code goes here
    ...
}

// old + new code
int someValue = 
    IsEnabled("StrangeUIBugFix") ? a + b :  // new code
    a * b; // old code

Answer 7

एक बात: Never change any existing code if you are not sure what effect change would have on complete application.