Najlepsze praktyki dotyczące zmiany nazwy, refaktoryzacji i przełamywania zmian w zespołach

10

Jakie są najlepsze praktyki dotyczące refaktoryzacji i zmiany nazw w środowiskach zespołowych? Przytaczam to z myślą o kilku scenariuszach:

  1. Jeśli biblioteka, do której się często powołuje się, jest refaktoryzowana, wprowadza przełomową zmianę do dowolnej biblioteki lub projektu, który się do niej odwołuje. Np. Dowolna zmiana nazwy metody.

  2. W przypadku zmiany nazwy projektów i przebudowy rozwiązań przy użyciu zaktualizowanych odniesień do nich.

  3. Jeśli struktura projektu zostanie zmieniona, aby była „bardziej zorganizowana” przez wprowadzenie folderów i przeniesienie istniejących projektów lub rozwiązań do nowych lokalizacji.

Kilka dodatkowych myśli / pytań:

  1. Czy takie zmiany powinny mieć znaczenie, czy też ból może świadczyć o tym, że struktura poszła nie tak?

  2. Kto powinien wziąć odpowiedzialność za naprawę błędów związanych z przełomową zmianą? Jeśli programista dokonuje przełomowej zmiany, czy powinien być odpowiedzialny za wchodzenie w projekty, których dotyczy problem, i aktualizowanie ich, czy też powinien ostrzegać innych programistów i zachęcać ich do zmiany rzeczy?

  3. Czy jest to coś, co można zrobić zgodnie z harmonogramem, czy też należy to robić tak często, jak to możliwe? Jeśli refaktoryzacja jest odkładana na zbyt długo, coraz trudniej jest to pogodzić, ale jednocześnie w ciągu dnia spędza 1 godzinę na ustalaniu kompilacji z powodu zmian zachodzących gdzie indziej.

  4. Czy jest to formalny proces komunikacji, czy może być organiczny?

David w Dakocie
źródło
1
Obciążaj każdego 1 $ za każdym razem, gdy psują kompilację ... Byłbyś zaskoczony, jak bardzo ogranicza niedbałe błędy.
Berin Loritsch,
+1, ponieważ Twój komentarz zainspirował 3 doskonałe - i różne - odpowiedzi.
Carl Manaster,

Odpowiedzi:

13

Każdy z wymienionych scenariuszy należy do kategorii „opublikowanego interfejsu API / kodu”. Jest to trudne do refaktoryzacji, więc nie należy niczego zmieniać. Zamiast tego powinien on wcześniej negocjować planowane zmiany ze wszystkimi zaangażowanymi stronami. Jest to co najmniej tak samo kwestia polityczna, jak techniczna.

Tak więc najważniejszą radą Martina Fowlera na ten temat jest nie publikowanie przedwcześnie interfejsów (nazw i struktur projektów) .

Jeśli jednak jest to już zrobione i wymaga naprawy, prawdopodobnie lepiej jest spróbować wprowadzić niezbędne zmiany w jak najmniejszej liczbie kroków, aby zminimalizować zakłócenia innych stron. Co odbiega dość daleko od pierwotnej koncepcji refaktoryzacji, ale nie bez powodu.

Ponadto, jeśli to możliwe, rozważ dodanie nowej metody (nieaktualne już istniejącej) zamiast zmiany jej nazwy. Zapewnia to, że kod klienta się nie psuje, i zapewnia okres przejściowy na aktualizację kodu, aby był zgodny z najnowszym interfejsem API. Wadą jest to, że komplikuje interfejs API. Chociaż stan ten jest tylko tymczasowy, może upłynąć sporo czasu, zanim będzie można bezpiecznie usunąć przestarzałe metody API (w przypadku biblioteki klas Java, lata).

Péter Török
źródło
Nie możesz skorzystać z porady Martina Fowlera (poza tym dobrej), gdy refaktoryzujesz kod napisany przez innych. Przypuszczam też, że programista, który wycofał metody, powinien przypomnieć kolegom, aby od czasu do czasu korzystali z nowych metod, nie będąc zbyt irytującym, aby przyspieszyć przejście. Mam wrażenie, że przestarzałe metody w bibliotece klas Java zawsze będą istnieć dla kompatybilności wstecznej, ale mogę się mylić.
blizpasta
@blizpasta, zależy od liczby klientów, których dotyczy dany interfejs API. Jeśli masz pół tuzina, wszyscy w tym samym dziale, może zająć trochę dyskusji i argumentów, a kilka miesięcy, aby zakończyć przejście w normalnych okolicznościach. Jeśli masz miliony użytkowników i miliardy LOC kodu klienta na całym świecie, to tak, najprawdopodobniej nigdy nie usuniesz tych przestarzałych metod.
Péter Török
5

Prawie zawsze można uniknąć tych problemów, dokonując refaktoryzacji w dwóch etapach. W pierwszym kroku wprowadź nowy kod i wycofaj stary kod. Po migracji wszystkich zespołów do nowego kodu usuń stary kod. Korzystam również z tej techniki, aby stopniowo refaktoryzować pojedynczy moduł. W ten sposób mogę ograniczyć ilość kodu, który należy zmienić między uruchomieniami testowymi.

Kevin Cline
źródło
2
Kiedy to zrobiłem, często byłem w stanie zmienić stary kod, aby wywołać nowy kod. Dzięki temu może stać się metodą pośredniczącą i zapewnia (miejmy nadzieję) ulepszony kod dla klientów starej metody.
BillThor
4

Zauważ, że jest to jeden z głównych powodów posiadania serwera kompilacji, który uruchamia testy.

Jeśli zdarzy się coś, co zepsuje dany program, zostaniesz o tym poinformowany tak szybko, jak to możliwe, i możesz złapać winowajcę i rozwiązać problemy, gdy szczegóły są jeszcze świeże.


źródło