Refaktoryzacja kodu - szachy

Question

Witam, jakiś czas temu napisałem szachy w javascripcie. Kod, który napisałem jest moim zdaniem bardzo zagmatwany i skomplikowany. Chciałbym ten kod zrefaktoryzować, aby był bardziej czytelny dla innych i bardziej skalowalny. Niestety nie mam pomysłu od czego zacząć. Na razie nie chcę bardziej rozwijać tego projektu, a tylko uporządkować kod.

Link do szachów: https://github.com/Arcywojak/Chess

Answer 1

Zanim zaczniesz robić refaktor to pokryj kod testami, to Ci zapewni większe bezpieczenstwo, ja gdy mam zrefaktoryzowac jakis kawalek kodu to zawsze najpierw analizuje pokrycie testami ut, integracyjnymi i e2e aby móc potem faktycznie bezpiecznie robic refaktor. Dodaj testy e2e chociaz na podstawowe happy path i kilka.corner case j wtedy wez.sie za refactor.

Comments

Ja się z tym nie zgadzam. Testy, a szczególnie te wykraczające poza warstwę jednostkową, często przed refactorem są ciężkie do utrzymywania. Mam świadomość że taka praktyka jest stosowana, ale w systemach w których należy zapewnić 100% niezmienności działania przy refactorze.

---

Ale refaktor to właśnie zachowanie niezmiennosci zachowania biznesowego i to warto otestowac aby mieć pewność że nic nie popsules. Refaktor to nie zmiana logikj biznesowej, nie mylmy tych rzeczy. Miałem okazje robic sporo refaktorow czy nawet migracji apek np. Vanillajs do react jak zaczynały się rozrastac i wolę naprawdę poświęcić np. 1-2 dni na analize testow e2e i dodanie ewentualnych testow dla kluczowych procesow biznesowych niz potem co chwile recznie klikac całą apke... serio jestes zwolennikiem manualnego klikania milion razy czegos, co moze zrobić np. Cypress, testcafe itp.? Ja tam raczej wolę automatuzacje :) potem gdy siadasz do apki jaką robił ktoś inny to takie testy tez naprawde potrafia pomoc i czasami wykryc problemy... ale oczywiście dużo zależy od podejscia do pisania apki... ja staram sie patrzeć nie tylko na krotkotrwaly development ale tez na dalsze utrzymanie apki i nowe ficzery... dlatego u mnie w zespole zawsze przy ficzerach wyznaczamy sobie czas na odpowiednie testy reczne i dodanie odpowiednich automatow. To się naprawdę oplaca.

---

@Tomek Sochacki, a czy w sytuacji, gdy chciałbym później zmienić strukturę, rozmieszczenie lub kolejność wywołynia poszczególnych funkcji to czy testy wcześniej napisane nie stałyby się bezużyteczne i trzeba by było napisać je od nowa?

---

Po prostu trzeba bh je odpowiednio zaktualizowac, ale teraz piszesz ze chcesz robić refaktor a nie zmiany beznesowo uxowe.

---

@Tomek Sochacki, taka jest praktyka produkcyjna gdzie trzeba mieć pewność, że system nie zmienia swojego działania. 

Lepszym rozwiązaniem jest refactor poszczególnych elementów, tak aby można było je testować jednostkowo.

---

@Tomek Sochacki, 0 % pokrycia testami - testujemy za mało  100% pokrycia testami, testujemy za dużo :D jak to mawiaja