2008-09-16 18 views
18

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

हमें लगता है कि हम चार विकल्प हैं:

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

आप हमारे लिए सबसे अच्छा विकल्प क्या मानते हैं, और क्यों?

उत्तर

2

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

जहां मैं अभी काम करता हूं, हम वास्तव में प्रतिस्थापन .NET अनुप्रयोग बनाते समय एक पुराने सीएफ आवेदन को बनाए रखते हैं। क्या आप कल्पना कर सकते हैं कि नेट एप्लिकेशन को पूरा करने के बाद .NET लोगों को लिखना होगा? यही कारण है कि मैं विकास को ठंडा करने की सलाह देता हूं।

+0

मैं वास्तव में एक ही नाव में हूं। बस एक नई नौकरी शुरू की, और मेरी आने वाली परियोजनाओं में से कुछ पुराने सीएफ वेब ऐप्स के पुनर्लेखन हैं। कुछ हद तक क्योंकि नेटवर्क लोग पुराने सर्वर को बनाए रखना नहीं चाहते हैं जो कोल्डफ्यूजन चालू है। – Dana

6

पूर्ण पुनर्लेखन का प्रयास करने से सावधान रहें। कई सॉफ्टवेयर कंपनियों के लिए इस बारे में बहुत सारे उदाहरण हैं। नेटस्केप prime example

+2

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

+0

@Outlaw प्रोग्रामर इस एप्लिकेशन को पूरी तरह से फिर से लिखना क्यों होगा? वास्तव में जब – Amok

+1

! कोई cobol प्रोग्रामर –

5

विकल्प # 2 और # 3 आपके सर्वोत्तम विकल्प हैं। यदि आपका COBOL एप्लिकेशन एसक्यूएल डीबी या किसी अन्य सायन प्रारूप में इसका डेटा संग्रहीत करता है जिसे आप आसानी से आधुनिक भाषा से आसानी से एक्सेस कर सकते हैं जो सबसे सस्ता/आसान समाधान है।

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

लंबे समय तक कोबोल को बनाए रखना, केवल कठिन हो रहा है। जितना अधिक आप इंतजार करेंगे, उतना कठिन होगा।

2

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

यदि एप्लिकेशन बहुत कसकर बुना हुआ है तो ऐसा लगता है कि आपको अलग-अलग सेवाओं को खींचने में मदद के लिए कुछ कोबोल स्क्रिप्टर्स किराए पर लेने की आवश्यकता है, ताकि आप तैयार होने पर उन्हें हटा सकें।

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

9

स्वीकार्य रूप से, समस्या में कोबोल शामिल है जो आपकी आवश्यकताओं के लिए कोई जवाब देता है, अगर आपने कहा "हमारे पास पुराना वीबी ऐप" या पुराना सी ऐप है, तो विकल्प # 3 हमेशा जाने का सही तरीका है।

मैंने 3 कंपनियों पर काम किया है जिन्होंने विकल्प # 2 के लिए जाने का फैसला किया है। 2 नए सिस्टम के लिए भुगतान करने की कोशिश कर रहा था, जबकि केवल पुराने से राजस्व प्राप्त करने के लिए, तीसरा वास्तव में बहुत करीब आया था।

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

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

+2

छोड़ दिया व्यापार अनुप्रयोगों के साथ मुझे विश्वास है कि धीरे-धीरे माइग्रेट करना सबसे अच्छा है, नई सामग्री पहले। मैं एक बिगबैंग प्रतिस्थापन के माध्यम से चला गया जो एक प्रभावशाली विफलता थी। मेरे पिता, एक डेवलपर भी, 2 की सहायता की है। समस्या यह है: पुराने कोड * कभी * डॉक्टर के रूप में बिल्कुल व्यवहार नहीं करता है। कहते हैं, और COBOL-isms अचूक हैं। –

+2

"पुराना कोड बिल्कुल डॉक्टर के रूप में बिल्कुल व्यवहार नहीं करता है": यही है, मानते हैं * * दस्तावेज़ हैं ... – sleske

6

80/20 नियम का पालन करें। क्लाइंट के साथ बैठें और ऐप के 20% के लिए चश्मा लिखें जो 80% उपयोग प्राप्त करता है। एक आधुनिक प्रणाली में लिखें। फिर या तो पुराने सिस्टम को विशेष मामलों की घटती संख्या के लिए रखें या इसे एक नई प्रणाली के रूप में बाहर निकालें।

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

सिस्टम को बेहतर बनाने के लिए समय और प्रयास का उपयोग करें, न केवल पोर्ट करें। सबसे महत्वपूर्ण भागों को पोर्ट करने के बाद, विशेष मामलों पर फिर से विचार करने के लिए समय का उपयोग करें।

2

एक अन्य समाधान हो सकता है:

