Wydaje się, że trwa debata nad refaktoryzacją, aby wykorzystać generyczne java w moim obecnym zespole. Mam pytanie, jakie są obecne standardy branżowe w zakresie refaktoryzacji starszego kodu Java, aby skorzystać z niektórych z tych funkcji? Oczywiście według standardów branżowych mam na myśli najlepsze praktyki. Link do książki lub strony z tymi listami zostanie nagrodzony jako odpowiedź, ponieważ jest to najmniej subiektywny sposób na obsłużenie tego pytania.Java refactor do standardów branżowych Generics
Odpowiedz
Papiery z tej grupy badawczej MIT może dostarczyć Ci kilka przydatnych wskazówek:
- Refactoring Java Applications to Use Generic Libraries
- Efficiently refactoring Java applications to use generic libraries
Robert Fuhrer, Frank Tip, Julian Dolby, Adam Kieżun i Markus Keller
ECOOP 2005 --- Programowanie obiektowe, 19. konferencja europejska (Glasgow, Szkocja), 25-29 lipca 2005 r. - Refactoring techniques for migrating applications to generic Java container classes
Frank Tip, Robert Fuhrer, Julian Dolby i Adam Kiezun
IBM T.J. Watson Research Center IBM Research Report RC 23238 (Yorktown Heights, NY, USA), 2 czerwca 2004.
- Efficiently refactoring Java applications to use generic libraries
Użycie generic java jest zdecydowanie dobrym pomysłem. Jest kompatybilny wstecz. Dlatego baza kodów, której nie możesz przekonwertować, będzie nadal działać z nowym kodem.
EDYTOWANIE: Powinienem wspomnieć o type erasure jako o powodzie, który czyni zgodność zgodną z poprzednimi.
dziękuję za pomocne informacje, jednak jest jakikolwiek zestaw standardów co do tego, co powinno być refaktoryzowane do generycznych, a nie tylko robić to dla dobra tego. – Woot4Moo
@ Woot4Moo - nie ma takich standardów. Jest to decyzja, która musi być podejmowana indywidualnie dla każdego przypadku. –
Najlepsze praktyki dotyczące przyjmowania leków generycznych? Pierwszą najlepszą praktyką jest "do". Postaraj się wyeliminować jak najwięcej rzutów z kodu. Jeśli chcesz ułatwić sobie życie, skorzystaj z refaktoryzacji IntelliJ "Generify" - po prostu wskaż ją w całym kodzie źródłowym, pozwól mu to zrobić, a następnie wykonaj trochę po oczyszczeniu.
pytanie teraz staje się to zrobić ze względu na działanie lub zrobić, ponieważ jest właściwe? – Woot4Moo
Zrób to, jeśli możesz to zrobić. Czasami pisanie ogólnych klas nie-kontenerowych może być trudne (nauka korzystania z górnych, dolnych granic i wielorakich). Najlepszą zasadą kciuka jest to, że jeśli rzucasz wartość, która pochodzi * od * ogólnego wywołania, to najprawdopodobniej twoja generacja nie jest wystarczająco dobra lub trafiłeś w jedno z tych kilku narożnych przypadków, których system typów nie może wyrazić. Posiadanie fałszywego poczucia bezpieczeństwa zapewnianego przez leki generyczne i obserwowanie awarii systemu w środowisku wykonawczym przy użyciu klasy ClassCastException może być bardzo frustrującym doświadczeniem. – ddimitrov
@ Woot4Moo - oczywiście nie powinieneś robić tego tylko ze względu na robienie tego! –
Nie sądzę, że ślepo po co ktoś uznaje za "najlepsze praktyki" lub "standard branżowy" jest zawsze dobrym pomysłem. Jesteś w najlepszej sytuacji, aby zdecydować, czy zmiana kodu jest opłacalna, czy nie.
Pytania, które należy odpowiedzieć, to jakie korzyści można uzyskać dzięki uaktualnieniu starego kodu, kosztowi i ryzyku?
Główną korzyścią jest poprawa sprawdzania typów podczas kompilacji, co powinno pomóc wykryć błędy w nowym kodzie korzystającym ze zaktualizowanego kodu. Może nawet podkreślać błędy w istniejącym kodzie. Kod, który używa generycznych, a czasami dość gadatliwy, jest zazwyczaj bardziej czytelny, ponieważ jasno określa, które typy są poprawne w jakich kontekstach. Nie będziesz już musiał tłumić/ignorować ostrzeżeń kompilatora.
Koszt to ilość czasu potrzebnego na wykonanie i przetestowanie niezbędnych zmian w celu wprowadzenia leków generycznych. Za każdym razem, gdy wprowadzasz zmiany w kodzie, istnieje szansa, że możesz wprowadzić błędy, więc to jest ryzyko. Czy korzyści przewyższają koszty? To zależy od tego, ile masz kodu, jak go używasz i jakie masz inne wymagania na swój czas.
Rzeczywiście, byłem refactoring pakiet po paczce tylko wtedy, gdy ma sens dla każdego. –
+1 dla "ulepszonego sprawdzania nowego kodu". Użyłbym generycznych tylko dla nowego kodu i zaktualizowałbym starą klasę kodu dla klasy tylko wtedy, gdy i tak muszę ją dotknąć. – Thilo
Twój zespół powinien równoważyć korzyści wynikające z refaktoryzacji na dużą skalę z kosztami i ryzykiem technicznym i biznesowym związanym z tym ... i innymi priorytetami, które ma twój zespół.
Argumenty "najlepsze praktyki" i opinie osób, które nie rozumieją twojego projektu i kontekstu biznesowego, nie mają tu zastosowania.
Najlepsze praktyki nie istnieją. To dziwne określenie, które sugeruje, że drzwi zamykają się na "bestness" danego rozwiązania ... Użyj generycznych? Tak. Natychmiast. To niezręczna podróż, ponieważ tak wiele dużych bibliotek (Hibernate, Spring) wciąż nie potrafi ich całkowicie objąć ... ale z mojego doświadczenia wynika, że radzenie sobie z mieszanką generycznych i odważnych rzutów wciąż stanowi lepszą podstawę kodu, niż nieużywanie w ogóle.
Zrobiłabym także zasadę, że nawrócę się do ciebie, a nie jakaś gigantyczna misja refaktoryzacji.
Zazwyczaj dobrym pomysłem jest refaktoryzacja w celu użycia leków generycznych.
Nie jest to wymagane, więc nie traktuj tego jako pilnego zadania, ale możesz uważać, że używanie generycznych nie jest łagodną formą długu technicznego - więc jeśli masz czas, a baza kodu ma mieć długie życie, warto zainwestować w jego modernizację.
Główne korzyści to:
- Lepsza kontrola typów w czasie kompilacji, który będzie zmniejszyć liczbę błędów
- Usuń niepotrzebnych odlewów z kodu źródłowego, co sprawia, że kod jest bardziej czytelny
- Jest jeszcze wstecz kompatybilny ze starym kodem (dzięki usunięciu typu)
Nie ma prawdziwego problemu - jedyny potencjalny problem, jaki mogę sobie wyobrazić, to to, że kiedykolwiek chciałeś przenieść kod z powrotem do wcześniejszych wersji Java bez ogólnej obsługi. Ale byłoby to bardzo nietypowe!
Jeśli zdecydujesz byłaby do generyków to polecam następujące kroki:
- Włącz wszystkie ostrzeżenia kompilatora (Eclipse ma dość dobre ostrzeżenia)
- Dodaj typ rodzajowy do klasy pierwszej na przykład
MyClass<T>
- Następnie zmień typ wszystkich sygnatur metod/pól wewnętrznych/struktur danych, aby użyć T
- Prawdopodobnie będziesz mieć wiele ostrzeżeń/błędów w całym kodzie w tym miejscu. To jest w porządku, po prostu przepracuj je i napraw je wszystkie. Często twoje IDE może być w stanie "szybko naprawić" wiele z nich.
- przypadki Zapis testów/Refactor że wykazanie ogólne cechy
Jest dość szybki, aby zrobić to wszystko - Myślę, że udało mi się byłaby około 10.000 linii kodu biblioteki Java, aby użyć rodzajowych w mniej niż jeden dzień, w tym aktualizacja kodu klienta.
Na czym dokładnie polega debata w twoim zespole? Czy przyjąć, jak się adoptować czy coś innego? –
Wydawało się, że trwa święta wojna o to, co powinno, a czego nie powinno się robić. Teraz sprowadza się do tego, że jest to warte wysiłku, z powodu potencjalnie delikatnych rzeczy. To są słowa, które usłyszałem, a nie moje. – Woot4Moo