बिग रिवाइट कब देना और शुरू करना है?

Question

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

हालांकि, यह ज्ञान स्वीकार किया जाता है कि कुल पुनर्लेख आमतौर पर एक बुरा विचार है। सवाल यह है कि: आप एक परियोजना को कब देखते हैं और कहते हैं: "ठीक है, यह शुरू करने का समय है।"

किस प्रकार के मीट्रिक या उदाहरण आप उद्धृत कर सकते हैं जहां एक पुनर्लेख वास्तव में आवश्यक था? कोड कितना बुरा है? बहुत अधिक निवेश किए जाने से पहले एक परियोजना कितनी पुरानी हो सकती है?

Answer 1

मैं जोएल से सहमत हूं, आपको केवल एक अंतिम अंतिम उपाय के रूप में सॉफ्टवेयर को फिर से लिखना चाहिए।

http://www.joelonsoftware.com/articles/fog0000000069.html

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

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

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

Answer 2

सॉफ़्टवेयर को फिर से लिखना न करें। अपने पूरे जीवनकाल में इसे दोबारा दोहराएं।

Answer 3

आमतौर पर, वह बिंदु तब होता है जब लागत/लाभ विश्लेषण से पता चलता है कि कुल पुन: लेखन पुराने सिस्टम को बनाए रखने से अधिक पैसे बचाने जा रहा है।

विभिन्न कारक उस विश्लेषण को प्रभावित कर सकते हैं हालांकि (प्लेटफ़ॉर्म को अब समर्थित नहीं किया जा रहा है, प्रतिभाशाली डेवलपर्स ढूंढने में कठोर हो रहे हैं आदि)।

यदि आप लागत/लाभ विश्लेषण सही तरीके से करते हैं, तो आप देखेंगे कि यह कभी भी पूर्ण पुनः लिखने के लिए भुगतान नहीं करता है। यह केवल आपको समय और सिरदर्द खर्च करेगा।

Answer 4

पुनर्लेखन केवल जब दो चीजों में से एक सत्य है:

1. मौजूदा कार्यक्रम वैसे भी काम नहीं करता है, और कहीं के पास काम कर रहे है। (दूसरे शब्दों में, आपको अपने पूर्ववर्तियों से "90% किया गया" कोड आधार मिला, वास्तविक उत्पाद नहीं।)

2. चरण-दर-चरण पुन: फैक्टरिंग असंभव है क्योंकि नए कार्यक्रम को मूलभूत रूप से अलग-अलग आर्किटेक्चर की आवश्यकता होती है, जिसे एक अलग तकनीकी ढेर या जो कुछ भी चलाने की आवश्यकता होती है।

दूसरे शब्दों में, दिशानिर्देश (वहाँ अपवाद हैं, लेकिन वे दुर्लभ हैं, आप की संभावना इस निर्देश का पालन बुरी तरह से गलत नहीं जाना होगा), पुनर्लेखन है जब कदम-दर-कदम एक से फिर से फैक्टरिंग कामकाजी उत्पाद एक विकल्प नहीं है।

Answer 5

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

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

आप यहाँ इसके बारे में पढ़ना शुरू कर सकते हैं: http://www.extremeprogramming.org/rules/iterative.html

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

Answer 6

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

उच्च अप्स का मानना ​​है कि कुछ नया & के साथ मुश्किल से काम करने में कुछ और मूल्य है, यदि यह वर्कफ़्लो & उत्पादकता में सुधार करेगा।

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

Answer 7

यदि यह पहले से ही एक आधुनिक भाषा में है, तो पुनः लिखने के बजाय रिफैक्टर।

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

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

Answer 8

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

Answer 9

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

और चोट का अपमान जोड़ना, आप आसानी से कुछ भी खराब कर सकते हैं जो आपने शुरू किया था।

Answer 10

ए "पुनः लिखना" (या कम से कम एक गंभीर रिफैक्टरिंग) कभी-कभी एक सोल्यूटन का एहसास होने पर सबसे अच्छा तरीका आगे बढ़ने योग्य नहीं है।

