git-interactive
Code Review a spacje i inne pierdoły
Chodzi o taką sprawę:
Te ciemno zielone to kilka dodatkowych spacji, które się pojawiło (a nie było ich wcześniej). (Inne to np, dodatkowo zbędna, podwójna linia, brak pustej linii, brak spacji w parametrach lub zbyt duża ich liczba, itp, itd.)
Przypadkowo podczas pracy nad kodem gdzieś się pojawiło kilka spacji za dużo lub za mało. Czy chcielibyśmy przypieprzać się do takich rzeczy na Code Review? – nie bardzo, są ciekawsze rzeczy do kminienia. Jak unikać takich przeszkadzajek.
- Formatować kod przed commitem, a najlepiej na bieżąco, skrót Ctrl+k, Ctrl+d.
- Jeśli powyższego nie możemy zrobić, bo ogólnie cały kod jest syfiasty gdy chodzi o wcięcią/formatowani to możemy formatować tylko kod który dodaliśmy. Zaznaczamy kod i ten sam skrót. To akurat robię rzadko.
- Jeśli już nie możemy (albo nie chcemy) korzystać z automatycznego formatowania to przed pushowaniem do centralnego repozytorium powinniśmy oczyścić commity z takich przeszkadzajem (git rebase interactive)
- Już naprawdę w ostateczności gdy nic z powyższych nie podziałało to podczas tworzenia pull requesta (obszerny opis o co w tym biega na przykładzie Git/BitBucketa) zobaczmy wszystkie nasze zmiany. Na tym etapie wyłapiemy te pierdoły, na które będzie tracił czas każdy robiący Code Review (a czasem jest to kilka osób, których czas byśmy zmarnowali).
Innym podejściem jest włączeniem do projektu StyleCopa. Dzięki temu wymusimy pewne standardy formatowania, czyli brudną robotę odwali za nas narzędzie.
Git przypadki użycia – refactoring w trakcie pisania kodu
- Refactoryzowałem przeniesienie logiki w inne miejsce. Zmieniły się zależności jakie pobieraja serwisy => trzeba dostosować Unit Testy (MyServiceTests). Zmiany w UT polegaja jedynie na dodaniu dodatkowego parametru jaki wstrzykujemy do testowanego serwisu – zmiana w jednej klasie ale w kilku testach.
- Zauważyłem, że nasze testy powinny korzystać z SUT Factory (System Under Test) – tworzenie testowanego serwisu powinno być tylko w jednym miejscu aby ewentualne zmiany w zależnościach (konstruktor) tego serwisu wymagały tylko jednej zmiany.
- – commituje aktualnie zmieniony kod (aktualnie projekt się nie kompiluje), powiedzmy ze jednem na branchu “development”
– przechodze na nowego brancha “sut-refactoring”, cofam sie “git reset –hard head^” o jeden commit do stanu sprzed refactoringu
– wykonuje punkt 2) czyli refactoring do SUT, sprawdzam czy testy przechodza.
– wracam “development”
– pobieram jeden commit z poprzedniego brancha “git cherry-pick sut-refactoring”
– zamieniam miejscami dwa ostatnie commity aby ten z sut-refactoring był wcześniej. “git rebase -i head^^” i zamieniam miejscami – konieczna znajomość rebase interactive
– wprowadzam zmiany w teście MyServiceTests, teraz wystarczy tylko jedna zmiana w fabryce tworzacej testowany serwis (SUT Factory) – sprawdzam czy testy przechodza.
– zmiany łaczace z ostatnim commitem (znowu znajomość rebase interactive) - Implementuje metodę która była dotychczas stubem.
private void HandleCopyButtonControl(FieldRenderingDefinition control) { // TODO: RQ-1234 }Po zaimplmentowaniu okazało się, że miejsce z którego jest wołana metoda z bugiem i działało dotychczas tylko dlatego, że nasza metoda była pusta. Commitujemy. Zmieniamy tamto miejsce niezależnie (zamieniając ify na switcha), commitujemy. Zamieniamy commity miejscami.
