कोड "विरासत" कब है? [बन्द है]


63

हमने यह सब किया है, हमने कुछ कोड (अक्सर सामान जो हमें विरासत में मिला है) को "विरासत" के रूप में लेबल किया है? लेकिन यह अभी भी उत्पादन प्रणालियों में उपयोग किया जाता है - तो क्या यह वास्तव में विरासत है? और क्या यह विरासत बनाता है? क्या हमें पूरी तरह से कामकाज कोड के इस अनुचित लेबलिंग से दूर रहना चाहिए; जहां लेबलिंग एक शुद्ध विश्वास है जो हमें नए सामान के माध्यम से धक्का देने और ऊपरी प्रबंधन को अच्छा और खुश रखने की अनुमति देता है?


उत्तरों का सारांश

उत्तरों के माध्यम से मैं चार सामान्य विषयों को देखता हूं। यहाँ मैं टूटता देख रहा हूँ:

  1. जो भी कोड दिया गया है: 6
  2. मृत प्रणाली: 2.5
  3. कोई इकाई परीक्षण: 2
  4. डेवलपर्स आसपास नहीं हैं: 1.5


1
जैसे ही इसे वितरित किया जाता है और यह काम कर रहा है, यह विरासत कोड है।
मार्टिन बेकेट

23
अगर आपने इसे नहीं लिखा तो यह विरासत कोड है ;-)
स्टीवन ए। लोव

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

3
@ StevenA.Lowe, पर्याप्त समय दिया, यह विरासत कोड है भले ही मैंने इसे लिखा था।
Kyralessa

जवाबों:


43

मैं खुद विकिपीडिया के सारांश के लिए आंशिक हूँ :

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

बहुत से अन्य लोग जो अपने उत्तर में वर्णन कर रहे हैं, वे कारण हैं कि क्यों कोड "विरासत" बन जाता है। लेकिन आवश्यक प्रश्न यह है:

लेकिन यह अभी भी उत्पादन प्रणालियों में उपयोग किया जाता है - तो क्या यह वास्तव में विरासत है? और क्या यह विरासत बनाता है?

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

कोई भी कोड या सिस्टम जिसे आप (ए) अपग्रेड / अपडेट करना चाहते हैं, लेकिन उन्नयन के बीच में अभी भी (या) नहीं कर सकते हैं, एक विरासत प्रणाली है। इसका मतलब यह नहीं है कि रिफैक्टरिंग या सामान्य कोड सफाई, इसका मतलब है कि डिजाइन में महत्वपूर्ण बदलाव, संभवतः एक नए ढांचे या यहां तक ​​कि एक नए प्लेटफॉर्म का उपयोग करना।

सिस्टम या कोड की विरासत बनने के कई कारण हो सकते हैं :

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

  • परीक्षण का अभाव। एक अन्य जवाब में एक लोकप्रिय लेखक के किसी भी कोड के विरासत के दावों के हाइपरबोलिक दावे का उल्लेख किया गया है, जो कि विरासत कोड नहीं है। यह वास्तव में एक सटीक परिभाषा नहीं है बल्कि यह है एक संभावित मूल कारण; अच्छे परीक्षणों (स्वचालित या मैनुअल) के बिना, डेवलपर्स डरपोक हो जाते हैं और बड़े बदलाव करने से डरते हैं क्योंकि वे किसी चीज़ को तोड़ने के बारे में चिंता करते हैं, इस प्रकार "सॉफ़्टवेयर रोट" को ऊपर ले जाते हैं।

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

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

कुछ भी जो कोड बेस पर अपडेट को धीमा या बंद कर देता है, वह कोड बेस विरासत बन सकता है।

अब अलग, अस्थिर-लेकिन-निहित सवाल यह है कि विरासत कोड में क्या गलत है? यह अक्सर एक शब्द के रूप में प्रयोग किया जाता है, इसलिए प्रश्न:

क्या हमें पूरी तरह से काम करने वाले कोड के इस अनुचित लेबलिंग से दूर रहना चाहिए?

और जवाब नहीं है, हम नहीं; लेबलिंग को वारंट किया गया है और यह शब्द स्वयं कार्य कोड को स्पष्ट रूप से दर्शाता है। मुद्दा यह नहीं है कि यह कार्य है, लेकिन यह कैसे कार्य कर रहा है।

कुछ मामलों में विरासत कोड के साथ कुछ भी गलत नहीं है। यह बुरा शब्द नहीं है। लिगेसी कोड / सिस्टम ईविल नहीं हैं। उन्होंने बस कुछ धूल एकत्र की है - कभी-कभी थोड़ी, कभी-कभी बहुत कुछ।

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


