कोड अनुरक्षण: एक बुरा पैटर्न रखते हुए जब नए कोड को सुसंगत होने के लिए विस्तारित किया जाता है, या नहीं?


45

मुझे किसी प्रोजेक्ट के मौजूदा मॉड्यूल का विस्तार करना है। मुझे यह पसंद नहीं है कि यह किया गया है (बहुत सारे विरोधी प्रतिरूप, जैसे कॉपी / पेस्ट कोड)। मैं कई कारणों से पूर्ण रिफ्लेक्टर नहीं करना चाहता।

क्या मैं:

  • मौजूदा कन्वेंशन का उपयोग करके नए तरीके बनाएं, भले ही मुझे यह गलत लगे, अगले अनुचर के लिए भ्रम से बचने और कोड बेस के अनुरूप होने के कारण?

या

  • कोड में एक और पैटर्न शुरू करने पर भी मुझे जो अच्छा लगता है उसका उपयोग करने की कोशिश करें?

पहले उत्तर के बाद संपादित किया गया जेल:

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

मैं रिफ्लेक्टर नहीं करना चाहता क्योंकि मेरे पास समय नहीं है। और समय के साथ भी यह उचित होगा कि एक पूरी तरह से काम कर रहे मॉड्यूल को रिफैक्टिंग की जरूरत है। रिफैक्टिंग लागत इसके लाभों से अधिक भारी होगी। याद रखें: कोड गन्दा या अधिक जटिल नहीं है। मैं वहाँ कुछ तरीके नहीं निकाल सकता और यहाँ एक अमूर्त वर्ग का परिचय दे सकता हूँ। यह डिजाइन में एक दोष है (अत्यधिक 'इट इट स्टुपिड सिंपल' का परिणाम) मुझे लगता है कि

तो यह सवाल भी इस तरह से पूछा जा सकता है:
आप, डेवलपर के रूप में, क्या आप आसान बेवकूफ उबाऊ कोड को बनाए रखना पसंद करते हैं या कुछ सहायक हैं जो आपके स्थान पर बेवकूफ उबाऊ कोड करेंगे?

आखिरी संभावना के उलट कि आपको कुछ चीजें सीखनी पड़ेंगी और हो सकता है कि आपको पूर्ण रीफैक्टरिंग होने तक आसान बेवकूफ बोरिंग कोड भी बनाए रखना होगा)


बहुत दिलचस्प सवाल!
फिलिप

1
आसान उबाऊ बेवकूफ कोड बनाए रखना - परिभाषा के द्वारा आसान है। मैं बल्कि एक आसान जीवन चाहता हूं और प्रत्येक दिन जल्दी छोड़ देता हूं।
जल्दी से

हाँ, लेकिन मैं उबाऊ बेवकूफ कोड करने के लिए बहुत आलसी हूँ :) मैं कुछ ऐसा बनाने के लिए 2 या 3 दिनों के लिए कड़ी मेहनत करना पसंद करूँगा जो मेरे लिए यह हिस्सा करेगा!
गिलियूम

1
बेवकूफ या बोरिंग कब आसान हो गया?
एरिक रेपेन

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

जवाबों:


42

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

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

अपडेट करें

रिफैक्टरिंग लागत इसके लाभों से अधिक भारी होगी। [...] आप डेवलपर के रूप में, क्या आप आसान बेवकूफ बोरिंग कोड बनाए रखना पसंद करते हैं या कुछ ऐसे हेल्पर्स हैं जो आपकी जगह पर बेवकूफ बोरिंग कोड करेंगे?

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

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

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


7
यह कोड के जाल में गिरना इतना आसान है 'कोड पहले से ही बेकार है, साथ ही इसे चालू रख सकता है ...' अच्छा प्रोग्रामर नहीं। अच्छा जवाब।
sevenseacat

हालांकि यह सबसे सुरक्षित दृष्टिकोण होने की संभावना है (कोड परीक्षण के लिए काम करने के लिए गारंटी है) यह अभी भी प्रश्न में वर्णित समस्या का परिणाम है। एक अलग पैटर्न कोड में पेश किया गया है। आम तौर पर, मेरा मानना ​​है कि आपको अपना समय एक बार में सब कुछ ठीक करने के लिए लेने की कोशिश करनी चाहिए (जब TDD कर रहा है, मध्यवर्ती चरणों के साथ सबसे अच्छा) तो आपके पास उस मध्यवर्ती असंगत स्थिति नहीं है। समाप्त होने पर, अपने कोड को स्रोत नियंत्रण के लिए प्रतिबद्ध करें।
स्टीवन ज्यूरिस

