Naprawianie błędu pisowni w nazwie metody

73

Jedną z metod, których zwykle używam w naszej bazie kodu, jest niepoprawna (i poprzedza mnie).

To naprawdę irytuje mnie nie tylko dlatego, że jest źle napisane, ale, co ważniejsze, sprawia, że ZAWSZE mylę nazwę przy pierwszym wpisywaniu (a potem muszę pamiętać: „Och, racja, należy ją źle odczytać ...”)

Wprowadzam kilka zmian w stosunku do oryginalnej metody. Czy powinienem skorzystać z okazji, aby po prostu zmienić nazwę tej dziwacznej metody?

refactoring

— Raz Dwa Trzy
źródło

12

Czy możesz to zmienić? Jeśli jest używany przez kod, którego nie kontrolujesz, musisz uzasadnić przerwanie zgodności z poprzednimi wersjami.

16

* błędnie napisane. I będziesz musiał to zmienić wszędzie tam, gdzie wywoływana jest metoda.

— JohnP,

2

* błędnie napisane ... a może inna pisownia?

— HorusKol,

2

@JohnP Były trzy, teraz jedna jest naprawiona, a dwie nadal są niepoprawne. Przypadkowo całkiem ładnie pasuje do nazwy OP. :)

— Rozczarowany

3

Musimy dopuścić, aby nic nie zostało niepoprawnie zapisane!

— Mag

136

Czy powinienem skorzystać z okazji, aby po prostu zmienić nazwę tej dziwacznej metody?

Absolutnie.

To powiedziawszy, jeśli twój kod został wydany jako API, powinieneś również ogólnie zostawić niepoprawną metodę i przekazać ją do poprawnie nazwanej metody (oznaczenie jako Nieaktualne, jeśli Twój język obsługuje takie rzeczy).

— Telastyn
źródło

33

Pomysł „przejdź do poprawnie nazwanej metody” jest prosty i genialny. Interesujący link również do teorii zepsutych okien.

— dev_feed

2

Pamiętaj, że jeśli jest to część publicznego interfejsu API, może to nie być zmiana zgodna wstecz (w zależności od języka). Nie jest to tak mało prawdopodobne, jak mogłoby się to wydawać. Gdybym musiał odziedziczyć istniejący interfejs API z błędnie napisaną nazwą, zdecydowanie to naprawiłbym.

— Voo

10

@voo - co? W jakim języku dodanie nowej metody (i zmiana jej implementacji w celu wykonania dokładnie tego samego zachowania) byłoby niezgodne z poprzednimi wersjami?

— Telastyn

3

@Telastyn czasami może być trudne dodanie metod określania usług internetowych. Niektórzy klienci nie chcą na przykład zmieniać WSDL, nagle odmawiają rozmowy z serwerem. Jest to problem z implementacją w kliencie, ale jeśli klient jest ważny, nie chcesz go denerwować, może bardzo dobrze zapobiec zmianie interfejsu.

— jwenting

17

