Jak refaktorujete rubrika: Programování: Jiné
3
vaclav
V návaznosti na diskuzi v otázce http://devel.cz/otazka/pouzivani-gitu-pri-zbesilem-refactoringu by mě zajímalo jak konkrétně refaktorujete a co bych se mohl přiučit. Co mě nejvíce zajímá:
- jak velké celky refaktorujete
- jak změny promítáte do produkce
- jak (pokud děláte) řešíte code-review
- jak při tom používáte Git/Mercurial
- cokoliv zajímavého k tématu :-)
4
dominios
Vzdy refactorujem len tolko co je treba, ale tak, aby sa refactorovalo vsetko co s tym suvisi. Ak ide o nejake zmeny nazvov tried/metod, tak v 1 commite zahrniem vsetky premenovania napriec celou aplikaciou, nerobim ale pri tom nic ine. V mojom pripade, updatnem zaroven aj testy (ale len v takych pripadoch premenujem co treba, inu logiku nepridavam/nemenim). Vysledkom je 1 commit, do ktoreho napisem renamed class x to class y a je to jasne a vystizne. Ak v buducnosti najdem nieco, co som nezmenil (to je ale malokedy, nakolko pouizvam IDE), tak na to urobim samostatny commit, nikdy nie ammend, to by bol chaos.
Ak sa refactoring tyka vela veci naraz, urobim samostatnu branchu a tam aplikujem zmeny postupne a tak mergnem. Vzdy vsak plati, ze sa snazim robit commity tak, aby riesili vzdy len 1 vec, nikdy nic viac. Vynimkou je mozno sem-tam mala zmena dizajnu ktora s tym len okrajovo suvisi... Radsej urobim 5 commitov kludne po zmene 1 riadku ak ide o male fixy nez 1 commit s textom fixed issues with something and something else. Tak isto, ak sa da, snazim sa vsetko parovat na issues v gitlabe a 1 commit vzdy riesi len 1 issue (ak teda nieje duplicita alebo to nieje naozaj potrebne). Pri zlozitejsich issues si tak isto vytvaram samostatnu branchu v ktorej to riesim, takto mam vzdy poriadok.
Pokial sa meni uz navrhnuta struktura rozrhani (navratove typy a pod.) tak uz nejde o refactoring ale redesign a tam je to samozrejme tazsie. Vyvoj (a praca s gitom) je rovnaka, davam akurat vacsi doraz na branche aby bolo jasne co sa robi. Vzdy sa snazim (aj ked sa to nie celkom da), aby som v 1 commite zahrnul vsekty zmeny zmeneneho 1 ifacu, v druhom dalsieho, potom x bugfixov, uprava testov, bugfixy, atd., a az tak merge do mastru (resp. ja miesto mastru pouzivam ako hlavnu dev vetvu, do mastru davam prakticky az release).
Nasadenie do produkcie: s tym az tak vela skusenosti nemam, ale z hladiska backendoveho kodu viac menej verim testom. Tzn.: ak som robil nejake zmeny a testy prechadzaju, tak si na produkcnom serveri proste pullnem zmeny.
Pro zobrazení všech 2 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře