TheKoder dev diary #5

Temat przewodni dzisiejszego wpisu to refactoring!

Przyznaję: w poprzednim tygodniu nie miałem zbyt dużo czasu, żeby napisać chociaż linijkę kodu do gry. Owszem, nad projektem pracowałem, ale nie tym nad którym bym chciał – projekty na studia same się nie zrobią (a szkoda…) 😉

W związku z tym, że w tym sprincie był w planie refactoring od niego postanowiłem zacząć. Spodziewałem się że zajmie mi on więcej czasu, jednak udało zamknąć się w 4 godzinach. Skupiłem się głównie na plikach gry – osobną kwestią jest konfiguracja webpacka i skrypty npm – na nie też przyjdzie czas.

Tym sprzątaniem chciałem osiągnąć bardziej SOLIDny projekt. Do tej pory na pewno nie można było go za taki uważać, biorąc pod uwagę na przykład umieszczenie logiki gracza w jednym z plików State. Ale czym właściwie ten SOLID jest? Bardzo zwięźle ten akronim można rozpisać w ten sposób:

  • S (Single Responsibility Principle) – dany moduł, klasa czy też funkcja ma wykonywać tylko i wyłącznie jedno zadanie,
  • O (Open-Closed Principle) – w tej zasadzie chodzi o to, że moduł/klasa powinien być napisany w taki sposób aby nie trzeba było go modyfikować. Należy pisać kod w taki sposób aby był jak najbardziej uniwersalny,
  • L (Liskov Substitution Principle) – ta zasada mówi, że klasa dziedzicząca po klasie nadrzędnej może być użyta zamiast niej bez żadnych błędów,
  • I (Interface Segregation Principle) – w JS nie możemy tej zasady interpretować dosłownie ale można ją sprowadzić do stwierdzenia, że dany moduł powinien zawierać tylko te metody, które są mu potrzebne,
  • D (Dependency Inversion Principle) – moduły wysokiego poziomu nie powinny zależeć od implementacji modułów niskiego poziomu, relacje pomiędzy nimi powinna określać dodatkowa abstrakcja.

Żeby mój projekty bardziej trzymał się powyższych zasad, zrobiłem kilka rzeczy:

  • utworzyłem osobny folder na pliki konfiguracyjne, na razie wszystkie zmienne są w jednym pliku, ale kiedy będzie ich więcej będzie trzeba je rozbić na mniejsze w zależności czego dotyczą,
  • wyciągnąłem klasę Game do osobnego pliku,
  • klasa Game potrafi iterować po zaimportowanych do niej stanach gry, dzięki czemu nie muszę za każdym razem, kiedy utworzę nowy stan dopisywać go do Game
  • wyodrębniłem klasę gracza do osobnego pliku

Na koniec podzielę się przydatnym narzędziem, który odkryłem do pracy ze spritami — texturepacker. Z jego oceną jeszcze się wstrzymam, ponieważ nie testowałem go zbyt długo, ale na pewno ułatwia prace z animacjami w Phaserze. Jeżeli ktoś ma doświadczenie w pracy z tym narzędziem, zapraszam do podzielenia się opiniami w komentarzach 😉

Leave a Comment

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *