आप एक गैर-तकनीकी व्यक्ति को रिफैक्टिंग कैसे समझाते हैं?


52

आप एक गैर-तकनीकी व्यक्ति (आमतौर पर PHB या ग्राहक) को रिफैक्टरिंग (और तकनीकी ऋण) के बारे में कैसे समझाते हैं? ("क्या, यह मुझे कोई फर्क नहीं दिखाई देने के साथ अपने काम का एक महीना खर्च करने जा रहा है !"

अद्यतन करें अब तक के सभी जवाबों के लिए, मुझे लगता है कि यह सूची कई उपयोगी उपमाएँ प्रदान करेगी, जिनसे हम उपयुक्त लोगों को इंगित कर सकते हैं (हालांकि PHBs के संदर्भों को संपादित करना बुद्धिमान हो सकता है!)


मुझे याद नहीं है कि Apple ने तेंदुए से स्नो लेपर्ड में बदलने के लिए कितने लोगों को आश्वस्त किया था। संभवतः मूल्य: उस समय सामान्य से $ 100 कम।
मौविसील

यह प्रश्न उद्योग में कोड के साथ काम करने वाले किसी के लिए आश्चर्यजनक रूप से उपयोगी प्रतिक्रिया दे सकता है। लोगों पर ध्यान दें।
joshin4colours

यह समझदारी क्यों होगी?
लुईस

जवाबों:


53

जब आपके पास एक बड़ा होम थिएटर होता है और आप चीजों को जोड़ते हैं, तो धीरे-धीरे लेकिन निश्चित रूप से पीठ में एक बड़े चूहों का घोंसला बनता है।

यदि आप कई बार भागों की जगह लेते हैं, तो कभी-कभी इसका सारा सामान सीधा हो जाता है।

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

किसी भी मामले में शायद किसी विषय क्षेत्र की इसी तरह की तुलना करने के लिए इसका सबसे अच्छा PHB या ग्राहक पहले से ही परिचित है, अर्थात कार या निर्माण या अन्य ...


1
सबसे अच्छा सादृश्य नहीं है क्योंकि यह खराब सामान की तरह आवाज करता है बस अपने थिएटर में अनायास क्रॉल करता है, जैसा कि आपके थिएटर के लगातार निर्माण के प्रत्यक्ष परिणाम के रूप में दिखने वाले खराब सामान का विरोध करता है।
डोपेलग्रेनेर

21
@ एक्सीडोस: "चूहों का घोंसला" एक अंग्रेजी मुहावरा है जिसका अर्थ है "उलझन को पूर्ववत करना असंभव है" (इस मामले में, मनोरंजन केंद्र के पीछे डोरियों और केबलों का)
हेजमैज

8
वैचारिक रूप से इसकी बहुत अच्छी - जरूरतों "केबल" के बाद "चूहों के घोंसले"
मर्फ़

2
@Peter: मुझे लगता है कि हम सभी को कम से कम एक बार टीवी के पीछे जाना होगा। बस इसे सौ गुना बदतर समझाएं और हर जगह केबलों का एक धागा स्पिन करें और इसे खींच कर खींच लें और गंदगी में कहीं मृत सभ्यता की खोज करें।
doppelgreener

3
यदि कोई संबंधित नहीं कर सकता है, तो उन्हें यह दिखाएं: google.com/images?q=do+not+touch+any+of+these+wires
स्टीव एस

41

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


1
मैं गैराज या शेड के साथ कुछ सादृश्य पोस्ट करने जा रहा था, लेकिन यह बेहतर है।
मैट एलेन

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

+1 यह बहुत अच्छा है। कम जगह घेरने वाली चीजों को बनाने के साथ-साथ आपको ऐसा एहसास होता है कि आपको इसकी बिल्कुल भी जरूरत नहीं थी और इसलिए इसे छोड़ सकते हैं।
रोबी डे

21

मैं तकनीकी ऋण की अवधारणा की व्याख्या नहीं करूंगा, क्योंकि यह आवश्यक नहीं है। इसके बजाय, रिफैक्टिंग पर ध्यान केंद्रित करें: आप अपने प्रोग्राम के डिज़ाइन को बदल रहे हैं, जरूरी नहीं कि यह "बेहतर" या "बेहतर" हो, आप इसे बदल रहे हैं ताकि यह एक बदलाव को स्वीकार कर सके जिसे आपको बनाने की आवश्यकता है।

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

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


बेहतर प्रदर्शन या आसान रखरखाव देने के लिए कार में भागों को स्थानांतरित करना - किसी के लिए भी काम करता है जिसने अपनी कार पर ढक्कन उठा लिया है, लेकिन कितने PHB ने ऐसा किया है?
पीटर बॉटन

3
मुझे यह पसंद है क्योंकि यह इस बात पर जोर देता है कि आवश्यक बदलाव को आसान (या संभव) बनाने के लिए रिफैक्टरिंग की जा रही है। आम तौर पर अपने स्वयं के खातिर रिफैक्टरिंग नहीं की जानी चाहिए, लेकिन एक विशिष्ट लक्ष्य को पूरा करने के लिए।
क्रिस्टोफर जॉनसन

तो, संक्षिप्त उत्तर बन जाता है: उन्हें मत बताना! नए फीचर्स और रिफ्लेक्टर में समय के हिसाब से सिर्फ कारक।
जोनाथन वैन डे वीन

12

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

हालांकि, यदि आप ऐसे ऋण पर 25% ब्याज दे रहे हैं, तो आप खुद को एक गैर-स्थायी स्थिति में डाल सकते हैं। तकनीकी ऋण के साथ भी यही है। कभी-कभी यह कुछ तकनीकी ऋण लेने के लिए समझ में आता है। हालांकि, एक बिंदु आता है जहां ब्याज बहुत अधिक है और इसे चुकाने की जरूरत है। कुछ टेचिंकल डेट होम लोन की तरह है और कुछ क्रेडिट कार्ड डेट की तरह है। आपात स्थिति में क्रेडिट कार्ड ऋण एक महत्वपूर्ण और मूल्यवान संपत्ति है। हालाँकि, यह बैंक का उपयोग कर सकता है (या यदि आप चुनते हैं)

एक अन्य उदाहरण: आप भविष्य में बिक्री के लिए और अधिक नेतृत्व करने के लिए एक विपणन मेल ड्रॉप के लिए $ 10,000 का भुगतान कर सकते हैं। आप "बिक्री ऋण" का भुगतान कर रहे हैं। यह लंबी अवधि के भुगतान के साथ एक खर्च है। इस बात की बराबरी करें कि आप क्यों "पैसा खर्च" करना चाहते हैं, अब कोड का एक टुकड़ा फिर से बेचना। दोनों ही मामलों में तत्काल भुगतान नहीं होता है, लेकिन आप भविष्य में बेहतर प्रदर्शन के लिए खुद को स्थापित कर रहे हैं।

"एक्सएक्सएक्सएक्स ऋण" शब्द का उपयोग मैं एक सादृश्य के रूप में करता हूं जब लक्ष्य दर्शकों से बात करना है। जैसे, ऑपरेशनल डेट - प्रिंटिंग प्रेस हमारे पास अब अच्छी तरह से काम करता है, लेकिन एक दिन (या एक सप्ताह) के लिए उत्पादन रोककर और एक नई मशीन में अपग्रेड करके हम आउटपुट को 25% बढ़ा सकते हैं।

संपादित करें - यहाँ इस पर एक अन्य टेक है


1
+1 एक उचित उत्तर के लिए जो यथार्थवादी अर्थशास्त्र को प्रदर्शित करता है। ऋण कई बार तर्कसंगत होता है, और शुद्धतावादी बहुत सारे अवसरों को याद करते हैं यदि वे इसे बर्दाश्त नहीं कर सकते।
मैक्नील

1
और लोग समझते हैं कि पुराने ऋणों पर ब्याज का भुगतान करने के लिए ऋण लेना टिकाऊ नहीं है।
क्रिस्टोफर महान

1
यह स्पष्टीकरण के लिए मेरी प्राथमिकता है, क्योंकि मुझे सब कुछ स्क्रैप करने और फिर से लिखने के लिए संदर्भित करना पसंद है (जो कि अक्सर तकनीकी दिवालियापन के
वेन मोलिना

4
यह एक भयानक जवाब है। (1) यह रीफैक्टरिंग की तकनीकी व्याख्या से अधिक जटिल है। (2) यह "क्यों" का वर्णन नहीं करता है, जो कि रिफैक्टिंग है; यह "जब" की व्याख्या करता है (यानी: जब यह लागत प्रभावी है)। या शायद मैं वास्तव में इस पोस्ट को समझ नहीं पा रहा हूं, और इसलिए बिंदु (1)।
थॉमस ईडिंग सेप

2
@ThomasEding (1) यह रिफैक्टरिंग का स्पष्टीकरण नहीं है, यह तकनीकी ऋण का स्पष्टीकरण है। (२) यह इस बात की व्याख्या करता है कि कब क्या करना चाहिए - किसी व्यवसायी को। ईमानदारी से, वे तकनीकी कारण की परवाह नहीं करते, आप करते हैं। वे एक उचित कारण चाहते हैं जो आप अगली विशेषता के अलावा किसी अन्य चीज़ पर काम कर रहे हैं जो बिक्री को चलाएगी। यही कारण है कि अधिकांश प्रोग्रामर अपने बॉस से बात नहीं कर सकते हैं और शिकायत कर सकते हैं कि बॉस बेवकूफ है। वे मूर्ख नहीं हैं, उनके पास आपसे अलग ड्राइवर हैं।
नेमी

8

वसंत सफाई।

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


1
+1: यह सबसे अच्छा उत्तर है imo: और बहुत अधिक कोई भी संबंधित कर सकता है। "आप अपने घर में रहते हैं, चीजें गंदी / धूल भरी होती हैं।
स्टीवन एवर्स

7

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

आप आश्चर्यचकित हो सकते हैं कि हमने पहली बार माउस ट्रैप जैसा क्यों दिखना शुरू किया:

  • कभी-कभी कुछ सही होने का मतलब है कि हमें "इसे काम करने के लिए" लालित्य और दक्षता का त्याग करना होगा।
  • प्रोग्रामर के रूप में हमारे लिए उपलब्ध भाषा सुविधाएँ और अन्य प्रौद्योगिकियाँ अक्सर बदलती रहती हैं। कभी-कभी नई विशेषताएं हमें एक के साथ छह चलती भागों की एक बारीक जंबल की जगह देती हैं।
  • अक्सर, जब हम A और B के फीचर्स में फीचर C जोड़ते हैं, तो हम यह नहीं जानते कि B आखिरकार गिराया जाएगा और D जोड़ा जाएगा। C को पूरा करने का एक तरीका B के साथ बहुत अच्छा काम कर सकता है, लेकिन D के साथ बहुत अच्छा नहीं।

एक बेहतर माउस जाल का निर्माण करने के प्रयास में, हमें लगातार वापस जाना होगा और जटिलता को कम करने के लिए स्थानों को ढूंढना होगा और जो हमारे पास है उसे कारगर बनाना होगा। यह बहुत सारी विशेषताओं वाले सॉफ़्टवेयर के बीच का अंतर है, और वास्तव में उच्च-गुणवत्ता वाला सॉफ़्टवेयर है। "


6

वैकल्पिक शब्द

यह होम थियेटर सादृश्य का थोड़ा अधिक चित्रमय संस्करण है।

यदि आप एक और नया उपकरण जोड़ना चाहते हैं [उर्फ, नई कार्यक्षमता], एक चुटकी पर आप शायद इसे कहीं में फिट कर सकते हैं।

यदि आप अभी तक एक और उपकरण जोड़ना चाहते हैं, तो आप एक एक्सटेंशन लेड खरीद सकते हैं, जो आपको कुछ समय खरीदेगा।

लेकिन प्रत्येक जोड़ पर, एक समाधान खोजना अधिक कठिन हो जाता है। और तुम अपने आप को एक करने के लिए उजागर कर रहे हैं जोखिम 1 आग [उर्फ कीड़े] की है, और आप बड़े रुपये बाहर निकलने के लिए किसी को भुगतान करने के लिए दीवार, जो काफी संभवतः मुख्य अप करने के लिए सभी तरह से बढ़ा सकता है में नए सॉकेट डाल करना होगा सर्किट बोर्ड, या आगे भी।

1 एक और बात PHB बहुत अच्छी तरह से नहीं गाती है: "ठीक है अगर यह केवल हो सकता है, तो आप किस बारे में चिंता कर रहे हैं?"


5

Refactoring - अपने कपड़े कैबिनेट / उपकरण दराज का आयोजन करने जैसा है।

  • आप अपने कपड़े / उपकरण सिर्फ इसलिए नहीं फेंकते क्योंकि वे सभी जगह पर हैं।

  • आप तर्क दे सकते हैं कि उन्हें कभी भी अव्यवस्थित नहीं होना चाहिए। लेकिन वे करते हैं।

जैसे कोड करता है। विशेष रूप से यह समय के साथ बढ़ता है।

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


4

मैं कहूंगा कि "कोड रखरखाव" । उन शब्दों का उपयोग करना महत्वपूर्ण है जो गैर-तकनीकी व्यक्ति से परिचित हैं और जो गैर-तकनीकी दुनिया के दृष्टिकोण से समझ में आते हैं। यदि गैर-तकनीकी व्यक्ति (ग्राहक) आवेदन रखरखाव से परिचित है, तो कोड रखरखाव और अनुप्रयोग रखरखाव के समानांतर बनाना आसान है। यहां तक ​​कि अगर वे समान नहीं हैं, तो आप समझा सकते हैं कि यहां अंतिम ग्राहक डेवलपर्स हैं या जो सिस्टम को बनाए रखते हैं।


1
गैर तकनीकी लोग अनुप्रयोग रखरखाव के साथ पारिवारिक हैं? मैंने अपनी दादी से पूछा: वह ऐसी नहीं है जो मुझे मिली सबसे गैर तकनीकी व्यक्ति है। इसके अतिरिक्त: चूंकि एक गैर तकनीकी व्यक्ति कोड और एप्लिकेशन के बीच अंतर नहीं जानता है ("यदि कोड एप्लिकेशन है, तो एप्लिकेशन कोड है") आपका सादृश्य काम नहीं करेगा।
मार्टिन

2
जिन स्थानों पर मैंने काम किया है, विपणन और प्रोजमैन प्रकारों ने "रखरखाव" को "रिलीज के बाद बग फिक्स" के रूप में समझा है, और यह दावा करने के लिए अपमानजनक होगा कि रिफैक्टरिंग कीड़े को ठीक कर रहा है।

मेरे लिए गैर-तकनीकी व्यक्ति ग्राहक है। यदि ग्राहक जानता है कि आवेदन रखरखाव क्या है तो उसे कोड रखरखाव को समझना चाहिए।
अमीर रज़ाई

"कोड रखरखाव" लगता है जैसे आपका कोड पहनने और फाड़ने या उपयोग करने से गुजरता है। एक कार को बनाए रखने की आवश्यकता होती है, क्योंकि सामान्य उपयोग इसके घटकों पर जोर देता है, तरल पदार्थ का उपयोग करता है, आदि। एक आवेदन ऐसा नहीं है - हार्ड ड्राइव पर बैठे कोड "उम्र" या "खराब हो" नहीं जाता है।
दान रे

मैं आपको रखरखाव पर कुछ उदाहरण दूंगा: प्रदर्शन के मुद्दे। आपका घटक, संपूर्ण सिस्टम या एप्लिकेशन VB में लिखा गया है और Microsoft इसका समर्थन करना बंद कर देता है। ओएस आपके कोड पर आधारित तकनीक का समर्थन नहीं करता है। सुरक्षा मुद्दे। इन मुद्दों पर रखरखाव किसी भी नई कार्यक्षमता को नहीं जोड़ता है जो अंतिम उपयोगकर्ता को नोटिस कर सकता है, हालांकि वे "एप्लिकेशन" को जीवित रखने के लिए महत्वपूर्ण हैं।
अमीर रज़ाई

4

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

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

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

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

एक महीने बाद वह वापस आता है, इस बार वह एक प्रकाश व्यवस्था चाहता है और वह चाहता है कि नए वक्ताओं को पहले वाले सप्ताह में पुराने नुकसान हो।

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

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

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

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

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

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

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

यहाँ आपका सॉफ्टवेयर है, सब किया है, आशा है कि आप इसे पसंद करेंगे .... हो, वैसे, मैंने आपके क्रेडिट कार्ड को अधिकतम कर दिया है, आशा है कि आप नहीं ... cya


3

फिर से फैक्टरिंग की बात यह है कि डिजाइन को सरल बनाना और अक्षमताओं को दूर करना है। इससे बग को ठीक करना और भविष्य में नई सुविधाओं को जोड़ना आसान हो जाता है।

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

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


लेकिन clever == 0ऐसा है 2 * clever == 0...
थॉमस ईडिंग सेप

3

सॉफ्टवेयर लिखना एक बहुत बड़ी गैर-काल्पनिक किताब, या एक विश्वकोश लिखने जैसा है।

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

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


3

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

एक दिन बाद जब आप अपने स्पीकर पर संतुलन बदल रहे होते हैं, तो आपको एहसास होता है कि आपने गलती से अपने बाएं और दाएं स्पीकर को गलत क्षेत्रों में डाल दिया है, इसलिए आप उनके पदों को स्वैप करना चाहते हैं। लेकिन अरे नहीं! पेचीदा डोरियों का जंगल है; जब आप स्पीकर को स्थानांतरित करने के लिए आगे बढ़ते हैं, तो आपका माउस कॉर्ड हुक हो जाता है, और अब आपका माउस स्पीकरों के साथ खींच लिया जाता है। इसके अलावा, आपके कीबोर्ड में अब कोई सुस्ती नहीं है - आप इसे डेस्क से अपनी गोद में ले जाने में सक्षम होते थे।

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

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

मुख्य मुद्दा यह है कि मूल समाधान ज्यादातर काम करता है। यह रिफैक्टिंग के बारे में बात है: यह के साथ शुरू करने के लिए काम करता है, लेकिन आपको यह बदलने की आवश्यकता है कि भविष्य में परिवर्तन (बोलने वाले) को आसानी से बनाने के लिए चीजें पहले से मौजूद हैं।


2

यह थोड़े पहले की रात से एक जंगली और पागल पार्टी के बाद घर को साफ करने जैसा है।

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

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

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

आप चारों ओर देखते हैं और देखते हैं कि अगर वे समान ऊंचाई पर होते तो खिड़की की छाँव ज्यादा अच्छी लगती। किया हुआ। वाह, कमरा अद्भुत है।

अपने कोड को उसी तरह से समझो।


1
मुझे यह पसंद है, लेकिन मैं इसे रसोई की सफाई में बदल दूंगा। थोड़ी देर के लिए खाना पकाने नहीं, लेकिन बाद में चीजें बेहतर होंगी। PHB को कंपनी समय पर पार्टी करने से संबंधित कठिनाई हो सकती है :)
Jaap

सादृश्यता, लेकिन एक दोष यह है कि पाठकों को इसके बारे में पता होना चाहिए: यदि आप अपने घर को साफ नहीं करते हैं, तो आपका घर सचमुच समय के साथ कम उपयोग करने योग्य हो जाता है। जबकि एक कार्यक्रम के साथ, ऐसा नहीं होता है।
थॉमस ईडिंग सेप

1

आसान!

इसे एक उदाहरण के साथ लें ... हर किसी ने अपने जीवन में एक प्रिय को एक पत्र लिखा है। यह किसी को प्रिय होना है क्योंकि उन पत्रों में हम आमतौर पर रचना पर भी ध्यान देते हैं।

तो, आपके पास आपका पाठ है, ... अर्थ किसी भी तरह से गुजरेगा, लेकिन आप चाहते हैं कि पूरी बात अच्छी लगे! सही?

Refactoring, एक ही बात ... एक ही जानकारी के टुकड़े, कम या ज्यादा, लेकिन रचना बेहतर है। और यह शायद पाठक द्वारा एक बेहतर समीक्षा का परिणाम देगा।

एक अन्य उदाहरण - एक पत्रिका के लिए एक लेख लिखना। दो लेखक, दोनों "अपना सामान" जानते हैं, एकमात्र अंतर यह है कि "कैसे लिखना है" और दूसरा लिखते हैं जैसे उन्होंने इन जैसे उत्तरों से लिखना सीखा।

आपको किसका लेख याद होगा?


1

भौतिक दुनिया में चीजों की सभी उपमाएँ - जैसे कि रंगमंच का निर्माण - हैं, IMO, भयानक।

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

हम रिफ्लेक्टर क्यों लगाते हैं? क्योंकि कोड जिसे कभी भी रिफैक्ट नहीं किया जाता है, उसे बनाए रखने और बदलने में प्रति मिनट अधिक खर्च होता है, और अंततः अधिक समस्याग्रस्त हो जाता है।

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


/ सभी उपमाएं /? मैं दृढ़ता से असहमत हूँ। आपको बस अधिक रचनात्मक होने की आवश्यकता है। इसके अलावा ओपी के सवाल का जवाब नहीं है।
थॉमस एडिंग

@ThomasEding आपकी टिप्पणी के लिए धन्यवाद। मैं दूसरे बिंदु पर असहमत हूं: मैं वास्तव में सवाल का जवाब दे रहा हूं। हालाँकि, मैं अभी आपके लिए एक संपादन करूँगा।
डैन रोसेनस्टार्क

0

री-फैक्टरिंग कुछ साफ करने और सामान को 'रहने' के लिए एक नई जगह देने के समान है

आसान सरल और कुछ ऐसा जो बहुत समय ले सकता है। कभी-कभी मैं यह भी जोड़ता हूं कि एक्स ने चीजों की एक बड़ी गड़बड़ी छोड़ दी है और मुझे इसे साफ करना होगा।


0

मैंने एक और उदाहरण के बारे में सोचा, जिसका जाहिर तौर पर यहां किसी ने भी उल्लेख नहीं किया है: रिफैक्टिंग, मैथ्स में एक समीकरण को फिर से व्यवस्थित करने के समान ही है (हालांकि यह 'गैर-तकनीकी व्यक्ति के दायरे से बाहर हो सकता है, मुझे लगता है)।

जब आप एक समीकरण को पुनर्व्यवस्थित करते हैं, तो आप अर्थ बदलने के बिना , इसे और अधिक पठनीय और अधिक उपयोगी बनाने के लिए 'चारों ओर सामान ले जाएँ' ।


1
इसलिए यदि मैं PHB या ग्राहक हूं (जो इस रीफैक्टरिंग प्रयास के लिए भुगतान करने जा रहा है), तो मुझे क्यों परवाह करनी चाहिए? कोड काम करता है (मेरे दृष्टिकोण से)
21

0

उन्हें एक सरल गणित समीकरण दें। उदाहरण के लिए:

कौन सा सरल है?

y = x + x

या

y = 2x

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

सरलतम रीफैक्टरिंग जो किया जा सकता है उसका नाम बदल रहा है।

doX() { ... }
{
   doX()
}

अब क्योंकि हम वास्तव में चीजों को doX कहलाना नहीं चाहते हैं क्योंकि हम वास्तव में नहीं जानते कि इसका क्या मतलब है, हम इसका नाम बदलकर कुछ और करते हैं जो अधिक आत्म व्याख्यात्मक है और कहीं भी हमने इसका इस्तेमाल किया है।

doBusinessTransaction() { ... }
{
   doBusinessTransaction()
}

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


1
मैं वास्तव में इस सादृश्य को पसंद करता हूं क्योंकि यह सभी के लिए समझ में आता है और वास्तव में खुद को कोड के समान है।
वेंकट डी।

धन्यवाद, मैंने इसे अपने ब्लॉग पर भी trajano.net/2013/05/05/refactoring-explained
Archimedes Trajano

0

एक तस्वीर बहुत कुछ कहती है। उदाहरण के लिए, रिफैक्टिंग के दो उपयोग मामले हैं:

  • जब चीजें पहली बार सही नहीं की जाती हैं:

जब पहली बार चीजों को सही तरीके से नहीं किया जाता है तो रिफलेक्ट करना

  • जब चीजें थकाऊ होती हैं:

जब चीजें थकाऊ होती हैं, तो पुन: सक्रिय करना

संदर्भ


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

@ बीडीएसएल कार्यस्थल
।se

0

Refactoring में दिए गए उत्तर पर विचार करें , और इसे किसी गैर-तकनीकी व्यक्ति को न समझाएं। Refactoring एक तकनीकी गतिविधि है जिसके बारे में उन्हें जानने की आवश्यकता नहीं है:

बेशक, बहुत से लोग कहते हैं कि वे गुणवत्ता से प्रेरित हैं, लेकिन अनुसूची द्वारा संचालित हैं। इन मामलों में मैं अपनी अधिक विवादास्पद सलाह देता हूं: नहीं बताएं!

विध्वंसक? मुझे ऐसा नहीं लगता। सॉफ्टवेयर डेवलपर्स पेशेवर हैं। हमारा काम प्रभावी सॉफ्टवेयर का निर्माण करना है जितनी तेजी से हम कर सकते हैं। ... एक अनुसूची-संचालित प्रबंधक चाहता है कि मैं सबसे तेज़ तरीके से चीजें कर सकूं; मैं कैसे करूँ यह मेरा व्यवसाय है। सबसे तेज़ तरीका रिफ्लेक्टर है; इसलिए मैं रिफ्लेक्टर करता हूं।

(रिफैक्टरिंग, मार्टिन फाउलर, 2000, पृष्ठ 61)

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

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