2
@ ठीक है, अगर आप इसे वहन कर सकते हैं तो एक बार में सब कुछ रिफलेक्टर करना ठीक है । अधिकांश वास्तविक जीवन की परियोजनाओं में, आप केवल सब कुछ रोक नहीं सकते हैं और केवल रिफ्लेक्टर के लिए कई दिनों या हफ्तों तक एक पंक्ति में बिता सकते हैं। यहां तक ​​कि अगर आप भाग्यशाली हैं कि एक प्रबंधक है जो इसका समर्थन करता है, तो परियोजना को अभी भी रोल करने की आवश्यकता है।
पेर्ट टॉर्क

1
@ सही, यह निर्भर करता है - ऊपर मेरा अपडेट देखें।
पेर्ट टॉर्क

1
@ Péter Török: अच्छा अपडेट! खाते में लेने के लिए वास्तविक दुनिया के कारकों का सही वर्णन।
स्टीवन ज्यूरिस

4

चूँकि आपके पास रिफ्लेक्टर करने का समय नहीं है और कोड मेंटेन है, इसलिए इसे लगातार रखें। अगली बार अनुमान में रिफैक्टरिंग को शामिल करना सुनिश्चित करें।


3

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

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


3

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

मैंने डेवलपर्स को कुछ करने के लिए "बेहतर तरीका" ढूंढने के परिणामस्वरूप बहुत गन्दा कोड देखा है, लेकिन इसे एक कोडबेस पर लगातार लागू नहीं किया। यदि यह समय के साथ-साथ नए पैटर्न को लागू करने के लिए योजनाबद्ध और समन्वित रणनीति का हिस्सा है, तो यह समय के साथ धीरे-धीरे काम कर सकता है, लेकिन असंगत रूप से लागू किए गए प्रत्येक पैटर्न में समग्र प्रणाली को बदतर बनाने का जोखिम होता है।

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


+1 "फिर आपके पास एक ही काम करने के तीन अलग-अलग तरीके हैं।" मैंने यह देखा है कि मैंने जिस भी एंटरप्राइज प्रोजेक्ट पर काम किया है। मैं कहूंगा कि आप तब तक रिफैक्टर करने की कोशिश नहीं करेंगे, जब तक आप कोड को दस्त नहीं कर देंगे, यह सुनिश्चित करने के लिए कि पहले से ही कोड का कोई दूसरा टुकड़ा नहीं है जो बदसूरत कोड की देखभाल करने का प्रयास कर रहा है जो आपने तय किया था कि आप रिफ्लेक्टर करना चाहते हैं। कभी-कभी बॉयलरप्लेट सम्मेलन के साथ चिपकना सबसे अच्छा होता है, कम से कम जब तक आपने कोड को पूरी तरह से पढ़ा नहीं होता है।
TK-421

1

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

मेरी राय में यह एक आम गलत धारणा है जिसका पालन करने के लिए रिफैक्टेड कोड कठिन है। यह आमतौर पर उन लोगों का एक तर्क है जो केवल उस चीज से परिचित हैं जिसे रिफैक्ट किया जा रहा है, न कि रिफैक्ट किए गए परिणाम। नए लोगों के लिए, रिफलेक्ट किए गए परिणाम स्पष्ट होंगे।

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

Péter Török के उत्तर से संबंधित अपडेट: क्या "क्योंकि इसमें समय लगता है" को स्थगित करने से नहीं होता है, बाद में इसे फिर से भरने का समय बढ़ जाता है? जब अधिक बार किया जाता है, तो रिफैक्टरिंग को लंबा नहीं होना चाहिए।

अपने बॉस को कैसे समझाएं कि आप कुछ दिनों का कोड लिखने में बिताएंगे जो उत्पाद में कुछ भी नहीं जोड़ता है, मुश्किल है, और एक पूरी तरह से अलग सवाल है। :)


