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

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?

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).

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.

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.