Refaktoryzacja - szkielet

Refaktoryzacja

Korzyści
1. Narzędzia
  1. Podejście ‘od problemu do rozwiązania’ przy refaktoryzacji
  2. Podejście systemowe
  3. Pętla ‘koncepcja-cele-implementacja-weryfikacja’ w praktyce, w sposób możliwy do powtórzenia.
  4. Celowość, iteracyjność, kryterium końca
2. Korzyści
  1. Inżynierskie podejście do przebudowania kodu pod kątem celu
  2. Sprawdzenie, czy zmiany jakie chcecie wprowadzić są “lepsze”
  3. Dostaniecie recepturę, która u mnie się sprawdza przy małych i dużych.
  4. Refaktoryzacja nie jest straszna
Streszczenie myśli przewodniej
1. Refaktoryzacja to przebudowa nie zmieniająca wymagań funkcjonalnych.
2. “Refaktoryzacja” sama w sobie nie ma sensu. Musi być “refaktoryzacja do czegoś”, pod kątem celu.
3. Przebudowa istniejącego kodu wymaga przeanalizowania całości systemu, nie tylko tego elementu systemu.
4. Sukces refaktoryzacji zależy od zidentyfikowania problemu i zaplanowania działań.
5. Proponuję podejście: “Kontekst -> problem -> ideał -> (strategia <-> weryfikacja strategii) -> (działanie -> weryfikacja wyniku)”
6. Iteracyjność, ewolucja a nie rewolucja. Ustawienie warunków sukcesu.
7. Bez zrozumienia problemu i domeny refaktoryzacja raczej nie przyniesie maksymalnego zwrotu.
8. Jeśli nie wiesz po czym poznasz sukces, nie osiągniesz sukcesu i nie obronisz rozwiązania.
Kontekst refaktoryzacji
1. Co to: Przebudowa bez zmian wymagań funkcjonalnych
2. Wyjaśnienie systemu: przykład silnika parowego, który ma działać też na Syberii jak i na pustyni
  1. Część, Całość, Otoczenie
3. Wszystko się zmienia przez zmianę Otoczenia biznesowego. Refaktoryzacja jest dostosowaniem do CZEGOŚ
4. Restrukturyzacja w firmie. Firma 3-osobowa, firma 10000-osobowa.
5. Ten artykuł unika politycznego aspektu refaktoryzacji
Jak to robić - pobieżnie?
1. Kontekst -> problem -> ideał -> (strategia <-> weryfikacja strategii) -> (działanie -> weryfikacja wyniku)
2. Iteracyjne podejście: Ewolucja, nie rewolucja
3. Przepisanie lub przeniesienie
4. Kryterium końca
Przykład z regexami
1. Kontekst: regexy
2. Problem: nowa osoba ma dużo kopiowania i wklejania kodu by zrobić nowy regex
3. Poznam sukces po: łatwo dodać nowy element, nawet junior da radę, bez durnego kopiowania
4. Ideał: losowy junior może łatwo dodać nowy regex
5. Strategia 1: wydzielenie regexów do stringów
6. Weryfikacja str 1: PORAŻKA. Regexy są trudne dla juniora
7. Strategia 2: parametryzacja regexów
8. Weryfikacja str 2: Sukces, junior potrafi pracować z funkcjami
9. Działania: zbiór kroków
10. Weryfikacja wyniku:
  1. porównanie czasu na dodanie nowego elementu przez weterana (mnie)
  2. sprawdzenie jak łatwo dodać nowy regex
11. Sami możecie zrobić to ćwiczenie
  1. Link do ćwiczenia
  2. Opisanie ćwiczenia
  3. Link do zbiorczego commita
  4. Link do brancha na rdbutlerze
Jak to robić - omówienie?
1. Kontekst -> problem -> ideał -> strategia <-> weryfikacja strategii -> działanie -> weryfikacja wyniku
2. Iteracyjne podejście: Ewolucja, nie rewolucja
3. Przepisanie lub przeniesienie
4. Kryterium końca
Co jest potrzebne?
1. Domena
2. Mierzalny sposób weryfikacji
3. Kontekst: w czym działam (500 milisekund, hardware zajmuje 600 milisekund)
4. Kontekst: Otoczenie jako System (problem bazy danych z nullami)
Podsumowanie
1. Niektóre cele są sprzeczne; dlatego nie ma refaktoryzacji idealnej
2. Stożek nieoznaczoności: najlepiej pisać kod pod kątem “łatwo go zmienić”, nie “idealny kryształ”
3. Kod to UI programisty. Skupienie na testowalności i mutowalności
4. Nie znam żadnych “uniwersalnych technik” - wszystkie są kontekstowe
5. Obszary ciepłe aplikacji, obszary zimne aplikacji - krystalizacja z czasem
6. Refaktoryzacja to przede wszystkim problem polityczny
Wykazanie korzyści
1. Przebudowanie kodu pod kątem celu
2. Czy zmiany są zmianami “na lepsze”?
3. Receptura jak to robić by działało.
4. Refaktoryzacja nie jest straszna.