क्या आप कभी BIG Rewrite में शामिल हुए हैं? [बन्द है]

Question

जोएल स्पोल्स्की ने अपने प्रसिद्ध पदों में से एक में कहा:

सबसे खराब रणनीतिक गलती जो किसी भी सॉफ्टवेयर कंपनी कर सकती है: खरोंच से कोड को फिर से लिखना।

चाड फाउलर ने लिखा:

आपने वीडियो, वेबलॉग पोस्ट और प्रचार देखा है, और आपने निर्णय लिया है कि आप अपने उत्पाद को रेल (या जावा, या .NET, या एर्लांग, आदि) में फिर से लागू करेंगे।

खबरदार। यह आपकी अपेक्षा से अधिक लंबा, कठिन, अधिक असफल-प्रवण मार्ग है।

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

Comments

BIG के लिए आपकी क्या सीमा है ?

— रवांग

एक परियोजना जो कई वर्षों के दौरान समेकित होती है; एक परियोजना नहीं है कि एक महीने में फिर से लिखा जा सकता है।

— systempuntoout

:) वह कुछ भी हो सकता है। किसी भी अनुभव के बिना कॉलेज से बाहर ताजा कोई भी एक महीने में कई महीनों तक कर सकता है जो एक दशक या उससे अधिक कठिन अनुभव वाले किसी व्यक्ति की तुलना में काफी अलग है।

— बेरिन लोरिट्श

Mozilla ने सफलतापूर्वक CakePHP से Django में addons.mozilla.org का संक्रमण किया। इस बड़े पुनर्लेखन का वर्णन करने वाली एक बात है ( DjangoCon 2010, addons.mozilla.org को CakePHP से Django में स्विच करना ), लेकिन TL: DR संस्करण यह है कि उन्होंने एक समय में एक URL स्विच किया।

— user16764

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

— EB

Answer 1

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

• आवश्यक प्रयास के लिए कम मूल्यवान: हर बार जब कोई व्यक्ति फिर से लिखना चाहता है, तो ऐसा इसलिए है क्योंकि पुरानी प्रणाली पुरानी तकनीक का उपयोग कर रही है और बनाए रखना मुश्किल है। वे जो विचार करने में विफल रहते हैं, वह यह है कि इसकी आयु के कारण, इसमें 30-40 वर्ष के विकास के प्रयास हो सकते हैं। यह सोचकर कि आप 5 महीने में 5 साल की टीम के साथ पूरी बात फिर से लिख सकते हैं।
• खोया हुआ ज्ञान: पुरानी प्रणाली इतने लंबे समय से चली आ रही है, यह बहुत सारा सामान बनाती है, और हर चीज में शामिल है। कोई अप-टू-डेट दस्तावेज़ नहीं है, और कोई भी अधिकार प्राधिकरण नहीं है जो वास्तव में उन सभी चीजों को जानता है जो सिस्टम करता है। विशेष विभागों में विशेष उपयोगकर्ताओं के साथ ज्ञान के टुकड़े होंगे, और उन सभी को ढूंढना मुश्किल या असंभव है।
• खराब प्रबंधन के फैसले: जिन राइट्स को मैंने शामिल किया है, वे प्रबंधन से समान अपेक्षाएं रखते थे: नई प्रणाली को 'किया जाना चाहिए', और पुरानी प्रणाली को किसी विशेष तिथि, अवधि में बंद किया जा सकता है। कोई अन्य विकल्प स्वीकार्य नहीं था। मुझे लगता है कि उन्हें यह उनके सिर में मिलता है, क्योंकि वे इस विशाल परियोजना के लिए नए लोगों को काम पर रखने के लिए यह सारा पैसा खर्च कर रहे हैं। वास्तव में, बेहतर जोखिम शमन की रणनीति पुरानी प्रणाली के प्रमुख कार्यों को फिर से लिखना है, पहले रिलीज के लिए पुरानी प्रणाली के 50-75% से निपटने का कहना है, और फिर देखें कि यह कैसे काम करता है! ऊपर # 1 और # 2 की वजह से, यह संभवतः बहुत बेहतर काम करेगा, क्योंकि हम कुछ ऐसी विशेषताओं का पता लगाते हैं जो छूट गई थीं, और वास्तव में पुरानी प्रणाली को बंद करने की आवश्यकता है।

Answer 2

यदि आप उन्हें सही ढंग से गुंजाइश देते हैं, तो पुनर्लेखन बहुत सफल हो सकता है। मुझे नहीं पता कि ये आपके "बीआईजी" (टीएम) प्रोजेक्ट्स की सीमा को पूरा करते हैं, लेकिन मैं आपको कुछ और सफल लेखकों के बारे में बताता हूं।

प्रोजेक्ट 1

जिस कंपनी के लिए मैंने काम किया था, उसके पास एक शेल्फ स्ट्रिप प्रिंटिंग सिस्टम था, जिसका उपयोग आप उन लेबलों पर देख सकते थे, जिन्हें आप एक प्लानोग्राम कहे जाने वाले रिटेल अलमारियों पर देखते हैं । प्लानोग्राम को उद्योग मानक सॉफ्टवेयर में उत्पन्न किया गया था और हमारे उपकरण उस स्टोर को लक्ष्य स्टोर के लिए टेम्पलेट का उपयोग करके शेल्फ स्ट्रिप्स बनाने के लिए पढ़ते हैं। टेम्प्लेटिंग सॉफ़्टवेयर नेस्टेड परिमित राज्य मशीनों के साथ एक गड़बड़ी थी जो कई वर्गों और 3 DLL को फैलाती थी। जब पेग बोर्डों को करने के लिए (तब) पेटेंट लंबित दृष्टिकोण को लागू करने का समय आया, तो यह स्पष्ट था कि वर्तमान कोड का समर्थन नहीं कर सकता है जो हम करना चाहते थे।

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

प्रोजेक्ट 2

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

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

प्रोजेक्ट 3

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

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

निष्कर्ष

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

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

Answer 3

मैं कई पुनर्लेखन के साथ शामिल रहा हूं जो VB6 से .NET तक थे। 2 मामलों में पुनर्लेखन आसानी से हुआ और हम वास्तव में समय से पहले ही समाप्त हो गए। दूसरे पुनर्लेखन में अपेक्षा से अधिक समय लगा लेकिन बिना किसी प्रमुख मुद्दे के पूरा हुआ।

हमारे विशेष मामले में फिर से लिखना सबसे खराब निर्णय नहीं था जो हमारी कंपनी कर सकती थी। अंतिम परिणाम वास्तव में मूल की तुलना में बहुत अधिक स्थिर थे और हमें बहुत बेहतर जगह में डाल दिया।

Comments

जब तक आप कोड को C # या कुछ में परिवर्तित नहीं करते, मैं उस पुनर्लेखन को ... अधिक अपग्रेड की तरह नहीं कहूंगा। क्या आपने वास्तव में नए कोड पर खरोंच से शुरू किया था?

— Jay

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

— वाल्टर

वे कितने बड़े थे? मूल प्रणाली में कोड की कितनी लाइनें, कितने व्यक्ति-महीनों ने फिर से लिखा था?

— मार्कज

Answer 4

किसी मौजूदा प्रणाली का पूर्ण पुनर्लेखन करने के दौरान सबसे बड़ा जाल यह सोचना है कि "हमें यह निर्दिष्ट करने की आवश्यकता नहीं है कि नई प्रणाली को क्या करना है - यह बहुत सरल है, यह सिर्फ वही करना है जो पुरानी प्रणाली करती है!" ।

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

Comments

मैं इस पर गौर कर सकता हूं। आवश्यकताओं के इनपुट के रूप में पुरानी प्रणाली की एक कार्यशील प्रतिलिपि का उपयोग करना ठीक है। लेकिन तब ग्राहक को पुराने सिस्टम की कुछ अस्पष्ट धारणा नहीं, उस डॉक्टर पर हस्ताक्षर करना चाहिए।

— एड्रियन रत्नापाला

Answer 5

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

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

संसाधन: 3 प्राथमिक आर्किटेक्ट - प्रोग्रामर, पहचान प्रबंधन, परियोजना प्रबंधक। लगभग 20 डेवलपर्स, 10 विश्लेषक, 10 परीक्षक।

पूरा होने का समय (शुरू से अंत तक): 1.5 वर्ष

लॉन्च सफलता: निकट विफलता

दीर्घायु सफलता: भयानक

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

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

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

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

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

Answer 6

मैं अब एक विशाल कोड में शामिल हूँ ... केवल समस्या यह है कि मैं इस पर काम कर रहा हूँ! हमारे वर्तमान सॉफ़्टवेयर की रखरखाव लागत अपमानजनक है, इसमें बहुत सारे कीड़े हैं, और हमारे पास 1 एफटी कर्मचारी है जो इसे बनाए रखता है इसलिए हमने अपना निर्माण करने का फैसला किया।

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

Comments

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

— बेनालास्टर

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

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

— राहेल

लगता है कि आपके पास पहले से ही साझा करने के लिए अतिरिक्त हॉररस्टोरी हैं :)

@MarkJ दुख की बात है कि परियोजना एक साल बाद रद्द हो गई क्योंकि कंपनी इसे बनाए रखने के लिए पैसा और संसाधन खर्च नहीं करना चाहती थी। मुझे लगता है कि वे सोचते थे कि हम मजाक कर रहे थे जब हमने उन्हें बताया कि इस पर काम करने वाले एक अंशकालिक प्रोग्रामर के साथ लगभग 5 साल लगेंगे ... मैं बहुत निराश था, लेकिन मैंने बहुत कुछ सीखा और मुझे लगता है कि इसने मुझे एक बेहतर प्रोग्रामर बना दिया ।

— राचेल

Answer 7

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

यह एक आंतरिक अनुप्रयोग था - मुख्य व्यवसाय अनुप्रयोग, वास्तव में।

हमने पुरानी प्रणाली को बनाए रखा जैसा कि हमने संस्करण 2 लिखा था। यदि मैं सही ढंग से याद करता हूं, तो हमें लगभग एक वर्ष (दो प्रोग्रामर, और फिर एक तीसरा) मिला। हमें डेटाबेस को छूने की जरूरत नहीं थी, लेकिन कम से कम डेटा माइग्रेशन कोई समस्या नहीं थी।

Comments

साझा करने के लिए ध्यान रखें कि पुराने संस्करण को मापना बहुत बुरा क्यों था? क्या आपने प्लेटफ़ॉर्म बदल दिया?

हमने डेटाबेस (SQL कहीं भी 6 से MS SQL सर्वर 7) को बदल दिया, लेकिन मुख्य ड्राइवर यह था कि एप्लिकेशन को डेल्फी लिखने के लिए सबसे खराब तरीके का उपयोग करते हुए लगभग पूरी तरह से लिखा गया था: सभी मॉडल और नियंत्रक तर्क विचारों में, 500-लाइन ट्रिपल- नेस्टेड लूप, आदि। यह एक गड़बड़ था, हम यह नहीं देख सकते थे कि इसे कैसे भी शुरू किया जाए, और हम वैसे भी डेटाबेस बदल रहे थे।

— फ्रैंक शीयर

Answer 8

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

खराब रणनीति: मैंने 4 छात्रों के एक समूह की देखरेख की:

• छात्र # 1 - उन्हें सुरक्षित बनाने के लिए डेटाबेस एक्सेस / क्वेरी को फिर से लिखना
• छात्र # 2 - सभी सीएसएस "ऊपर" चले गए
• छात्र # 3 - सभी पृष्ठों को w3c संगत बनाया
• छात्र # 4 - सभी लंबित बगों को हल किया
• स्वयं: सभी php चेतावनियों और भद्दे सामानों को हटा दिया (डुप्लिकेट कोड वगैरह)

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

अच्छी रणनीति:

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

समय लगेगा: दो महीने ( शायद कम )।

• अच्छा कोड है।
• अच्छा रखरखाव।
• उत्पादकता।
• "हम ऐसा नहीं कर सकते, वेबसाइट इस तरह के उत्पादों को संभाल नहीं सकती" जैसे कोई जवाब नहीं।

तो, मेरे अंतिम शब्द: यह सब उस सामान की जटिलता पर निर्भर करता है जिसे आपको फिर से लिखना है ।

कृपया मेरे पोस्ट को सही करने के लिए संकोच न करें, कृपया इसे उचित अंग्रेजी बनाने के लिए, बहुत-बहुत धन्यवाद

ओलिवियर पोंस

Comments

अगर इस परियोजना में 2 महीने लगे तो मैं इसे "BIG" नहीं लिखूंगा। खासकर उस पर केवल 5 लोगों की टीम के साथ।

— जोएल एथर्टन

तुम एक अर्थ में सही हो। मैंने सोचा था कि "BIG" "> 2-4 लोगों की तुलना में" पूर्ण "पुनर्लेखन के करीब था"। क्या आपको लगता है कि मेरी पोस्ट बेकार है? अगर ऐसा है तो मैं इसे हटा दूंगा। धन्यवाद।

— ओलिवियर पोंस

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

— जोएल एथर्टन

