Też tak czasami macie, iż zastanawiacie się jaką strukturę projektu zaproponować? Jaka struktura sprawi, iż rozwijanie kodu nie będzie sprawiało problemów i każdy się odnajdzie? I ile razy nasze wysiłki nic nie dały? W tym wpisie chcę się z wami podzielić moją filozofią dotyczącą tworzenia struktury projektu.
1. Prostota jest piękna
Naczelna zasada, jaką się kieruję to prostota. Jestem przeciwnikiem tworzenia bardzo zagnieżdżonych struktur katalogów. Im struktura jest bardziej płaska, mamy mniej folderów zagnieżdżonych w sobie, tym jest lepiej dla całego projektu. Najlepiej pokaże to przykład czegoś, co staram się unikać:
Bardzo nie lubię katalogów shared. Jak dla mnie powodują one tylko zwiększenie ścieżki dostępu, a nie dają widocznych zalet. Dużo lepiej według mnie zrobić to w ten sposób
Dzięki temu od razu widać, jakie mamy katalogi i możemy się spodziewać, od razu co tam znajdziemy. A i tak w obrębie danej aplikacji wszystko jest współdzielone.
2. Zidentyfikuj warstwy
Podczas pisania aplikacji postaraj się zidentyfikować warstwy w aplikacji. Pomoże ci to w dzieleniu kodu na foldery i utrzymanie porządku. Przykładowymi warstwami w aplikacji SPA mogą być:
- dostęp do danych (np.: kod odpowiedzialny za pobieranie/aktualizację danych)
- przechowywanie danych (np.: redux albo contexty)
- komponenty biznesowe (np.: strona logowania)
- komponenty bazowe (np.: przyciski)
Dzięki takiemu podziałowi w strukturze plików i folderów zaczyna panować porządek i widać zależności między elementami. Osobiście polecam taki sposób dzielenia plików i zachęcam do spróbowania tej metody w swoim projekcie
3. Trzymaj rzeczy, które często się zmieniają obok siebie
Pliki, które są bardzo od siebie zależne, powinny być blisko siebie. Mam tu na myśli na przykład plik komponentu wraz z testami, stylowaniem, typowaniem itd. W momencie, gdy główny plik jest edytowany (w tym przypadku komponent), to istnieje duża szansa, iż pozostałe pliki też się zmienią. Trzymanie ich blisko siebie powoduje, iż nie tracimy czasu w znalezienie pliku. Same pliki wtedy można dać w jeden katalog, który będzie w pełni opisywał dany komponent i wszystkie jego zależności. Dlatego też nie jestem fanem trzymania testów jednostkowych w osobnym folderze niż testowany plik.
4. Nie bój się modyfikować struktury
Najważniejsze na koniec. Nie bój się zmieniać struktury. Baw się nią. Niech struktura kodu ewoluuje wraz z rozwojem projektu. Najlepiej od razu się pozbyć nadziei, iż początkowa struktura będzie optymalna pod koniec projektu. Dużo lepszym pomysłem jest pozwolenie na to by struktura plików i katalogów wyłoniła się sama z kodu. Fajnie to określił Dan Abramov:
"move files around until it feels right" (źródło)
W sytuacji, gdy widzisz, iż aktualna struktura jest niewygodna w korzystaniu, warto ją zmienić. Oczywiście trzeba się liczyć z tym, iż w niektórych projektach będzie to trudne/niemożliwe do zrobienia, ze względu na wielkość i poziom skomplikowania. I tu wchodzi dodatkowy czynnik, jakim jest doświadczenie. Wraz z jego wzrostem będziemy coraz lepiej porządkować nasze pliki i foldery, ponieważ wiemy, co działa a co nie. Co więc ma zrobić junior? jeżeli robi własne projekty, niech eksperymentuje. Nie brałbym od razu gotowych struktur, jeżeli nie wiemy, jakie szły za nią intencje. A co w przypadku projektów komercyjnych? Tutaj mam nadzieję, iż każdy junior ma dostęp do seniora, który podpowie co i jak zrobić by projekt dało się bezproblemowo rozwijać. jeżeli nie to możecie do mnie napisać, to spróbuję wam coś doradzić :)
