क्या सॉफ्टवेयर की सफलता / विफलता दर के पुनर्लेखन पर कोई वास्तविक केस अध्ययन है?

Question

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

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

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

क्या वास्तविक मामले के अध्ययन हैं जिन्होंने इसकी जांच की है? मैं वास्तविक अध्ययनों के आधार पर कुछ सर्वोत्तम प्रथाओं, नुकसानों और सफलताओं को जाने बिना एक प्रमुख पुनर्लेखन का प्रयास नहीं करना चाहता।

परिणाम: ठीक है, अधिक खोज के बाद, मुझे केस स्टडीज पर तीन दिलचस्प लेख मिले:

1. फिर से लिखना या उपयोग करना । उन्होंने एक कोबोल ऐप पर एक अध्ययन किया जो जावा में परिवर्तित हो गया।
2. अन्य सॉफ्टवेयर के पुन: उपयोग पर था : डेवलपर्स के अनुभव और धारणाएं ।
3. पुन: उपयोग या फिर से लिखना एक रखरखाव के खर्च पर एक अन्य अध्ययन बनाम एक फिर से लिखना।

मुझे हाल ही में इस विषय पर एक और लेख मिला: द ग्रेट रिवर्ट । वहाँ लेखक कुछ प्रमुख मुद्दों पर हिट करने के लिए लगता है। इसके साथ ही प्रस्तावित नई प्रौद्योगिकी स्टैक का उपयोग करके प्रोटोटाइप बनाने का विचार था और देवों ने इसे कितनी जल्दी उठाया था। यह सब एक फिर से लिखना के लिए एक प्रस्तावना के रूप में था, जो मुझे लगा कि एक महान विचार है!

Comments

मैं केस स्टडीज के बारे में नहीं जानता, लेकिन मुझे लगता है कि एक दृष्टिकोण के लिए मानक उत्तर शायद "यूनिट टेस्ट और रिफ्लेक्टर जोड़ें।"

— जेरी कॉफिन

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

— जेरी कॉफिन

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

— जेरी कॉफिन

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

— mike30

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

— एरिक रेपेने

Answer 1

मैं इन महान टिप्पणियों का श्रेय नहीं ले सकता, लेकिन उन्हें मूल लेखक द्वारा उत्तर में नहीं डाला गया था, इसलिए मैं इसे सामुदायिक विकि के रूप में चिह्नित कर रहा हूं।

मैं केस स्टडीज के बारे में नहीं जानता, लेकिन मुझे लगता है कि एक दृष्टिकोण के लिए मानक उत्तर शायद "यूनिट टेस्ट और रिफ्लेक्टर जोड़ें।"

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

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

मुझे लगता है कि परियोजनाओं को फिर से लिखना सामान्य रूप से परियोजनाओं की तुलना में विफलता दर में काफी भिन्न नहीं है, और सर्वोत्तम जानकारी के लिए नवीनतम CHAOS रिपोर्ट को संदर्भित करेगा।

Comments

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

— केविन

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

Answer 2

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

Answer 3

अनुभव से बोलते हुए और एक ऐसी कंपनी में रहना जिसने शुरू से ही उद्यम वास्तुकला को खराब माना है, मैं ईमानदारी से कह सकता हूं कि सबसे बड़ा मुद्दा एक व्यापक समझ विकसित कर रहा है।

यह विचार कि एक प्रणाली को टुकड़ों में तोड़ा जा सकता है और व्यक्तिगत रूप से समझा जा सकता है। किसी समय किसी एक व्यक्ति या कई व्यक्तियों को संपूर्ण समस्या के बारे में पूरी तरह से अनुमान लगाने में सक्षम होना चाहिए था। यदि यह समस्या व्यावसायिक समस्याओं और उन्हें चलाने वाली प्रौद्योगिकियों की एक श्रृंखला है; कंपनी के सभी सिस्टम को एक स्तर तक समझने में कई वर्षों तक किसी व्यक्ति को लग सकता है, जहां आपदा या चूक के बिना उन्हें प्रतिस्थापित करना संभव है। यह निश्चित रूप से मेरी कंपनी में मामला था जब मैंने प्रौद्योगिकी निदेशक के रूप में पदभार संभाला था। यदि यह इस तथ्य के लिए नहीं था कि मैं खुद एक कोडर हूं तो मैं धीरे-धीरे खराब तरीके से संगठित, कसकर युग्मित, कसकर बंधे वास्तुकला और प्रौद्योगिकी के एकीकरण के सभी विवरणों को समझने में सक्षम नहीं होगा। यदि छोटा छिपा हुआ है, तो ऐसा नहीं है"We put the eBay order number in the "SYSOENT.PO_NUMBER" field in the ERP system because that's what Wendell the VB coder from Florida decided to do" अनदेखी के परिणाम विनाशकारी हो सकते हैं, और यह जानने का एकमात्र तरीका धीरे-धीरे यह सब पता लगाना है।

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

मुझे लगता है कि मेरी प्राथमिक बात यह है कि, सिस्टम को लगभग पूरी जटिलता में समझा जाना चाहिए, और नई प्रणाली को ठीक से "इंजीनियर" और न सिर्फ "बनाया" होने के लिए इसे पूर्णता में समझा जाना चाहिए।

कुकीज़ बनाई जाती हैं, सॉफ्टवेयर (होना चाहिए) इंजीनियर।

Comments

व्यापार प्रणाली के बारे में इतना समझने की आवश्यकता के लिए +1। हालांकि, जैसा कि आप जानते हैं, यहां चुनौती समय और संसाधन (व्यवसाय से) और साथ ही परिवर्तन कारक है। मध्यम और बड़ी प्रणालियों के लिए, पूर्ण जटिलता को सामने वाले को समझना कभी-कभी संभव नहीं होता है।

— NoChance

Answer 4

कंपनियों के कई उदाहरण हैं जो एक फिर से लिखे गए, जैसे नेटस्केप । ऐसी कंपनियां भी हैं जो ट्विटर जैसी बड़ी परेशानी के बिना फिर से लिखी गईं ।

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

कुछ स्पष्ट मामले हैं जहां एक पुनर्लेखक समझ में आता है और कई मामले जहां यह नहीं होता है। यदि कोई पुनर्लेखन आपके मामले में समझ में आता है तो मैंने यह जानने के लिए एक छोटी सी रेसिपी बनाई है ।

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

Answer 5

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

आपके द्वारा पाया गया केस अध्ययन फुजित्सु द्वारा निर्मित किया गया है, और इसका परिणाम यह है कि फूजित्सु के औजारों का उपयोग करना बेहतर था।

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

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

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

Comments

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

— MarkJ

@ मर्कज: मैंने सोचा था कि "काम नहीं करता" के तहत कवर किया गया था, लेकिन मैं इसे और अधिक स्पष्ट करने के लिए संपादित करूंगा।

— जमरिनो