खराब कोड से निपटने के लिए कैसे करें

Question

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

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

अब मेरा प्रश्न मैं खराब कोड से निपटने के लिए कैसे सीख सकता हूं? मैं विशाल कोडबेस को समझना सीख सकता हूं और उसके बाद इसके कुछ हिस्सों को फिर से काम कर सकता हूं जो पहले से ही काम कर चुका है और समय सीमा से अधिक नहीं है? क्या कोई साहित्य है जिसे आप अनुशंसा कर सकते हैं? क्या आपके पास मेरे लिए कोई सामान्य सुझाव है?

Answer 1

माइकल फेदर्स ने इस विषय के बारे में एक अच्छी किताब लिखी।

Working Effectively with Legacy Code।

Refactoring: Improving the Design of Existing Code:

एक और महान पुस्तक मार्टिन Fowler, केंट बैक और दूसरों के द्वारा है।

Answer 2

जनरल टिप:

if (it is working) 
    Do (not touch it); 
else 
{ 
    Make (as few modifications as possible) 
    Or (it will stop working at all); 
} 

यह पीढ़ियों के अनुभव है।

Answer 3

मुझे बुरा कोड को कार्यक्षमता जोड़ने से निपटने के लिए है, तो मेरे सामान्य दृष्टिकोण है: हर महत्वपूर्ण विशेषता है कि काम करना चाहिए (सबसे बुरा कोड किसी भी परीक्षण की जरूरत नहीं है के रूप में) के लिए

• लिखें स्वचालित परीक्षण।
• कोड परिवर्तन करें।
• सुनिश्चित करें कि परीक्षण अभी भी काम कर रहे हैं।

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

Answer 4

Refactoring: Improving the Design of Existing Code

Answer 5

ठीक है, तुम, एक परियोजना मैं कुछ सभ्य संस्करण नियंत्रण का उपयोग कर की सलाह देते हैं में कोड की बड़ी मात्रा में refactor करने के लिए ताकि आप शाखा और वापस आसानी से गिर सकता है जा रहे हैं। यह देखते हुए, यह शायद एक खुला दरवाजा है, लेकिन महत्वपूर्ण आईएमओ है।

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

एस्पिरिन भी अच्छा काम करता है।

Answer 6

रिफैक्टरिंग को यूनिट टेस्ट सूट की सुरक्षा दोहन की आवश्यकता है ताकि "इसे मैंने तोड़ दिया हो?" अनुभूति। परीक्षण के कंबल में खराब कोड को कवर करने से आप अच्छे साफ कोड के लिए प्रयास करते समय आपकी सहायता करेंगे।

Pex एक उपकरण है जो मुझे विरासत कोड के लिए परीक्षण बनाने के लिए उपयोगी लगता है (यदि आप .NET दुनिया में हैं)।

विरासत कोड == बिना परीक्षण के कोड!

दया,

दान

Answer 7

यह कारकों की संख्या पर निर्भर करता है, लेकिन सबसे महत्वपूर्ण है अगर आप इसे संशोधित करने के लिए अधिकार है।

यदि आप ऐसा करते हैं, तो इसे दोबारा दोहराएं। उदाहरण के लिए, कक्षाओं/कार्यों/चर का नाम बदलें। कार्यशीलताओं को निकालें और सामान्यीकृत करें। रिफैक्टरिंग देखें: Improving the Design of Existing Code (विषय के लिए बाइबिल)। ऐसा करने से पहले यह सुनिश्चित करना कि कोड उचित संस्करण नियंत्रण (वीसी) में है और परीक्षण मामलों का एक अच्छा सेट है। वीसी आपको वापस रोल करने और अप्रत्याशित साइड इफेक्ट्स को पकड़ने में मदद करने के मामलों का परीक्षण करने देता है।

मैं वितरित संस्करण नियंत्रण जैसे Mercurial/Bazaar और Git का सुझाव देता हूं क्योंकि यह बहुत ही रिफैक्टरिंग बिल्कुल सुविधाओं को जोड़ने की तरह संरचित नहीं है।

यदि कोई परीक्षण (सामान्य) नहीं था, तो आपको उन्हें बनाना होगा। Working Effectively With Legacy Code पढ़ें। विशेष रूप से "सील प्वाइंट" के बारे में (सियामी बिल्ली के बारे में नहीं: पी)।

यदि आप क्लीनर एपीआई नहीं बनाते हैं तो क्लीनर।

उदाहरण के लिए:

Old code ==================== 
const ACT_SHOW = 'show'; 
const ACT_HIDE = 'hide'; 
function int DoThing(Object $Obj, Stirng $Action, Object $Param1, Object $Param1) { 
    ....; 
} 
Added code ================== 
enum Actions { 
    show, hide; 
}; 
class ActionDoer { 
    private obj; 
    ActionDoer($Object) { 
     this.obj = $Object; 
    } 
    function int act(Actions $Action, $Param1, $Param1) { 
     this.act($Action.toString(), $Param1, $Param1) ; 
    } 
    function int act(String $Action, $Param1, $Param1) { 
     DoThing(this.obj, $Action, $Param1, $Param1) ; 
    } 
    function int show() { 
     this.act(Actions.show, null, null); 
    } 
    function int hide(Color $ToBGColor, long $FadeTime) { 
     this.act(Actions.hide, $ToBGColor, $FadeTime); 
    } 
} 

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

उम्मीद है कि इससे मदद मिलती है।

Answer 8

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

तो मूल रूप से, यदि आपके सामने किसी ने इसे सही नहीं किया है, तो यह अच्छा होगा यदि कम से कम आप किसी भी अन्य डेवलपर के लिए समस्याओं को कम करने में मदद कर सकें जो एक ही कोड में आएगा।

Answer 9

मैं वर्तमान में इस स्थिति में हूं।

1. कोड वास्तव में कि बुरा है: मेरे दृष्टिकोण कोड को छूने से पहले कुछ सवालों के जवाब देने के लिए है? यदि हां, तो आम त्रुटियां क्या हैं? ==> शायद उन पहले
2. पर ध्यान केंद्रित करें कोड में मुख्य रनटाइम प्रवाह क्या है? शायद आप इससे कुछ संरचनाओं को त्याग सकते हैं।
3. इसे बदलने के बिना कोड को परत/मॉड्यूलर करने का प्रयास करें। इससे परस्पर निर्भरता में कुछ कमी आती है
4. परीक्षण के साथ कोड को पोक करने का प्रयास करें। यदि कोड बेस आशा से परे उलझा हुआ है: PowerMock जैसी वस्तुओं का अनुकरण करने के लिए
5. एकीकरण वातावरण उपलब्ध है, जिसमें आप पर्यावरण के निकट उत्पादन में परिवर्तनों का परीक्षण कर सकते हैं।
6. कोड बेस के हिस्सों को फिर से लिखने के लिए शर्मिंदा न हों। लेकिन, टीम डिजाइन, सिद्धांतों, समाधान

इस कठिन कार्य है, और कोई भी इसके लिए धन्यवाद करेंगे चर्चा करने के लिए

कोशिश यह बहुत अधिक नई सामग्री को लागू नहीं करने के लिए प्रयास करें। छोटे सुधारों पर गर्व करें और अच्छे काम का आनंद लें :)