Pisaliśmy kilka funkcjonalności, korzystając z dwóch serwisów, napisanych przez inny zespół. Do obu serwisów dostaliśmy api, które było w miarę dobrze udokumentowane. Napisaliśmy cały kod używając api, po czym okazało się, że do tych serwisów istnieje biblioteka/klient, który zawiera modele + metody wywołujące endpointy.
Dla wszystkich w zespole było to takie oczywiste, że teraz trzeba to wszystko przepisać na tego klienta, co dla mnie jest niezrozumiałe, bo wydaje się być to stratą czasu. Do tego już od początku okazało się, że modele są z dupy, zjadane są błędy, więc nie wiadomo do końca co się wywala. Dodatkowo używając endpointów mogliśmy o wiele więcej, a ten klient mocno wycina różne rzeczy, a wielu endpointów po prostu brakuje i trzeba teraz zmieniać sporo rzeczy, robić coś naokoło. Taki przykład api pozwala szukać użytkownika po emailu, username lub id, a klient tylko po username.
-
Takim największym argumentem było to, że nie trzeba tego pisać, ale mieliśmy już wszystko napisane.
-
Drugim argumentem było, że jeżeli coś zmieni się w api, to nie trzeba będzie zmieniać nic u nas, bo wystarczy podnieść wersję klienta. Tylko, że jak zmieni się klient, to może być tak, że i tak będziemy musieli coś zmienić. A druga rzecz, że jeżeli już teraz jest rozjazd pomiędzy tym klientem, a api, to może w ogóle nikt zmian nie zaktualizuje i będziemy musieli my tą bibliotekę aktualizować, albo część rzeczy przepisywać na wywołania api.
- Trzecim argumentem było to, że jak jest napisane, to na pewno jest dobrze i my nie mamy odpowiedzialności za to na sobie, tylko co można źle napisać wywołując webClient.post().uri(api/x) vs uglyService.Createuser(xxx) - jest to dokładnie to samo, tylko opakowane, a całą logikę wciąż mamy u siebie...
@HmmJakiWybracNick imho jeżeli ktoś dostarcza bibliotekę do obsługi api to warto z tego skorzystać, ale skoro już wszystko zaimplementowaliście, to bym nie ruszał. Wszystko oczywiście też zależy od tego, czy to jakiś kod stabilny, czy dynamicznie się zmienia, bo jeżeli to drugie, to przepisanie już teraz ma sens.
Problemem jest też to, że jeżeli nie przepiszecie tego na tego oficjalnego klienta teraz, to jeżeli będziecie mieli dopisywać nowe ficzery, to będziecie mieli co chwilę dylemat, czy coś pisać samemu, czy korzystać z oficjalnego klienta i zrobi się miszmasz.
Także jeżeli kod jest stabilny i nie zamierzacie tam za wiele zmieniać, to bym zostawił, ale jeżeli ten moduł żyje, to przepisanie tego już teraz ma sens.
Zgadzam się w 100%. Skoro ten klient już teraz jest przestarzały to jaka jest gwarancja że kiedykolwiek będzie aktualizowany. No i skoro już macie kod działający bezpośrednio na API to po co powtarzać robotę. Ale często racjonalne argumenty nie docierają z jakiś dziwnych powodów ...
@HmmJakiWybracNick Ty masz rację, ale jeśli nie jesteś osobą decyzyjną to po prostu rób swoje i patrz jak świat płonie. Z podkładką w formie tekstowej że zwracałeś uwagę na problemy już teraz
@HmmJakiWybracNick powiedz, że skoro zaimplementowaliście to API to wypuście modele itp. jako bibliotekę i zróbcie konkurencyjną, lepszą. To twórca tamtej, użyje waszej
Zaloguj się aby komentować