अपनी पसंद का एक आधुनिक भाषा के लिए कोड का अनुवाद करें।

जिनका अनुवाद नहीं किया जा सकता है लेगेसी एप्लिकेशन की
  • पुनर्लेखन भागों:

    आमतौर पर, कि कई बड़ा हिस्सा शामिल होगा। कम से कम, संरचित प्रोग्रामिंग का उपयोग हर जगह बनाते हैं।

  • internal DSL लागू करें जो नई भाषा में पुरानी भाषा से संरचनाओं को मानचित्र बनाना आसान बनाता है।
  • कोड के 90% के लिए एक फेंकने वाले स्रोत-कोड अनुवादक को लागू करें।
  • शेष 10% मुश्किल कोड का हाथ से अनुवाद करें।
  • संकलन करने के लिए धुन की चीज़ प्राप्त करने में बहुत समय व्यतीत करें।
  • कुछ गंभीर परीक्षण और फिक्सिंग के माध्यम से पूरी चीज प्राप्त करें।
  • इसे परिणामी जानवर को धीरे-धीरे साफ करने के लिए साफ करें।

इस दृष्टिकोण का मुख्य लाभ यह है कि यह सब बुरा व्यापार कोने मामलों कोड बेस में पिछले कुछ वर्षों में इनकोडिंग कर दिया है की रक्षा करेंगे। से-स्क्रैच रीराइट्स के साथ बड़ी समस्या यह है कि वे इस संचित ज्ञान को छोड़ देते हैं।

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

टिप्पणी

नहीं यह एक अनुवादक है कि कोड है कि कुछ हद तक पठनीय और पोषणीय है में अनुवाद लिखने के लिए बहुत मुश्किल हो जाएगा? हमारी समस्या यह है कि COBOL ऐप एक रखरखाव दुःस्वप्न है। हम नहीं चाहते हैं कि यह एक और भाषा में एक ही दुःस्वप्न बन जाए।

मैं यह नहीं बता सकता कि यह कितना मुश्किल होगा। यदि आप जिस कोड से शुरू कर रहे हैं वह नियमित है। लेकिन किसी भी मामले में आप "LANBOL में लिखित COBOL" के साथ समाप्त हो जाएंगे। रखरखाव दुःस्वप्न तय होने तक यह वृद्धिशील पुनर्लेखन का एक प्रारंभिक बिंदु है।

यह "स्क्रैच से पुनर्लेखन" और "कोबोल में बनाए रखने" का एक विकल्प है। यह हो सकता है कि कोड बेस में संचित ज्ञान का मूल्य वृद्धिशील सफाई की अपेक्षित लागत से कम हो।

+0

क्या अनुवादक लिखना बहुत कठिन नहीं होगा जो कुछ हद तक पठनीय और रखरखाव योग्य कोड में अनुवाद करता है? हमारी समस्या यह है कि COBOL ऐप एक रखरखाव दुःस्वप्न है। हम नहीं चाहते हैं कि यह एक और भाषा में एक ही दुःस्वप्न बन जाए। –

+0

हम सीओबीओएल को सी # अनुवाद करने में व्यस्त हैं - सुनिश्चित करें कि आप इसके लिए सही लोगों के साथ साझेदार हैं; [महान प्रवास] [https://www.greatmigrations.com/en/) अत्यधिक अनुशंसा की जाती है। –

4

धीरे-धीरे आवेदन को माइग्रेट करें?

क्या कोई तरीका है कि आप कोबोल में अन्य कोड इंटरफ़ेस कर सकते हैं, और धीरे-धीरे घटकों को बुलबुले के रूप में पुन: लिख सकते हैं? आप इसे कभी भी छुटकारा नहीं पा सकते हैं, लेकिन क्या इससे वाकई कोई फर्क पड़ता है?

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

यह न मानें कि एक सक्षम प्रोग्रामर आवश्यकता होने पर COBOL सीखने में सक्षम नहीं होगा- एक प्रोग्रामिंग भाषा एक जैसी है। यदि आप किसी को (कहें) सी ++ या जावा पर सक्षम व्यक्ति को किराए पर लेते हैं, तो वे कोबोल सीखने में सक्षम होंगे।

+0

ग्रेट टिप्पणी। यह बिंदु हिट करता है। – Phil

2

मैं पुराने आवेदन बनाए रखना चाहते हैं, लेकिन फिर, मैं एक cobol प्रोग्रामर हूँ ....

3

मैं पुराने कोड को बनाए रखने और इसे करने के लिए नई कार्यक्षमता जोड़ने microfocus से महान सामान में से कुछ का उपयोग कर होगा/AcuCOBOL। आप जीयूआई ऐप्स कर सकते हैं और अपने "विरासत" कोड से सीधे .NET और Java सामान को कॉल कर सकते हैं।

