कब करें रिफ्लेक्टर


32

मैंने फाउलर की अधिकांश रिफैक्टिंग पुस्तक के माध्यम से पढ़ा है और अपने पिछले बड़े और छोटे में कई अनुप्रयोगों को फिर से बनाया है।

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

मुझे लगता है कि इस पर और अधिक कठोर दृष्टिकोण होना चाहिए, लेकिन यह निश्चित नहीं है कि वे क्या हैं।

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


2
अनिवार्य रूप से, आप यही बात पूछ रहे हैं: programmers.stackexchange.com/questions/6268/… । कार्रवाई करने के लिए आपकी सीमा को छोड़कर कम है, क्योंकि लागत और जोखिम कम है, है ना?
एस.लॉट

जवाबों:


22

Refactor जब पुनर्रचना की लागत की लागत से कम है नहीं पुनर्रचना।

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


कमी और सही
ZJR

8
दूसरे शब्दों में: "यह रिफैक्टर के लायक है जब यह रिफ्लेक्टर के लायक है"। ओह। खैर, यह वास्तव में एक जवाब नहीं है, क्या यह :) Measure "cost" however you can.- ठीक है, कैसे? सवाल का सार नहीं है? उस लागत को मापते समय किस परिप्रेक्ष्य को लागू किया जाना चाहिए?
कोनराड मोरावस्की

2
@ मोरोस्की: नहीं, यह एक गलत विरोधाभास है। मैंने कहा कि यदि रिफैक्टरिंग से प्राप्त मूल्य रिफैक्टरिंग की लागत से अधिक है, तो इसे रिफैक्टर के लिए इसके लायक है। यह कहने के समान नहीं है कि "रिफैक्टर के लायक है जब यह रिफ्लेक्टर के लायक है"। रिफैक्टरिंग की लागत की गणना करें। Refactoring नहीं की लागत की गणना करें। कौन सा बड़ा है?
ब्रायन ओकले

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

1
@ ian31: सच है, आप मूल्यों की गणना नहीं कर सकते हैं, और सबसे अच्छा आप कर सकते हैं अनुमान है। फिर भी, यह केवल यह तय करने का एकमात्र वैध तरीका है कि आपके पास सीमित समय और संसाधन हैं या नहीं। आपको यह तय करने की आवश्यकता है कि क्या रिफ्लेक्टर इसके लायक है। आप "मूल्य" को कैसे परिभाषित करते हैं यह एक बहुत ही सटीक विज्ञान है। मुद्दा यह है कि, आपको आंत की भावना पर रिफ्लेक्टर नहीं करना चाहिए - "मैं कोड को पूर्ववर्ती होना चाहता हूं" के अलावा अन्य रीफैक्टरिंग करने का एक अच्छा कारण होना चाहिए।
ब्रायन ओकले

12

  1. 5 से नीचे के समारोह की चक्रीय जटिलता है?
  2. क्या आप पूरी तरह से समझते हैं कि उस लिंक का अनुसरण किए बिना साइक्लोमैटिक जटिलता क्या थी?
  3. क्या आपके पास फ़ंक्शन के माध्यम से प्रत्येक पथ के लिए एक स्वचालित परीक्षण या प्रलेखित परीक्षण मामला है?
  4. क्या मौजूदा परीक्षण के सभी मामले पास हो जाते हैं?
  5. क्या आप फ़ंक्शन को समझा सकते हैं और यह सब 1 मिनट से भी कम समय में मेरे लिए किनारे का मामला है?
  6. यदि नहीं, तो 5 मिनट के बारे में कैसे?
  7. 10 मिनटों?
  8. क्या फ़ंक्शन (टिप्पणियों सहित) में कोड की 100 से कम लाइनें हैं?
  9. क्या आप दो अन्य डेवलपर्स पा सकते हैं जो इस कोड से सहमत हैं कि दृश्य निरीक्षण से यह त्रुटि मुक्त है?
  10. क्या यह फ़ंक्शन केवल एक ही स्थान पर उपयोग किया जाता है?
  11. क्या यह फ़ंक्शन प्रदर्शन लक्ष्यों (समय / मेमोरी / सीपीयू) को पूरा करता है?

स्कोरिंग

उपरोक्त "नहीं" उत्तर जोड़ें:

  • 0-1 - आप इस पर विचार करने के बारे में क्यों सोचेंगे? आप शायद केवल चर का नाम बदलना चाहते हैं क्योंकि आप पिछले डेवलपर के नामकरण सम्मेलन को पसंद नहीं करते हैं
  • 2-5 - इसके लिए थोड़ा ट्विकिंग की जरूरत हो सकती है, लेकिन मैं इस रेंज में कुछ के लिए प्रोडक्शन रिलीज नहीं करूंगा
  • 6-8 - ठीक है, हमें शायद इसे ठीक करने की आवश्यकता है ... संभावना है कि हम इसे फिर से जारी रखने जा रहे हैं और / या हम वास्तव में यह नहीं जानते कि यह क्या कर रहा है। अभी भी बाड़ पर, लेकिन यह बहुत संदिग्ध है
  • 9+ - यह रीफैक्टरिंग के लिए एक प्रमुख उम्मीदवार है। (ध्यान दें, परीक्षण मामलों को लिखना रिफैक्टरिंग का एक रूप है)