उस ने कहा, टैक्स ऑडिट भी पूरी तरह से ठीक स्थिति होनी चाहिए।
फ्लोरियन मार्गाइन

मैं कहता हूं: सिस्टम जो मौजूदा टेक्नोलॉजी स्टैक के साथ अब स्केलेबल नहीं हो सकता है।
रमिज़ उद्दीन

40

आमतौर पर इसका मतलब है कि यह एक भाषा में लिखा गया है, या एक ऐसी प्रणाली पर आधारित है जिसमें आप आमतौर पर नया विकास नहीं करते हैं।

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


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

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

4
@ जेरी: तो क्या यह विरासत बना दिया? विरासत "बुरा" का पर्याय नहीं है।
शैतानिकप्यूपी

1
जिस मामले में मैं सोच रहा हूँ, यह एक काफी बड़ी वितरित प्रणाली थी (BEA Tuxedo के आसपास निर्मित)। डिज़ाइन पाठ्य पुस्तक के परिदृश्यों पर आधारित लगता है जो समय / स्थानों की संख्या को अधिकतम करके सिंक्रोनाइज़ेशन के बारे में सिखाने के लिए लक्षित होते हैं। वह (प्रकार) एक पाठ्य पुस्तक के लिए समझ में आता है, लेकिन यह वास्तविक डिजाइनों के लिए भयानक है । यह काफी बड़ा था कि एक प्रतिस्थापन की वास्तुकला भी एक बहु-वर्षीय परियोजना थी। प्रतिस्थापन को बिना किसी समय के साथ चरणों में किया जाना था, क्योंकि प्रणाली व्यापार के लिए पूरी तरह से आवश्यक थी ।
जेरी कॉफ़िन

1
@ कावासा: यह मुझे प्रतीत होता है कि @ चाड का उत्तर तब लागू होगा जब / यदि नई प्रणाली किसी अन्य भाषा में हो रही है, या विभिन्न हार्डवेयर का उपयोग कर रही है, आदि। यह जावा का उपयोग करके अभी भी फिर से विकसित किया जा रहा था, अभी भी टक्सिडो का उपयोग कर रहा है, आदि। मैं इसे लागू करने के रूप में नहीं देखता हूं।
जेरी कॉफिन

28

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

  1. जोर "बल्कि" यह बताने के लिए है कि विरासत कोड का अर्थ यह भी है कि आप इसके साथ काम कर रहे हैं भले ही आप इसके बजाय नहीं। मुझे यकीन नहीं है कि जोर हालांकि पर्याप्त था। उसके कारण अलग-अलग हो सकते हैं। कुछ वास्तव में सिर्फ बहुत बड़े और बदलने के लिए जटिल हैं। अन्य अन्य प्रणालियों के लिए इंटरफेस हैं। अभी भी अन्य लोग राजनीति और व्यक्तित्व से प्रेरित हैं (उदाहरण के लिए, कोड भयानक है, लेकिन बूथ बेब अद्भुत था)।
  2. एक और बात जो मैंने पर्याप्त रूप से जोर नहीं दी है , वह यह है कि जब कोड गुणवत्ता एक कारक हो सकता है, तो यह शायद ही कभी (यदि कभी भी) एकमात्र कारक है - और अक्सर एक विशेष रूप से महत्वपूर्ण भी नहीं है।
  3. मुझे लगता है कि एकमात्र परीक्षण कारक के रूप में यूनिट परीक्षण को धक्का देने वाले लोग उस व्यक्ति की तरह हैं जो अपनी पत्नी के कान की बाली के लिए सड़क की रोशनी के नीचे देख रहा है, एक ब्लॉक दूर गिरा दिया। प्रकाश बेहतर हो सकता है, लेकिन आप अभी भी गलत जगह देख रहे हैं। कूल-एड पीने से पहले सोचें ।
  4. (ए कोरोलरी टू 3.) यह मुझे लगता है कि कुछ लोग इस बारे में अधिक बात कर रहे हैं कि वे चीजों की इच्छा कैसे करते हैं, वे वास्तव में कैसे हैं। यदि जॉन कॉनवेज का गेम ऑफ लाइफ एक ऐप्पल IIc प्लस के लिए विरासत नहीं है, तो यह इसलिए है क्योंकि यह पर्याप्त रूप से छोटा और सरल है कि जमीन से इसे फिर से लागू करना आसान है। सबसे सही इकाई परीक्षण जो कभी भी लिखा गया था, वह एकल iota नहीं बदलेगा ।