@Joel: ठीक है, मैंने आपका उत्तर पढ़ा है, यह बिल्कुल भी "समस्या" नहीं है। एक बार फिर यह सब मामले पर निर्भर करता है। वैसे मैंने कुछ साल पहले फ्रेंच में पूरे जोएल के लेख (मेरे निजी ब्लॉग पर) का अनुवाद किया है;)

— ओलिवियर पोन्स

@OlivierPons मुझे यकीन नहीं है कि आप वास्तव में जो आप सोचते हैं कि आप जो कर सकते थे उसके खिलाफ तुलना करना एक उचित तुलना है ...

— vaughandroid

Answer 9

मैंने जिस कंपनी के लिए काम किया, उसने कोडबेस का एक प्रमुख रिफ्लेक्टर शुरू किया।

आधी टीम रिफ्लेक्टर पर काम करने के लिए तैयार थी, और दूसरी आधी मौजूदा उत्पाद को बनाए रखने और सुधारने के लिए जारी थी।

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

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

लेकिन यह कंपनी के पतन के कारण समाप्त हो गया।

Answer 10

मैं पिछले 3 वर्षों से एक बड़े पुनर्लेखन पर हूँ। मूल हमने परियोजना को 2 साल लगने का अनुमान लगाया है। मूल विचार हार्डवेयर को प्रतिस्थापित करना था, एक मौजूदा ओएस का उपयोग करना, व्यापार तर्क को फिर से लिखना (सी से सीपीपी तक), एक नया आईओ कार्ड बनाना और एक नया यूआई लिखना।

जिस तरह से हमने कुछ भयानक निर्णय लिए। हमें सीपीपी में कोई वास्तविक अनुभव नहीं था और इसे अच्छी तरह से पढ़ाने के लिए कोई संरक्षक नहीं था। हमने win32 के आधार पर एक यूआई फ्रेमवर्क बनाने की कोशिश की। हार्डवेयर सस्ता था और बीएसपी बग के साथ त्रुटिपूर्ण था। सॉफ्टवेयर सुपर लचीला था, लेकिन बनाए रखना मुश्किल था। पिछले साल हमने घर में बड़े हुए UI को फेंक दिया और एक .net में UI विकसित किया। हमने अपने दृढ़ता तंत्र और डेटा संचार प्रोटोकॉल को पूरी तरह से फिर से लिखा है।

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

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

Answer 11

दरअसल मैं एक बड़ी रिफैक्टिंग शुरू कर रहा हूं। 4MLocs शायद 800KLocs या उससे कम हो। इस परियोजना में बहुत सारी कॉपी और पेस्ट, गलतफहमी की भाषा की विशेषताएं, बहुत सारी और बहुत सी दोहराई जाने वाली बेकार टिप्पणियां, खराब फैसले, अस्थायी हैकिंग और अधिक हैकिंग स्थायी (वर्कअराउंड सहित) कंप्यूटर विज्ञान या सॉफ्टवेयर इंजीनियरिंग पर बुनियादी सिद्धांतों पर ज्ञान की पूरी कमी है । संभवतः 32 खराब प्रोग्रामर की रखरखाव टीम को रीफैक्टरिंग के बाद 2 अच्छे लोगों द्वारा प्रतिस्थापित किया जाएगा।

Comments

इस पर जो हुआ, उसे सुनकर मैं उत्सुक हूं। क्या यह सफल हुआ? रास्ते में आपने क्या सीखा? या अभी चीजें कहां हैं, अगर यह अधूरा है?

— किमबॉल रॉबिन्सन

Answer 12

मैंने 3 सप्ताह में एक ब्लॉगिंग इंजन लिखा। मैंने इसे 8 घंटे में फिर से लिखा।

आगे की योजना बनाना एक सफल पुनर्लेखन की कुंजी है। इसके अंदर और बाहर की प्रणाली को जानने से भी लाभ होता है।

Comments

क्या आप 3 सप्ताह की परियोजना को एक बड़ी परियोजना मानेंगे?

— जॉन मैकइंटायर

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

— जोश के

मौजूदा संस्करण के साथ (स्रोत कोड के साथ या बिना, लेकिन एक जिसे आप स्वतंत्र रूप से टिंकर कर सकते हैं) निश्चित रूप से पुनर्लेखन के प्रयास में मदद करता है। और अधिक बेहतर है।

— रवांग

सटीक होने के लिए, आपने 3 सप्ताह में एक प्रोटोटाइप ब्लॉगिंग इंजन लागू किया ।

@ थोरब: यकीन है, मुझे लगता है कि कहा जा सकता है।

— जोश के

Answer 13

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