इसका एक उदाहरण एक चित्रकारी पैकेज है जिसे मैं 1 9 80 के दशक में लिखता हूं। यह एक 16-रंग बिटमैप पर काम करने के लिए थोड़ा मज़ा के रूप में शुरू हुआ। जब यह 20kB बेसिक कोड था, मैंने सोचा "मुझे 16 या 256 रंगीन छवियों को संभालने में सक्षम बनाने के लिए इसे फिर से लिखना चाहिए"। लेकिन यह "बहुत अधिक काम" था। जब यह 50kb था तो यह स्पष्ट था कि इसे फिर से लिखने की ज़रूरत है, लेकिन इसमें बहुत लंबा समय लगेगा। तो मैंने उस कोड को जोड़ना जारी रखा जो 16 रंग की छवि होने पर निर्भर था, जब तक यह उस बिंदु तक नहीं पहुंच गया जहां यह 140 केबी था और फिर से लिखने के लिए पूरी तरह अव्यवहारिक था। जब मैं पुनः लिखना केवल कुछ घंटों का काम करता था तो मुझे हमेशा बुलेट काटने से खेद नहीं हुआ।

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

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

इन मामलों में, तकनीकी ऋण या डिज़ाइन दोष को के रूप में यथासंभव हल करने की आवश्यकता है। एक हफ्ते के लिए अपना शेड्यूल वापस रखने के लिए इसमें कमी आती है (यदि आप एक प्रबंधक हैं) या प्रेरकता (यदि आप अंडरलिंग कर रहे हैं), लेकिन कल्पना करें कि कोई सहारा नहीं है लेकिन एक साल में फिक्स में 2 महीने समर्पित करने के लिए!

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

Answer 11

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

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

असल में, यदि आप एक मॉड्यूल भी ले सकते हैं जो किसी आवश्यकता को पूरा करने के लिए कुछ करता है, और इसे "संस्करण 2" में फिर से प्रयोग करने योग्य बनाता है, तो परिभाषा के अनुसार आपने कोड आधार नहीं निकाला है और शुरू किया है ऊपर। और यदि आप खराब कोड में भी क्यों चाहते हैं, तो आमतौर पर इसे अच्छे कोड में साफ करने के लिए केवल कुछ बदलावों की आवश्यकता होती है? परियोजना में मौजूद सभ्य या यहां तक ​​कि "अच्छे" कोड के मोती अकेले रहने दें।

Answer 12

यही कारण है कि आप इसे फिर से लिखने की योजना बना रहे हैं क्योंकि, जो मुद्दों को आप अब देख रहे हैं, उन्हें पहले लिखा नहीं गया था, इस के लिए दो कारण हो सकते हैं 1. यह ऐसा करने के लिए नहीं था अब कर रहा है या 2।यह बस एक गलती थी।

अगर आप सभी चीजों की आवश्यकता हो सकती है, तो इसे पूरी तरह से सोचने दें।

केवल तभी इसे फिर से लिखें। लेकिन आम तौर पर सबसे अच्छी तरह से लिखित और अच्छी तरह से प्रबंधित कोड केवल refactoring की आवश्यकता होगी।

चीयर्स, पवन

Answer 13

अस्वीकरण: मैं एक विश्वविद्यालय है, जहां सॉफ्टवेयर के प्रयोजन स्थापित करने या नए विचारों की वैधता का खंडन करने के लिए है पर काम करते हैं। जबकि कुछ अकादमिकों ने एक ही सॉफ्टवेयर को 20 से अधिक वर्षों तक रखा है (उदाहरण: Glasgow Haskell Compiler और ACL2 theorem prover, कई अकादमिक पुरानी परियोजनाओं को छोड़ देते हैं और समय-समय पर नई परियोजनाएं शुरू करते हैं। हम में से कई लोगों के लिए, अंगूठे का सही नियम सॉफ़्टवेयर तक है उत्पादक बनी रहती है, रिफैक्टरिंग रखने के लिए और — में सुधार से शुरू नहीं है "उत्पादक" विभिन्न संदर्भों में अलग अलग बातें मतलब है, लेकिन कुछ उदाहरणों में शामिल हैं:।

स्नातक छात्रों को सॉफ्टवेयर के बारे में

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

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

संक्षिप्त संस्करण यह है कि एक पूर्ण पुनर्लेख लगभग को उचित नहीं ठहराया गया है।