नए और बेहतर इंटरफ़ेस कार्यान्वयन के पक्ष में पिछड़े अनुकूलता को कब त्यागेंगे? [बन्द है]

Question

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

मेरा सवाल यह है: जब एक पुराने इंटरफेस के पिछड़े संगतता को बनाए रखने की कोशिश करना बंद कर देना चाहिए और एक ब्रांड के नए डिजाइन को लागू करने के पक्ष में गोली को काट देना चाहिए?

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

Comments

I think there comes a point where keeping backward compatibility becomes such a big burden that useful changes to interfaces become impossible.- और मुझे लगता है कि आप अपने खुद के सवाल का जवाब दिया ...

— yannis

(१) क्या यह कमर्शियल है? (2) क्या ग्राहक इंटरफ़ेस / कार्यान्वयन का उपयोग करने के लिए लगातार समर्थन शुल्क का भुगतान करते हैं? (एक बार भुगतान बनाम)

— rwong

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

— कावका

Answer 1

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

• किसी भी संक्रमण से पहले अपने ग्राहकों / ग्राहकों के साथ संवाद करें। इसे क्यों और कैसे लागू किया जाएगा, यह बताइए। सुरक्षा, प्रदर्शन, स्थिरता और भविष्य के लचीलेपन का हवाला देते हुए कारण सभी मान्य हैं।
• यदि आप वैसे भी एक स्वच्छ विराम बना रहे हैं, तो प्रतिक्रिया दें।
• यदि कोई भी 3 पार्टी डेवलपर हैं, तो सुनिश्चित करें कि आप उनके इनपुट के साथ-साथ इसमें बहुत कुछ शामिल करते हैं।
• यदि यह संभव है, तो एक संगतता परत प्रदान करें।
• एक व्यापक उन्नयन गाइड प्रदान करें।
• जितना हो सके अपग्रेड को आसान और दर्द रहित बनाएं। अपने उपयोगकर्ताओं के दर्द को कम करें, भले ही इसका अर्थ आपके लिए थोड़ा और काम हो।
• यदि आप शुल्क लेते हैं, तो नए संस्करण में उन्नयन के लिए छूट प्रदान करें।
• नवीनीकरण को प्रोत्साहित करने के लिए एक नए संस्करण में कम से कम कुछ नई और उपयोगी सुविधाएँ जोड़ें । यह प्रबंधकों के लिए अपग्रेड को अधिक आकर्षक बनाने में विशेष रूप से महत्वपूर्ण है।
• यदि आप एक ब्रेक बनाते हैं, तो इसे आखिरी बार बनाएं जब आपको एक की आवश्यकता हो। इसका मतलब है कि अग्रिम में कुछ व्यापक योजना और यह सुनिश्चित करना कि सब कुछ ठीक से स्थापित है।
• यदि आपके पास UI है, तो इसके परिवर्तनों पर आसानी से जाएं। रिडिजाइन के बजाय ताज़ा सोचें। गैर-तकनीकी उपयोगकर्ताओं के लिए, एक संस्करण से दूसरे संस्करण में कठोर यूआई परिवर्तन हताशा का एक बड़ा कारण हो सकता है।
• आपके नए संस्करण को पुराने की तुलना में अधिक स्थिर और प्रदर्शनकारी होना चाहिए। अपने उपयोगकर्ताओं को अपग्रेड के लिए नाराजगी का कारण न दें। व्यापक परीक्षण (इकाई, एकीकरण और बीटा परीक्षण) के बिना एक नया संस्करण जारी न करें।
• पुराने संस्करण को एक साथ विस्तारित अवधि के लिए बनाए रखें। यदि आप इसे चरणबद्ध करने और समर्थन बंद करने का निर्णय लेते हैं, तो कम से कम 6-12 महीने का नोटिस दें, यदि आप कर सकते हैं तो अधिक।
• क्या आप वित्त और जनशक्ति दोनों के संदर्भ में एक साथ दो संस्करण बनाए रख सकते हैं? (इसके अलावा, व्यावसायिक दृष्टिकोण से, आपको पुराने संस्करण के समर्थन को तब तक नहीं रोकना चाहिए जब तक कि आप शेष ग्राहकों को खोने का जोखिम नहीं उठा सकते हैं जो पुराने संस्करण से चिपके हुए हैं और अपग्रेड नहीं करना चाहते हैं। यह बिंदु तब होना चाहिए जब आपकी लागत हो। इसे बनाए रखने से आपका मुनाफा इससे कम होगा।)
• यदि आवश्यक हो तो पुराने संस्करण को बंद करने के बाद कुछ समय के लिए सुरक्षा अद्यतन करने के लिए प्रतिबद्ध हैं।
• फिर, पूरी प्रक्रिया में संचार बहुत बड़ा है। किसी भी बिंदु पर अपने उपयोगकर्ताओं / ग्राहकों / ग्राहकों को छोड़ दिया महसूस न करें। उनकी वफादारी और जुनून आपके व्यवसाय की नींव है। सुनिश्चित करें कि आप उनके सवालों का जवाब अपने ब्लॉग पर या अपने मंचों पर दें। सामाजिक कारक को कम करके नहीं आंका जाना चाहिए।

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

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

