Kiedy zrezygnować z kompatybilności wstecznej na rzecz nowej i ulepszonej implementacji interfejsu? [Zamknięte]

Pracuję w tej samej firmie programistycznej od ponad dziesięciu lat. W rezultacie zaimplementowałem dużą bazę kodu przy użyciu różnych obiektowych języków programowania. Byłem początkującym programistą, kiedy zaczynałem karierę i nie wiedziałem wiele o dobrym interfejsie i zasadach projektowania klas. Chciałbym myśleć, że moje umiejętności projektowe poprawiły się z czasem, ale teraz mam coraz więcej trudności w ulepszaniu mojego wcześniejszego kodu z powodu problemów z kompatybilnością wsteczną. Mój kod jest używany przez wielu klientów jako część produktów sprzedawanych przez moją firmę.

Moje pytanie brzmi: kiedy należy przestać próbować zachować kompatybilność wsteczną starych interfejsów i gryźć kulę na rzecz wdrożenia zupełnie nowego projektu?

Myślę, że przychodzi moment, w którym utrzymanie wstecznej kompatybilności staje się tak dużym obciążeniem, że użyteczne zmiany w interfejsach stają się niemożliwe. Czy ktoś miał podobne obawy, kto może przekazać jakieś uwagi?

Chociaż „kiedy” jest dobrym pytaniem, myślę, że „jak” jest jeszcze bardziej odpowiednie. Dokonanie przełomowego przejścia może być trudne w taki sposób, aby użytkownicy nie byli sfrustrowani ani nieszczęśliwi. Niektóre elementy do rozważenia:

• Komunikuj się ze swoimi klientami / klientami na długo przed każdą zmianą. Wyjaśnij, dlaczego i jak to będzie realizowane. Powołanie na bezpieczeństwo, wydajność, stabilność i elastyczność na przyszłość jako uzasadnione.
• Jeśli mimo to robisz czystą przerwę, poproś o opinię.
• Jeśli są jacyś zewnętrzni programiści, upewnij się, że uwzględnisz ich wkład również w takim zakresie, w jakim ma to sens.
• Jeśli to możliwe, podaj warstwę zgodności.
• Zapewnij kompleksowy przewodnik aktualizacji.
• Uaktualnij tak łatwo i bezboleśnie, jak to możliwe. Zminimalizuj ból użytkowników, nawet jeśli oznacza to dla ciebie trochę więcej pracy.
• Jeśli pobierzesz opłatę, zaoferuj zniżkę na uaktualnienia do nowej wersji.
• Dodaj co najmniej kilka nowych i przydatnych funkcji w nowej wersji, aby zachęcić do aktualizacji. Jest to szczególnie ważne, aby aktualizacja była bardziej atrakcyjna dla menedżerów.
• Jeśli zrobisz sobie przerwę, zrób to ostatni raz, kiedy będziesz jej potrzebować. Oznacza to pewne kompleksowe planowanie z wyprzedzeniem i upewnienie się, że wszystko jest poprawnie skonfigurowane.
• Jeśli masz interfejs użytkownika, łatwo wprowadzaj zmiany w nim. Pomyśl raczej o odświeżeniu niż przeprojektowaniu. Dla użytkowników nietechnicznych drastyczne zmiany interfejsu użytkownika z jednej wersji do drugiej mogą być dużą przyczyną frustracji.
• Twoja nowa wersja powinna być zauważalnie bardziej stabilna i wydajniejsza niż stara. Nie dawaj użytkownikom powodu do odmowy aktualizacji. Nie wypuszczaj nowej wersji bez wcześniejszych obszernych testów (testy jednostkowe, integracyjne i beta).
• Utrzymuj starą wersję jednocześnie przez dłuższy czas. Jeśli zdecydujesz się go wycofać i przerwać wsparcie, powiadom co najmniej 6-12 miesięcy wcześniej, więcej, jeśli możesz.
• Czy możesz sobie pozwolić na utrzymanie dwóch wersji jednocześnie, zarówno pod względem finansowym, jak i siły roboczej? (Również z perspektywy biznesowej nie powinieneś przestać obsługiwać starej wersji, dopóki nie możesz pozwolić sobie na utratę pozostałych klientów, którzy przywiązują się do starej wersji i nie chcą aktualizować. To powinno być wtedy, gdy koszty utrzymanie go przewyższa twoje zyski.)
• Jeśli to konieczne, zobowiązaj się do wykonywania aktualizacji zabezpieczeń przez pewien czas po wycofaniu starej wersji.
• Ponownie komunikacja jest ogromna przez cały proces. W żadnym momencie nie zostawiaj użytkowników / klientów / klientów opuszczonych. Ich lojalność i pasja są podstawą Twojego biznesu. Upewnij się, że odpowiadasz na ich pytania na swoim blogu lub na forach. Czynnika społecznego nie należy lekceważyć.

Jeśli chodzi o „kiedy”, prawdopodobnie będziesz miał lepszy pomysł na aplikację niż ktokolwiek inny. Zasadniczo jednak nadszedł czas na czystą przerwę, gdy dług techniczny i architektura całkowicie hamują stabilność, zapobiegają rozsądnej wydajności i utrudniają opracowywanie nowych funkcji lub są niepotrzebnie trudne.

To powiedziawszy, nie rób tego kroku lekko. Nawet zrobione dobrze, złamanie wstecznej kompatybilności to wielka sprawa. Powinieneś zdecydowanie rozważyć zwiększenie zasięgu testu i refaktoryzację, a jeśli to w ogóle możliwe, przed rozważeniem przerwy.

Ogólnie zgadzam się z Jamesem Andersonem. Z mojego doświadczenia wynika jednak, że istnieją dodatkowe aspekty, które mogą wymagać rozważenia i które mogą wskazywać na opcję, która rzeczywiście umożliwia ewolucję interfejsów.

