Ne zaman yeni ve geliştirilmiş arayüz uygulaması lehine geriye dönük uyumluluktan vazgeçilir? [kapalı]

On yıldan fazla bir süredir aynı yazılım şirketinde çalışıyorum. Sonuç olarak, çeşitli nesne yönelimli programlama dillerini kullanarak büyük bir kod tabanı uyguladık. Kariyerime ilk başladığımda yeni başlayan bir programcıydım ve iyi arayüz ve sınıf tasarım ilkeleri hakkında fazla bir şey bilmiyordum. Tasarım becerilerimin zaman içinde geliştiğini düşünmek istiyorum, ancak artık geriye dönük uyumluluk endişeleri nedeniyle önceki kodumu iyileştirmede giderek daha fazla zorluk yaşıyorum. Kodum, şirketimin sattığı ürünlerin bir parçası olarak çok sayıda müşteri tarafından kullanılıyor.

Benim sorum şu: Ne zaman eski arayüzlerin geriye dönük uyumluluğunu korumaya ve yeni bir tasarım uygulamak için mermiyi ısırmaya çalışmaktan vazgeçmeli?

Bence geriye dönük uyumluluğun o kadar büyük bir yük haline geldiği bir nokta var ki arayüzlerde faydalı değişiklikler imkansız hale geliyor. Kimse benzer endişeler yaşadı, kim geri bildirimde bulunabilir?

'Ne zaman' iyi bir soru olsa da, 'nasıl' daha da alakalı olduğunu düşünüyorum. Kullanıcıları hayal kırıklığına uğratmayacak veya mutsuz hale getirmeyecek şekilde bir geçiş yapmak zor olabilir. Dikkate alınması gereken bazı maddeler:

• Herhangi bir geçişten çok önce müşterilerinizle / müşterilerinizle iletişim kurun. Neden ve nasıl uygulanacağını açıklayın. Güvenlik, performans, kararlılık ve gelecekteki esnekliği neden olarak belirtmek geçerli.
• Yine de temiz bir mola veriyorsanız, geri bildirim isteyin.
• Herhangi bir 3. taraf geliştirici varsa, girdilerini mantıklı olduğu kadar dahil ettiğinizden emin olun.
• Mümkünse bir uyumluluk katmanı sağlayın.
• Kapsamlı bir yükseltme kılavuzu sağlayın.
• Yükseltmeyi olabildiğince kolay ve acısız hale getirin. Sizin için biraz daha fazla iş anlamına gelse bile, kullanıcılarınızın ağrısını en aza indirin.
• Ödeme alırsanız, yeni sürüme yükseltmeler için indirim yapın.
• Yükseltmeyi teşvik etmek için yeni bir sürüme en az birkaç yeni ve kullanışlı özellik ekleyin . Bu özellikle yükseltme işleminin yöneticiler için daha cazip hale getirilmesinde önemlidir.
• Bir mola verirseniz, son kez ihtiyacınız olduğunda yapın. Bu, önceden kapsamlı bir planlama yapmak ve her şeyin doğru şekilde ayarlandığından emin olmak anlamına gelir.
• Bir kullanıcı arayüzünüz varsa, üzerinde değişiklik yapmayı kolaylaştırın. Yeniden tasarlamak yerine yenilemeyi düşünün. Teknik olmayan kullanıcılar için, bir sürümden diğerine önemli UI değişiklikleri hayal kırıklığı için büyük bir neden olabilir.
• Yeni sürümünüz eskisinden çok daha kararlı ve performanslı olmalıdır. Kullanıcılarınıza yükseltmeyi yeniden göndermek için bir neden vermeyin. Önceden kapsamlı testler yapmadan yeni bir sürüm yayınlamayın (birim, entegrasyon ve beta testi).
• Eski sürümü aynı anda uzun süre koruyun. Eğer aşamalı olarak kaldırmaya ve desteği sonlandırmaya karar verirseniz, mümkünse en az 6-12 ay önceden haber verin.
• Hem mali hem de işgücü açısından iki versiyonu aynı anda koruyabilir misiniz? (Ayrıca, işletme açısından bakıldığında, eski sürüme yapışan ve yükseltmek istemeyen kalan istemcileri kaybetmeyi göze alabilene kadar eski sürümün desteğini durdurmamalısınız. bunu korumak kârınızı aşar.)
• Gerekirse eski sürüm kesildikten sonra bir süre güvenlik güncellemeleri yapmayı taahhüt edin.
• Yine, süreç boyunca iletişim çok büyüktür. Kullanıcılarınızı / müşterilerinizi / müşterilerinizi hiçbir zaman terk edilmiş hissetmeyin. Onların sadakati ve tutkusu işinizin temelidir. Sorularını blogunuzda veya forumlarınızda yanıtladığınızdan emin olun. Sosyal faktör hafife alınmamalıdır.