Comments

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

— एस.लॉट

Answer 2

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

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

परिणामस्वरूप विशाल बहुमत - लगभग 95% ग्राहक - नियमित रूप से वर्ष में कम से कम एक बार उन्नयन कर रहे हैं। इसका मतलब यह भी है कि आप धीरे-धीरे नए इंटरफेस पेश कर सकते हैं।

पुराने इंटरफेस के बारे में कैसे? इस टीम द्वारा उपयोग की जाने वाली तकनीक पुराने इंटरफेस को 'एंड-ऑफ-लाइफ' घोषित कर रही है। फिर एक 12 महीने की अवधि होती है जिसमें नया इंटरफ़ेस उपलब्ध होता है और पुराना इंटरफ़ेस अभी तक सेवानिवृत्त नहीं हुआ है। नए इंटरफेस पुराने इंटरफ़ेस की तुलना में बेहतर सुविधाएँ प्रदान करते हैं इसलिए दो प्रोत्साहन हैं: पुराना इंटरफ़ेस एंड-ऑफ़-लाइफ और नया इंटरफ़ेस बहुत बेहतर है।

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

बेशक यह बदलाव रात में नहीं होता है और पूरा होने तक कई साल लग जाते हैं। लेकिन इसने पुरानी तकनीक में निवेश को रोकने और इसके बजाय नई तकनीक में निवेश करने की अनुमति दी। ग्राहक को सहायता दी जाती है और उसके पास एक रास्ता होता है। उनमें से ज्यादातर नई तकनीक की ओर कदम बढ़ाने का स्वागत कर रहे हैं।

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

Answer 3

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

http://www.joelonsoftware.com/items/2008/03/17.html

Answer 4

संक्षिप्त उत्तर कभी नहीं है!

अनुभव से पता चलता है कि ग्राहकों और उपयोगकर्ताओं को कम से कम annoys पर पिछड़े संगतता को छोड़ने, और, उन्हें पूरी तरह से खो देता है।

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

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

इसे और स्पष्ट करने के लिए संपादित करें।

एक प्रोग्रामर के रूप में आप क्या सोचते हैं -

"मैं इस एपीआई में सुधार करूंगा और सिस्टम को यथासंभव बेहतर बनाऊंगा और हर कोई मेरी प्रशंसा करेगा"।

आपके API के उपयोगकर्ता क्या सोचेंगे -

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

Comments

जोड़ा "सोचता है" जोर देने के लिए कैसे गुस्सा मजबूर परिवर्तन लोगों को बना सकते हैं!

— जेम्स एंडरसन

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

— S.Lott

@ S.Lott तरह अनावश्यक रूप से मजबूत शब्द का प्रयोग कभी नहीं जब आप वास्तव में मतलब शायद ही कभी एक ठेठ योएल Spolsky प्रभाव :) है

— maple_shaft

@ S.Lott: क्या हम उसी Microsoft के बारे में बात कर रहे हैं? Microsoft जिसका हालिया OS अभी भी अपने पहले वाले के लिए लिखे गए अधिकांश प्रोग्राम चला सकता है? Microsoft ने एक नए OS में कोड जोड़ा है ताकि यह सुनिश्चित हो सके कि पुराने में अनिर्दिष्ट व्यवहार पर निर्भर एक लोकप्रिय गेम अभी भी काम करेगा?

— माइकल बॉर्गवर्ड

-1: कुछ ग्राहक मूल्य से अधिक महंगे हैं।

— जिम जी। 15

Answer 5

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

Answer 6

मैं इस एक के ग्राहक पक्ष पर रहा हूं इसलिए मैं कहूंगा कि यह वास्तव में इस बात पर निर्भर करता है कि आप संक्रमण के बारे में क्या योजना बनाते हैं।

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

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

आपने ग्राहकों को प्राप्त करने और रखने में कड़ी मेहनत की है, आप संक्रमण को कैसे कम कर सकते हैं?