अंतिम बिंदु दो अन्य बिंदुओं को जन्म देता है जो मुझे लगता है कि अक्सर सच होते हैं।

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

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

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

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

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

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


3
देखिए, अब मुझे नहीं पता कि इसे चिन्हित करना है या नहीं, दुख की बात यह है कि यह सच है, लेकिन मुझे आश्चर्य है कि अगर यह एक ऐसा रवैया है जिससे हमें दूर रहना है ...
निम

+1। मैं उसी हद तक कुछ जवाब देने वाला था। विरासत कोई भी कोड है जो सक्रिय रूप से बनाए रखने के बजाय उपयोग किया जाता है।
डेनिस डी बर्नार्डी

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

@ जेरी, तो आप इकाई परीक्षण तो पसंद नहीं है? ;)
निम

1
@Nim: ऐसा नहीं है - मुझे लगता है कि वे उपयोगी हैं, लेकिन अब तक रामबाण जो के रूप में वे अक्सर चित्रित कर रहे हैं की कमी।
जेरी कॉफिन

17

लिगेसी कोड आमतौर पर किसी तरह अनाथ हो जाता है। मुख्य विकासकर्ता, एकमात्र व्यक्ति जो इसे समझता था, एक बस से टकरा गया, और उसके नोट्स उनकी मूल यूक्रेनी बोली में लिखे गए थे, जो अब एक मृत भाषा है। या, वैकल्पिक रूप से, Visual Basic 6.0 में लिखा गया कुछ भी ।

मैं हर समय विरासत कोड पर काम करता हूं। मैं कहूंगा कि विशेषताएं हैं:

  • इसे बड़े पैमाने पर प्रयास के बिना बढ़ाया नहीं जा सकता
  • इसे आसानी से नए हार्डवेयर में माइग्रेट नहीं किया जा सकता है
  • आसानी से प्रतिस्थापित किया जाना बहुत महत्वपूर्ण है

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


डरावना, हमारे प्रमुख डेवलपर यूक्रेनी भी है ... हाहा ... मैं आपके उत्तर के मध्य बिट से सहमत हूं, पहला बिंदु - इतना नहीं - मुझे लगता है कि यह निर्भर करता है कि आपकी देव टीम कैसे सेटअप है।
निम

1
योग्य, आप शायद एक ही पैराग्राफ में सभी (बस ड्राइवरों, यूक्रेनी भाषा, और VB6 देव) अपमान करने में कामयाब रहे हैं। लेकिन लानत है मुझे हंसी
आती है

मैं 1999 से एक समय यात्री हूं, आपका मतलब विजुअल बेसिक 6 2011 से विरासत है?
hjk

@hjk मैं कहना चाहता हूँ 2005 में सी # / asp.net के आगमन के बाद काफी कुछ भी अस्थिर जमीन पर होगा, लेकिन निश्चित रूप से Microsoft से समर्थन के अंत में एक बार 2008 में चारों ओर लुढ़का
SatanicPuppy

12

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


24
यह मुझे "चुनी हुई कार्यप्रणाली" का "विरासत" के रूप में अनुसरण नहीं करने वाली किसी भी चीज़ को परिभाषित करने के प्रयास के रूप में प्रभावित करता है। यह एक सस्ते बहस की रणनीति से अधिक या कम कुछ नहीं है, मूल रूप से सिर्फ गॉडविन का नियम लेना और भाषा को नरम करना (बमुश्किल) पाठकों को तुरंत यह पहचानने के लिए पर्याप्त है कि यह एक असमर्थित (और अक्सर अक्षम) से अधिक कुछ भी नहीं है जो हर किसी का पालन नहीं करता है। उसकी प्राथमिकताएं।
जेरी कॉफिन

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

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

6
मैं जेरी की टिप्पणियों से सहमत हूं। यूनिट परीक्षणों की अनुपस्थिति कोड की बदबू का एक गुच्छा है जो बदबू का संकेत दे सकती है (या नहीं )।
मुस्कुराते हुए

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

8

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

यह "आपके समय से पहले" है लेकिन "फिर भी आपका सिरदर्द" है


5

लिगेसी कोड वह कोड है जो केवल कोड बेस में रहता है क्योंकि बहुत सारी चीजें अन्यथा काम करना बंद कर देती हैं। दूसरे शब्दों में: यह केवल पश्चगामी संगतता होने का कारण है।