'Ne zaman' söz konusu olduğunda, muhtemelen başvurunuz için herkesten daha iyi bir fikriniz olacaktır. Bununla birlikte, genel olarak, teknik borcunuz ve mimariniz istikrarı tamamen engellediğinde, makul performansı önlediğinde ve yeni özelliklerin gelişimini ezici veya gereksiz yere zorlaştırdığında temiz bir mola zamanı olabilir.

Bütün bunlar, bu adımı hafife alma. Doğru yapıldığında bile, geriye dönük uyumluluğu bozmak büyük bir sorun. Bir ara vermeyi düşünmeden önce test kapsamınızı artırmayı ve mümkünse yeniden düzenleme yapmayı kuvvetle düşünmelisiniz.

Genel olarak James Anderson ile hemfikirim. Bununla birlikte, tecrübelerime göre, dikkate alınması gereken ve gerçekten de gelişen arayüzlere izin veren bir seçeneğe işaret edebilecek ek özellikler vardır.

Bu örnek birlikte çalıştığım takımlardan birinden. Bir ürünü düzenli olarak, ayda en az bir kez, hatta bazen haftada bir kez gönderiyorlar. Yeni özellikler ve yeni platformlar yalnızca yeni sürümlerde desteklendiğinden, müşteriler yeni sürüme geçmeyi teşvik eder. Yükseltme kolaydır ve müşteriler aralarındaki sürümleri bile atlayabilir. Sürüm düşürme desteklenmez. Ayrıca versiyonlar sadece 3 yıl için desteklenmektedir. Bundan sonra, bakım ücretlerinin iki katına çıktığı bir yıllık ödemesiz dönem vardır.

Sonuç olarak, büyük çoğunluk - müşterilerin yaklaşık% 95'i - yılda en az bir kez düzenli olarak iyileştirilmektedir. Bu ayrıca yavaş yavaş yeni arayüzler tanıtabileceğiniz anlamına gelir.

Eski arayüzlere ne dersiniz? Bu ekibin kullandığı teknik eski arayüzleri 'kullanım ömrü sonu' olarak ilan etmektir. Daha sonra yeni arayüzün mevcut olduğu ve eski arayüzün henüz emekli olmadığı 12 aylık bir dönem var. Yeni arayüzler eski arayüzden daha iyi özellikler sunuyor, bu yüzden iki teşvik var: Eski arayüz kullanım ömrü ve yeni arayüz çok daha iyi.

Bu durumda somut eski arayüz, yavaş yavaş standart ana akım teknolojisine dayanan bir servis arayüzü ile yerini alan bir platforma özgü teknolojiydi.

Elbette bu değişiklik gece boyunca gerçekleşmez ve tamamlanmasına kadar yıllar sürer. Ancak, eski teknolojiye yatırımın durdurulmasına ve bunun yerine yeni teknolojiye yatırım yapılmasına izin verdi. Müşteriye yardım verilir ve ileriye giden bir yol vardır. Birçoğu da yeni teknolojiye doğru ilerlemeyi memnuniyetle karşılıyor.