Ten przykład pochodzi z jednego z zespołów, z którymi pracuję. Wysyłają produkt regularnie, co najmniej raz w miesiącu, a czasem nawet co tydzień. Klienci są zachęcani do aktualizacji, ponieważ nowe funkcje i nowe platformy są obsługiwane tylko w nowszych wersjach. Aktualizacja jest łatwa, a klienci mogą nawet pomijać wersje pomiędzy nimi. Obniżenie wersji nie jest obsługiwane. Ponadto wersje są obsługiwane tylko przez 3 lata. Po upływie tego okresu karencja wynosi jeden rok, kiedy opłaty za konserwację podwoją się.

W rezultacie zdecydowana większość - około 95% klientów - dokonuje aktualizacji regularnie, przynajmniej raz w roku. Oznacza to również, że możesz stopniowo wprowadzać nowe interfejsy.

Co powiesz na stare interfejsy? Techniką stosowaną przez ten zespół jest deklarowanie starych interfejsów jako „wycofania z eksploatacji”. Następnie jest 12-miesięczny okres, w którym nowy interfejs jest dostępny, a stary interfejs nie został jeszcze wycofany. Nowe interfejsy oferują lepsze funkcje niż stary interfejs, więc istnieją dwie zachęty: Stary interfejs wycofania z eksploatacji i nowy interfejs są znacznie lepsze.

Konkretnym starym interfejsem w tym przypadku była technologia specyficzna dla platformy, która jest stopniowo zastępowana przez interfejs usługi oparty na standardowej technologii głównego nurtu.

Oczywiście zmiana ta nie zdarza się w nocy i jej ukończenie zajmuje wiele lat. Pozwoliło to jednak zatrzymać inwestycje w starą technologię i zamiast tego zainwestować w nową technologię. Klient otrzymuje pomoc i ma ścieżkę do przodu. Większość z nich z zadowoleniem przyjmuje także przejście na nowszą technologię.

Pamiętaj jednak, że to konkretne podejście może nie działać w Twoim scenariuszu. Z pewnością działa dla zespołu, z którym pracuję.

Masz już kilka dobrych odpowiedzi, więc chciałbym dodać wskaźnik do bardzo ładnego artykułu Joela Spolsky'ego na ten temat. Omawia plany rezygnacji z kompatybilności wstecznej w IE 8, która jest zasadniczo taka sama jak twój problem:

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

Krótka odpowiedź brzmi: Nigdy!

Doświadczenie pokazuje, że rezygnacja z kompatybilności wstecznej co najmniej denerwuje klientów i użytkowników, a co gorsza, całkowicie ich traci.

Jeśli poprosisz użytkowników o przepisanie kodu, po zakończeniu zwyczajowego przeklinania ciebie i wszystkich twoich potomków, pomyślą: „Jeśli mimo to będę musiał ponownie napisać, może powinienem po prostu przełączyć się na tę ładną bibliotekę ACME, którą czytałem tyle o? ”.

Sztuką jest albo ulepszyć bieżący interfejs, aby nie naruszał kompatybilności wstecznej, albo zaoferować zupełnie nowy błyszczący i oczywiście lepszy interfejs przy zachowaniu starszego interfejsu. W pewnym momencie w nowym interfejsie pojawią się funkcje, które po prostu nie będą możliwe w starszym interfejsie, ale to tylko zachęci ludzi do poruszania się, bez wymuszania problemu.

Edytuj, aby wyjaśnić to dalej.

Jako programista myślisz -

„Poprawię ten interfejs API i sprawię, że system będzie tak dobry, jak to możliwe, a wszyscy będą mnie podziwiać”.

Pomyślą użytkownicy Twojego interfejsu API -

„A * * * e uważa, że ​​mój czas i harmonogram nie są ważne. Muszę przerwać to, co robię, i przefakturować cały mój kod tylko z tego powodu, by zaspokoić jego ego. Jeśli będę musiał refaktoryzować, to zmienię na inny interfejs API, żeby go też przykleić ”.

To naprawdę bardziej decyzja biznesowa niż techniczna. Zwykle odbywa się to jako część głównej wersji (np. Przejście od wersji 3.5 do wersji 4.0), a często obie wersje są obsługiwane równolegle przez jakiś czas. Oznacza to, że wykonasz konserwację starej wersji, ale wszystkie nowe funkcje pojawią się tylko w nowej wersji. Stara wersja jest obsługiwana, o ile firma zarabia na tym pieniądze, lub przynajmniej wystarcza na pokrycie kosztów utrzymania. Przygotuj się na przekazanie tego kierownictwu.

Byłem po stronie klienta, więc powiedziałbym, że to naprawdę zależy od tego, co planujesz zrobić z przejściem.

Obecnie aktualizujemy nasz system kont. Firma przeprowadzająca aktualizację obsługuje również poprzednią niekompatybilną wersję. Planują wziąć dane i przenieść je do nowego systemu, aby (teoretycznie) wszystkie stare dane tam były. Za konwersję danych zapłacimy kilkaset funtów. Nie ma problemu.

Porównaj z poprzednią sytuacją w innej firmie, w której pracowałem. Dostawca nie miał możliwości przejścia ze starych na nowe systemy. To stawia ich w takiej samej sytuacji, jak każdego innego dostawcy. W rzeczywistości ich sytuacja była gorsza, ponieważ wiedzieliśmy, że nie byli zaangażowani w pomoc w ulepszeniach. Nie dostali nowego kontraktu.

Wykonałeś ciężką pracę w pozyskiwaniu i utrzymywaniu klientów. Jak możesz ułatwić przejście?