यदि यह आपके लिए काम कर रहा है तो बैक एंड क्यों तोड़ें? कामकाजी बैक-एंड को रखते हुए और थके हुए फ्रंट-एंड को बदलना वह समाधान है जिसे मैं जिस कंपनी के लिए काम करता हूं वह नियोजित करना शुरू कर रहा है।

तो मुझे लगता है कि मेरी पसंद विकल्प # 3 होगा, क्योंकि वहां ऐसा समाधान है।

7

यह विकल्प 3 की एक विविधता है:

Microfocus एक उपकरण जो कोबोल वेब सेवाओं के साथ बातचीत करने के लिए अनुमति देता है एंटरप्राइज सर्वर कहा जाता है प्रदान करते हैं।

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

प्रोग्राम ए के लिए, फिर आप क्लाइंट प्रॉक्सी उत्पन्न करते हैं और ए अब वेब सेवा के माध्यम से बी को कॉल कर सकता है।

बेशक, क्योंकि बी के पास अब किसी अन्य प्रकार की वेब सेवा है (कमांड लाइन, विंडोज़ एप्लिकेशन, जावा, एएसपी इत्यादि) अब इसे भी कॉल कर सकती है।

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

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

+0

यही वह है जो मैं सुझाव देने वाला था (अगर पोस्टर पहले से ही इसके बारे में नहीं जानता है)। प्रवासन के लिए क्लासिक "विभाजन-और-विजय" दृष्टिकोण के लिए – ConcernedOfTunbridgeWells

+0

+1। – sleske

2

कि cobol लेने के लिए और यह करने के लिए सी # की तरह परिवर्तित तृतीय पक्ष एप्लिकेशन में से एक का उपयोग कर के बारे में क्या:

http://www.softwaremining.com/index.jsp

या COBOL.net को यह पोर्टिंग, कि आसान होना चाहिए, तो सब कुछ आप जोड़ सकते हैं अन्य .NET भाषाओं में से एक में रहें।

+0

प्रोड कोड में वीबीएनईटी से सी # (मुख्य रूप से सुविधाओं में मतभेदों के कारण) में कुछ खराब अनुभव हुए हैं; एक क्रोधित वीपी के साथ मुझे याद दिलाने के लिए कि त्रुटियां कितनी मूर्ख थीं! अब, आप कोबोल को सी # में परिवर्तित कर रहे हैं। यह एए दुःस्वप्न हो सकता है जो तब होता है जब पलकें ऊपर होती हैं! – Phil

1

COBOL के बारे में सुंदर बात यह है कि कोड की शीर्ष पर डेटा आवश्यकताएं पूरी तरह से वर्तनी की जाती हैं। यह भी मदद करता है कि COBOL को (अपेक्षाकृत) सादे बिजनेस अंग्रेजी (TXTSPKers को लागू करने की आवश्यकता नहीं है) का उपयोग करके लिखे जाने के लिए डिज़ाइन किया गया था।

बेशक, यदि आपका लॉनमोवर आपके कुछ प्रोग्रामर से बड़ा है, तो उन्हें स्रोत पढ़ने के बारे में भूल जाओ। वे सिर्फ बहुत ज्यादा होगा।

3

उचित पाठ्यक्रम निर्धारित करने के लिए अपर्याप्त डेटा।

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

चीजें मौजूदा roadmaps, वितरण प्रतिबद्धताओं, सेवा अनुबंध, समय हैं- जैसे आवश्यक-लॉन्च-ऑफ-न्यू-फीचर्स, और यह निर्धारित करेगा कि आपकी स्थिति में सबसे अच्छा क्या है।

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

1

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

1

यदि आप OpenVMS का उपयोग करते हैं, तो BridgeWorks मामूली संशोधन के साथ आपके पुराने कोड का उपयोग करके वेब एप्लिकेशन बनाने में आपकी सहायता कर सकता है।

4

मैंने एक पुराने सिस्टम को माइग्रेशन किया है (हालांकि यह बहुत कम पैमाने पर था)।

क्लाइंट/सर्वर सिस्टम (एक छोटी, इनहाउस लिखित रिपोर्टिंग सिस्टम) के लिए हमने सफलतापूर्वक "क्रमिक प्रतिस्थापन" (# 2) दृष्टिकोण का उपयोग किया।हम वास्तव में, एक मोड़ के साथ यह किया एक "प्रॉक्सी" दृष्टिकोण का उपयोग करके:

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

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

मैं वास्तव में सर्वर के कमरे में गया था जब सब कुछ माइग्रेट किया गया था तो पुराने सर्वर को व्यक्तिगत रूप से बंद कर दिया गया था। वह मजेदार था :-)।

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

संबंधित मुद्दे