http://mikemainguy.blogspot.com/2013/05/when-to-refactor-code.html


4
# 2 बहुत ही भद्दी लगती है और कोड के मूल्यांकन के लिए वास्तव में बेकार है । # 3 & # 4 नहीं हर कंपनी इकाई परीक्षणों का उपयोग करती है। # 8 जहाँ भी संभव हो टिप्पणियों से बचें, और 100 लाइनें बहुत अधिक हैं। मेरे पास पोर्ट्रेट मोड में 1 बड़ी वाइडस्क्रीन मॉनिटर है और मैं मुश्किल से एक ही बार में पूरे फंक्शन को देख पाऊंगा। यदि यह वास्तविक कोड की 15 से अधिक लाइनें हैं, तो पहले से ही एक ठोस कारण होना चाहिए कि आप इसे इस तरह क्यों रखते हैं। एक चेकलिस्ट के लिए यह एक अच्छा, व्यावहारिक तरीका है, लेकिन यहां बहुत सारे बिंदु बस बने हैं या इसके पीछे बिना किसी तर्क के यादृच्छिक मूल्यों का उपयोग करते हैं।
आर। शमित्ज़

8

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

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

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

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

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

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


2

मुझे लगता है कि आपके प्रश्न का उत्तर प्रत्येक डेवलपर और यहां तक ​​कि प्रोग्रामिंग के प्रभारी प्रबंधन द्वारा दिया जा सकता है।

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

एक बड़ी सॉफ्टवेयर डेवलपमेंट कंपनी में जहां समय पैसा है, यह सिर्फ इस बिंदु से आगे सीखी गई बेहतर प्रथाओं के साथ डिजाइन करना शुरू करना हो सकता है, उस विशिष्ट सॉफ्टवेयर के वर्जन 2 तक रिफैक्टरिंग के बारे में चिंता न करें?

मुझे लगता है कि जब रिफ्लेक्टर वास्तव में उस कंपनी पर निर्भर करता है, जिस पर आप वर्तमान में हैं।


2

"कब रिफ्लेक्टर करना है?"

संक्षिप्त उत्तर: हर बार जब आप कोड भरते हैं तो उसमें से बदबू आती है या उसे सुधारा जा सकता है ( बॉय स्काउट नियम )

व्यावहारिक रूप से, ऐसा होता है:

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

मुझे ऐसा लगता है कि कठिन भाग का जवाब दिए बिना "आपको रिफ्लेक्टर चाहिए": "मुझे ऐसा लगता है कि इस पर अधिक कठोर दृष्टिकोण होना चाहिए, लेकिन यह सुनिश्चित नहीं है कि वे क्या हैं।"
18

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

1

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

ग्रहण या समान आईडीई का उपयोग करना, जिसमें मजबूत रीफैक्टरिंग समर्थन है, रिफैक्टरिंग करने के प्रयास को कम कर देता है। जैसे ही आप अतिरिक्त प्रयास के रूप में देखते हैं, आईडीई समर्थन इसे और अधिक संभावना बनाता है, जैसे ही आप "तीसरी बार" (या आवश्यकता देखें) को हिट करेंगे।

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


1

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

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


1

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

जैसा कि आप काम करते हैं, लगातार रिफ्लेक्टर। टेस्ट ड्रिवेन डेवलपमेंट का उपयोग करें ताकि आपके पास दिन के दौरान कई लाल-हरे-परावर्तक चक्र हों। आपके द्वारा स्पर्श किए गए कोड के कुछ हिस्सों को रिफलेक्टर करें।

एक बार जब आप अपने बारे में अधिक सुनिश्चित हो जाते हैं, तो आप इस आहार से भिन्न हो सकते हैं।


1

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

तकनीकी कारणों से, कई हैं।

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

एक स्कैम मास्टर के रूप में, हमारे पास एक डेवलपर था जिसने लगातार तर्क दिया कि टीम ने जो सोचा था, उसकी तुलना में हर कहानी टीम का आकार बड़ा था, और महसूस किया कि वह कोड के हर टुकड़े को फिर से भरना चाहता था। इस प्रकार, एक 3 बिंदु कहानी हमेशा उसके लिए एक 8 थी। स्पष्ट रूप से यह मूल्य के वितरण को बढ़ा रहा था। इसलिए किसी तरह रिफ्लेक्टर कब, और कैसे बनाया जाना चाहिए, इसकी कुछ समझ होनी चाहिए। बस मेरा विचार, उस (और कुछ अन्य) अनुभव से।
कर्टिस रीड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.