आप इसे बदल सकते हैं या यहां तक ​​कि इसे फेंक भी सकते हैं, लेकिन आप ऐसा नहीं कर सकते क्योंकि आप इस पर निर्भर सभी कोड को तोड़ देंगे (जो कोड हो सकता है जिसे आप तदनुसार अनुकूलित नहीं कर सकते)। इसलिए आपको इसे रखना होगा (और कभी-कभी इसे बनाए भी रखना चाहिए), लेकिन आप चाहते हैं कि सभी नए कोड इसके खिलाफ न लिखे जाएं।

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

एक अन्य उदाहरण उन सभी अजीब ट्रिक्स हैं जो माइक्रोसॉफ्ट उन कार्यक्रमों को चलाने के लिए करता है जो उनके ओएस के संस्करणों के लिए लिखे गए थे, जिन्हें उन्होंने पूरी तरह से हटा दिया है। इस होने का शिखर:

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


4

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

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


अतीत 1 दिन, 1 घंटा या 1 वर्ष हो सकता है। यह इसे विरासत नहीं बनाता है।
विंस पानसुओ 12

2

मेरी राय है कि जिसे विरासत कोड माना जाता है वह कई चीजों पर निर्भर है, और टैग 'विरासत' शायद संगठन-विशिष्ट है।

यदि हार्डवेयर / OS यह चलता है तो पुराने हैं और विक्रेता द्वारा बंद कर दिया गया है - हड़ताल 1।

यदि किसी कारण से इसे फिर से लिखने के बजाय, इसे ठीक करने का प्रयास करना अधिक काम आता है

  • मूल डेवलपर / एस गए हैं
  • कार्यक्रम बुरी तरह से लिखा गया है
  • यह एक नए प्लेटफॉर्म पर बेहतर किया जा सकता है, और अभी भी कंपनी के लिए इसके लायक है

ऐसा करने के लिए

  • मूल स्रोत अब उपलब्ध नहीं है और / या लापता टुकड़े हैं

प्रहार २।

एक में कई संगठनों का विलय - हड़ताल 3 - एक तरफ शायद विरासत के रूप में टैग होने वाला है।

क्या एक बेहतर, सस्ता विकल्प तीसरे पक्ष के आवेदन और / या सेवा के रूप में बेचा जाता है - हड़ताल 4।

क्या अस्पताल या स्कूल जिले जैसा कोई संगठन है, जहां दैनिक कार्यों की बात आती है, नई तकनीक पर निरंतरता को महत्व दिया जाता है? किसी व्यावसायिक / प्रतिस्पर्धी संगठन में एक ही आवेदन की तुलना में एक आवेदन पर विचार करने में अधिक समय लगेगा।

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

कभी-कभी जब प्रबंधन बदल जाता है, तो यह तरंगों में बदल सकता है, जिसमें कई ट्रिकल प्रभाव होते हैं ... नए प्रबंधन के संकेत के आधार पर, यह कई अनुप्रयोगों की विरासत को प्रस्तुत कर सकता है जो अन्यथा ठीक हो सकते हैं।

मेरा मानना ​​है कि प्रत्येक संगठन को यह निर्धारित करना होगा कि उनके लिए 'विरासत कोड' का क्या अर्थ है। मैं हर हफ्ते द संडे टाइम्स क्लासीफाइड्स के माध्यम से देखता था कि संगठनों को क्या देखना है। जो अब प्रासंगिक नहीं था (जो कि विरासत है) के लिए मेरा बैरोमीटर हुआ करता था। खैर, द संडे टाइम्स अब प्रासंगिक नहीं है :-) और हम यह सामान्य कर सकते हैं कि COBOL विरासत है, ASP क्लासिक विरासत है, आदि ... लेकिन मेरा मानना ​​है कि प्रत्येक संगठन को यह तय करना होगा कि कब किसी एप्लिकेशन को इसके लिए विरासत माना जाए।


+1, अच्छा उत्तर - org के परिप्रेक्ष्य से कुछ विरासत पर विचार करने के लिए बेहतर ...
निम

0

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

यही कारण है कि मैं माइकल फेदर की परिभाषा से भी सहमत हूं। कोड जिसमें अच्छी इकाई परीक्षण हैं उन्हें निडर होकर बदला जा सकता है।

मुझे यह भी लगता है कि विरासत कोड का कितना पुराना है, इससे कोई लेना-देना नहीं है। कोई शुरू से विरासत कोड लिख सकता है।

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