1
"अपने बॉस को कैसे समझाएं कि आप कुछ दिनों का कोड लिखने में बिताएंगे, जो उत्पाद में कुछ भी नहीं जोड़ता है, मुश्किल है, और एक पूरी तरह से अलग सवाल है।" अच्छी कोशिश ;-) दुर्भाग्य से वास्तविक जीवन में हमें इसे भी हल करने की आवश्यकता है। इसलिए छोटे चरणों में जाना अधिक व्यावहारिक है। आधे घंटे के रिफैक्टरिंग को दो घंटे के काम के हिस्से के रूप में किया जा सकता है, आपके प्रबंधक को भी इसके बारे में जानने की आवश्यकता नहीं है। OTOH के दो पूरे दिन बिताए हुए शायद ही किसी का ध्यान जाता है।
Péter Török

@ Péter Török: मैंने पोस्ट को थोड़ा अपडेट किया। बेशक, आपके पास अभी भी वास्तविक विश्व स्थितियां हैं जहां आपको रिफैक्टिंग के लिए समय निकालने की अनुमति नहीं है। लेकिन मैं दृढ़ता से मानता हूं कि सिद्धांत रूप में यह हमेशा समय प्राप्त होता है। (जब तक आप जानते हैं कि आप जिस कोड पर काम कर रहे हैं, वह निकट भविष्य में अब समर्थित नहीं होगा)
स्टीवन ज्यूरिस

जैसा कि वे कहते हैं, सिद्धांत में अभ्यास और सिद्धांत के बीच बहुत अंतर नहीं है। हालाँकि, व्यवहार में ... :-) वास्तविक जीवन में आपको हमेशा रिफैक्टिंग पर खर्च की गई लागत वापस नहीं मिल सकती है। मैंने इस पर अपना जवाब बढ़ाया।
पेर्ट टॉरक

1
दोहराए गए कोड को हटाने वाला रिफैक्टरिंग हमेशा अच्छा नहीं होता है; यह संभव है कि दो तरीके आज के व्यावसायिक नियमों के तहत समान हो सकते हैं, लेकिन यह कल की नहीं है। उदाहरण के लिए, किसी के AcmeLockerBankपास एक getRow(int itemIndex)विधि हो सकती है जो वापस आती है index % 5और AcmeButtonPanelएक समान विधि हो सकती है क्योंकि लॉकर और बटन बोर्ड दोनों चीजों को एक ही तरह से नंबर करते हैं; अगर आज के किसी भी लॉकर बैंक में 1000 से अधिक के इंडेक्स वाले आइटम नहीं हैं, लेकिन कुछ बटन पैनल करते हैं, और भविष्य के लॉकर 1000-1999 रेंज में सूचकांकों के लिए एक अलग पंक्ति रिक्ति का उपयोग करते हैं ...
सुपरकैट

1
... लॉकर बैंकों के लिए अतिरिक्त व्यवहार जोड़ना आसान होगा यदि लॉकर बैंकों और बटन बैंकों के अलग-अलग getRowतरीके हैं, लेकिन फ़ंक्शन एक सामान्य विधि में विलय कर दिया गया है, तो अधिक मुश्किल हो सकता है।
सुपरकैट १।

0

क्या आप एक नया इंटरफ़ेस / कक्षाएं नहीं बना सकते हैं जो पुराने कोड पर एक मुखौटा के रूप में काम करता है, जबकि अपने खुद के स्टाइल में अपने नए कोड को पेश करना, जिसे आसानी से बढ़ाया जा सकता है?


0

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


0

आप, डेवलपर के रूप में, क्या आप आसान बेवकूफ बोरिंग कोड बनाए रखना चाहते हैं या कुछ ऐसे हेल्पर्स हैं जो आपकी जगह पर बेवकूफ बोरिंग कोड करेंगे?

मैं संशोधित प्रश्न नहीं समझता। मुझे लगता है कि ज्यादातर लोग, खुद के रूप में, "बेवकूफ बोरिंग कोड" को बनाए रखना पसंद नहीं करेंगे। मुझे नहीं पता कि आपको हेल्पर से क्या मतलब है, क्षमा करें।

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

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

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