@Telastyn Jeśli nazwa metody z błędem pisowni znajduje się na interfejsie (jak w typie interfejsu używanym w Delphi / Java / C #), wówczas dodanie poprawnej pisowni wersji nazwy prawdopodobnie zepsuje wszystkie istniejące implementacje tego interfejsu.

— Rozczarowany

52

Są przypadki, w których należy unikać takich refaktoryzacji:

Jeśli metoda jest używana w interfejsie publicznym. Kanonicznym przykładem jest błędna pisownia strony odsyłającej w odsyłaczu HTTP , przy zachowaniu niepoprawnej pisowni, ponieważ zmiana pisowni miałaby teraz zbyt wiele następstw.
Jeśli podstawa kodu nie jest objęta żadnymi testami. Wszelkie refaktoryzacje należy przeprowadzać na testowanym kodzie, aby móc przeprowadzić test regresji. Refaktoryzacja bazy kodu, która nie jest testowana, jest szczególnie ryzykowna. Jeśli masz dużo czasu, zacznij od dodania testów; jeśli pracujesz pod presją czasu, podejmowanie ryzyka wprowadzenia subtelnych błędów nie jest najlepszym rozwiązaniem, jeśli chcesz wysłać na czas.
Jeśli metoda może być użyta w nietypowy sposób , co praktycznie uniemożliwia jej zastosowanie (za pomocą Ctrl + F lub zautomatyzowanego narzędzia do refaktoryzacji). Na przykład w języku C # można wywołać metodę poprzez odbicie, co powoduje, że okno dialogowe Zmień nazwę programu Visual Studio jest nieskuteczne. W JavaScript eval()trudno jest również znaleźć funkcję o nazwie inside . W PHP zmienne zmienne mogą powodować problemy.
Jeśli wielkość projektu jest ogromna, a metoda może zostać wykorzystana przez inne zespoły. Jest to podobne do pierwszego punktu, tzn. Interfejs, który udostępniasz innym zespołom, można uznać za interfejs publiczny.
Jeśli masz do czynienia z projektem krytycznym dla życia. Możliwe, że błąd ortograficzny nie jest zbyt ważny, aby uzasadnić kilka miesięcy papierkowej roboty w celu zmiany nazwy metody i upewnienia się, że nie spowoduje to, że żaden pacjent otrzyma dziesięciokrotność autoryzowanego promieniowania lub jakiegokolwiek wahadłowca, aby przeliczyć prędkość.

W każdej innej sytuacji możesz zmienić nazwę metody.

— Arseni Mourzenko
źródło

1

+1 za komentarz dotyczący Odbicia, ugryzł mnie więcej niż jeden raz.

— DaveShaw

33

Jeśli twój krytyczny dla życia projekt jest na tyle delikatny, że nawet najmniejsze refaktoryzowanie może kogoś zabić, jest na tyle delikatny, że nikt nie powinien mu ufać swoim życiem. Jak możesz mieć pewność, że twoja nowa funkcja lub usprawniony interfejs użytkownika nie wprowadzają zagrażających życiu błędów, jeśli nie możesz nawet zmienić nazwy metody?

— user2357112

2

Podobnie, jeśli jedna zmieniona nazwa metody powoduje kilka dodatkowych miesięcy papierkowej roboty (zamiast, powiedzmy, przeważnie zajmowania się papierkową robotą za wszystkie inne rzeczy, które zmieniają się w tym samym czasie), wówczas równowaga programowania do dokumentacji jest wypaczona o kilka rzędów wielkości i nie można dokonać żadnej znaczącej poprawy bez zmiany systemu.

— user2357112

8

@ user2357112: Nigdy nie mówiłem, że najmniejsze refaktoryzowanie może kogoś zabić. Nie chodzi o zabicie kogoś, ale o umożliwienie wszystkiego, co możliwe, aby zmniejszyć pozostałe 0,001% ryzyka wystąpienia błędu. Wymaga to formalnego proff. Wymaga to kilku warstw testów. To wymaga formalizmu. To zabrania „Chcę szybko zmienić nazwę tej metody, mam nadzieję, że zadziała!” zachowanie. Projekty o kluczowym znaczeniu dla życia wykorzystują techniki, które można by uznać za kompletną stratę czasu i pieniędzy na każdą aplikację biznesową. Dlatego są tak niezawodne (i drogie).

— Arseni Mourzenko

5

@ user2357112: jak zauważyła MainMa, nie chodzi tu o zwykłe aplikacje biznesowe. Chodzi o specjalny rodzaj oprogramowania, które jest szeroko testowane / weryfikowane. Co jeśli metoda zostanie wywołana gdzieś przez odbicie? Co się stanie, jeśli jakieś narzędzie do kompilacji przed / po coś z tym zrobi? Co z dokumentacją? Co z innymi zespołami, które go używają? Czy używają refleksji? Co jeśli ... Prawdziwe życie może być czasem dość skomplikowane. A czasem lepiej jest pozostawić nazwę metody nietkniętą niż sprawdzać, czy istnieją jakieś konsekwencje w sposób kuloodporny.

— dagnelies

30

Zrobiłem to kilka miesięcy temu (z różnych powodów). Kroki, które podjąłem (językiem był Perl):

Zmień nazwę metody. Alias od starej nazwy do nowej nazwy (nie powinno to łamać żadnego kodu, ponieważ metodę można wywołać dowolną nazwą).
Poinformuj pozostałych programistów o zmianie nazwy i dlaczego, mówiąc im, aby odtąd używali nowej nazwy.
Grep bazę kodu dla starej nazwy, napraw wszelkie wystąpienia.
Zaloguj wszelkie zastosowania starej nazwy (używanie starej nazwy powinno w tej chwili nadal działać). Napraw te przypadki.
Poczekaj (wykonując 4.), aż w dzienniku nie będzie już więcej wpisów.
Przełam alias. Utwórz metodę, używając starej nazwy, która zgłasza krytyczny wyjątek z komunikatem o zmianie nazwy.
Po pewnym czasie usuń metodę o starej nazwie.

Oczywiście twój przebieg będzie się różnić.

— Abigail
źródło

Jedno ulepszenie - nie polegaj na grep, aby znaleźć użytkowników o starej nazwie, zaloguj się również w forwarderze.

— Ben Voigt

@BenVoigt Czy to nie to, co robi nr 4?

— Bob

6

Dobrym sposobem na nie zerwanie żadnego istniejącego kodu byłoby połączenie nowej nazwy metody ze starą w takiej jak

private void MyNewMethodName()
{
    TheOldMethodName();
}

a następnie oznacz starą metodę jako przestarzałą (jeśli Twój język to obsługuje). W ten sposób każdy istniejący kod będzie nadal działał i będziesz mógł stopniowo usuwać wszystkie stare błędy pisowni ze swojej bazy kodu. W końcu możesz nawet skopiować / wkleić treść metody do nowej metody i usunąć starą.

/ Edycja ivo Jak powiedział w komentarzu: Jeszcze lepszym rozwiązaniem byłoby przenieść kod z TheOldMethodNameInto the MyNewMethodNamei wywołać nową metodę od starej. Ten miałby również tę zaletę, że pomógłby deweloperowi dowiedzieć się, gdzie należy kod.

— Rémi
źródło

2

Zgadzam się z twoją metodą; Zrobiłbym to samo. To najbardziej rozsądna, przejrzysta i bezpieczna metoda refaktoryzacji. Dobrym sposobem może być także przeniesienie kodu ze starej metody do nowej i sprawienie, aby stary używał nowej metody. Gdy podstawa kodu znajduje się kilka iteracji w dół na osi czasu, wystarczy usunąć starą przestarzałą metodę.

— Ivo Limmen,

1

@IvoLimmen To naprawdę dobra sugestia. W ten sposób ludzie jeszcze bardziej skupią się na użyciu nowej metody, a to usunie ostrzeżenie z przestarzałego wywołania starej metody z nowej. Dodam to do mojej odpowiedzi.

— Rémi

1

Zmiana nazwy metody:

Zrób to poprzez refaktoryzację, abyś nie miał więcej pracy niż chcesz
Jeśli twoje IDE obsługuje automatyczne uzupełnianie, użyj go podczas odwoływania się do tej metody

To są dwie opcje, na które możesz pójść. Wolę automatyczne uzupełnianie (np. Eclipse IDE) i nie muszę wpisywać nazwy metody. Zmieniam nazwę; po prostu upewnij się, że dowiesz się, jakie wywołuje tę metodę i zmienisz bezpośrednie odniesienia w każdym miejscu. Refaktoryzacja będzie twoim przyjacielem, ale bądź ostrożny, robiąc to.

— Bzdurny
źródło

0

Ogólnie polecam tak, zmień nazwę.

Inne odpowiedzi tutaj wymieniają dobre powody, dla których możesz nie chcieć zmienić jego nazwy, więc jeśli znajdziesz się w takiej sytuacji, możesz utworzyć nową metodę o właściwej nazwie i implementacji oraz zmienić starą metodę, aby wywołać nową metodę . Następnie zaznacz stary jako przestarzały, jeśli Twój język go obsługuje.

— Brian
źródło