Bununla birlikte, bu özel yaklaşımın senaryonuzda işe yaramayabileceğini unutmayın. Kesinlikle birlikte çalıştığım ekip için işe yarıyor.

Burada zaten bazı iyi yanıtlarınız var, bu yüzden Joel Spolsky'nin bu konuyla ilgili çok güzel bir makalesine bir işaretçi eklemek istiyorum. Temel olarak probleminizle aynı olan IE 8'de geriye dönük uyumluluktan vazgeçme planlarını tartışıyor:

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

Kısa cevap Asla!

Deneyimler, geriye dönük uyumluluğun en azından müşterileri ve kullanıcıları rahatsız ettiğini ve daha da kötüsü onları tamamen kaybettiğini göstermektedir.

Kullanıcılarınızdan kodu yeniden yazmasını istiyorsanız, sizin ve tüm torunlarınızın geleneksel lanetlerini bitirdikten sonra, "Yine de yeniden yazmak zorunda kalırsam belki de okuduğum güzel ACME kütüphanesine geçmeliyim. hakkında çok şey? "

İşin püf noktası, mevcut arayüzü geriye dönük uyumluluğu bozmayacak şekilde geliştirmek veya eski arayüzü korurken tamamen yeni, parlak ve açıkça üstün bir arayüz sunmaktır. Bir noktada, yeni arayüzde eski arayüzde mümkün olmayacak özellikler olacak, ancak bu, insanlara sorunu zorlamadan hareket etmeye teşvik ediyor.

Bunu daha fazla açıklığa kavuşturmak için düzenleyin.

Bir programcı olarak ne düşünüyorsunuz -

"Bu API'yı geliştireceğim ve sistemi olabildiğince iyi hale getireceğim ve herkes bana hayran kalacak".

API'nızın kullanıcılarının ne düşüneceği -

"A * * * e zamanımı ve zamanlamamın önemli olmadığını düşünüyor. Ne yaptığımı durdurmalı ve nefsini tatmin etmekten başka bir sebep olmadan tüm kodlarımı yeniden düzenlemeliyim. sadece onu da yapıştırmak için başka bir API’ye

Bu gerçekten bir teknik karardan çok bir iş kararıdır. Genellikle bu, büyük bir sürümün bir parçası olarak yapılır (örneğin, sürüm 3.5'ten sürüm 4.0'a) ve genellikle iki sürüm bir süre paralel olarak desteklenir. Bu, eski sürümde bakım yapacağınız anlamına gelir, ancak tüm yeni özellikler yalnızca yeni sürümde görünür. Eski sürüm, şirket bundan para kazandığı sürece veya en azından bakım maliyetlerini dengeleyecek kadar desteklenir. Bunu yönetime sunmaya hazır olun.

Bunun müşteri tarafında bulundum, bu yüzden gerçekten geçiş hakkında ne yapmayı planladığınıza bağlı olduğunu söyleyebilirim.

Şu anda hesap sistemimizi yükseltiyoruz. Yükseltmeyi yapan şirket önceki uyumsuz sürümü de desteklemektedir. Verileri almayı ve yeni sisteme taşımayı planlıyorlar (teoride) tüm eski veriler orada olacak. Veri dönüştürme için birkaç yüz pound ödeyeceğiz. Sorun değil.

Çalıştığım anothe'deki önceki durumla karşılaştırın. Tedarikçinin eski sistemden yeni sistemlere geçişi yoktu. Bu onları diğer tüm tedarikçilerle aynı duruma soktu. Aslında durumları daha kötüydü, çünkü yükseltmeler konusunda bize yardımcı olmayı taahhüt etmediklerini biliyorduk. Yeni sözleşmeyi alamadılar.

Müşterileri elde etmek ve elde tutmak için çok çalıştınız, geçişi nasıl kolaylaştırabilirsiniz?