Porządki w projekcie

Święta, święta i po świętach jak to mówią. W naszej długiej polskiej tradycji przyjęło się robić porządki przed świętami. Ja osobiście nigdy nie byłem przekonany specjalnie do tradycji i zawszę robię coś nie tak w tej kwestii. Dlatego też u mnie porządki zaczynają się po świętach. Ale nie martwcie się. Nie będę pisał o tym jak poprawnie odkurzać, myć okna, czy wyrzucać śmieci. To zostawiam Perfekcyjnej Pani Domu 😉 U mnie za to dowiecie się w jaki sposób można zorganizować kod w projekcie AngularJS.

Tak jak w większości przypadków jeśli chodzi o programowanie, tak i w tym nie ma jednoznacznie określonego, najlepszego sposobu w jaki można uporządkować kod Angularowy w projekcie. Kiedy zaczynałem swoją przygodę z tym frameworkiem całe szczęście, że nie wziąłem się od razu za duży projekt. Jakby spojrzeć na to jaki chaos panował w tych malutkich aplikacji to bardziej doświadczeni koledzy od razu powiedzieliby pewnie, że nie da się z tego nic ogarnąć i gdyby ciągnąć to dalej to byłbym skazany na wielką zagładę. Szczęśliwe jednak sam to dosyć szybko zauważyłem i postanowiłem poszukać w otchłaniach Internetu jak robią to zawodowcy. W tym przypadku w sumie jak zwykle sporą pomocą okazał się niezawodny ostatnio Pluralsight.

Angular for .NET Developers – Joe Eames i Jim Cooper postanowili nakręcić świetny film dla ignorantów takich jak ja, którzy do tej pory świata poza dot Netem nie widzieli. Oczywiście mogę polecić z czystym sercem cały, trwający ponad 5 godzin kurs, ale na moje potrzeby opiszę tylko jedno krótkie zagadnienie. Organizacja kodu w projekcie. Teoretycznie zagadnienie wydaje się trywialne. Ile może być sposobów na to jakie pliki i foldery tworzymy w naszym kodzie. Jak się jednak okazuje sposobów mamy całkiem sporo i każdy niesie za sobą jakieś wady i zalety.

1. All in one

Sposób wszystko w jednym. Oczywiście nie chodzi o to, żeby całą aplikację napisać w jednym pliku chociaż jest to możliwe. W tym sposobie chodzi o to, że tworzymy po jednym pliku w którym będziemy umieszczać wszystkie dyrektywy jednego typu.

all in one

Będziemy zatem każdy kontroler pakować do pliku controller.js, każdy serwis do services.js itd.

Zalety

Zaletą tego podejścia jest to, że po dodaniu nowego kontrolera trzeba pamiętać, że musimy dodać nowy plik w indexie. Może to być całkiem wygodne, ale…

Wady

Niestety przy większej aplikacji będziemy musieli się zmierzyć z ogromnymi blokami kodu w każdym z plików.

Jak zaczynamy przygodę z angularem można spróbować tego podejścia. Trzeba się jednak liczyć z tym, że Ctrl + F musi stać się naszym najlepszym przyjaciele, bo inaczej niczego nie będzie można znaleźć. Z drugiej strony mój częsty problem wiążący się z zapominaniem o dodaniu odpowiedniej linijki w danym pliku może tutaj sporo ułatwić sprawę 🙂

2. Typy

Drugi sposób delikatnie usprawnia problem, który pojawia się po pierwszym. Przy tym podejściu tworzymy oddzielne foldery dla głównych dyrektyw i tam pakujemy kolejne pliki .js po jednym na każdy kontroler, filter, fabrykę.

typy

Zalety

A w zasadzie znowu tylko jedna zaleta. I to niestety tylko w porównaniu do poprzedniego podejścia. Nie mamy wszystkiego w jednym pliku w związku z czym nie musimy się przekopywać przez tysiące linii kodu. I to niestety by było na tyle.

Wady

Niestety ten sposób nie bardzo poprawia nam sytuacje z poprzedniego sposobu. Nadal mamy spory pierdzielnik przy większej ilości modułów/podstron czy czegokolwiek. Dodatkowo już teraz trzeba pamiętać, że trzeba dodać każdy kolejny plik w indeksie.

 

Pomimo swoich wad sposób ten może być w miarę akceptowalny przy niewielkich projektach. No i dodatkowo delikatnie przypomina sposób zarządzania kodem w prostych aplikacjach ASP.NET MVC. Dlatego w celach edukacyjnych zdecydowanie może być używany.

3. Moduły

Kolejny sposób początkowo brałem pod uwagę przy wyborze swojego ideału do projektu. Mamy tutaj do czynienia z całkiem sensownym podziałem plików na moduły. Załóżmy, że mamy moduł Dań, Użytkowników, Administracyjny i jakieś inne. Dla każdego modułu tworzymy oddzielny folder i do niego pakujemy wszystkie pliki z nim związane.

moduly

Zalety

No tutaj już będzie trochę więcej. Po pierwsze mamy bardzo logiczny podział plików, który zbliżony jest do tego jak myślimy o aplikacji. Po drugie nawet przy większej ilości plików nie mamy dużego problemu z jego znalezieniem, bo wiemy gdzie szukać. Po trzecie w przypadku kiedy więcej programistów pracuje nad aplikacją nie wchodzą oni z buciorami do naszego rejonu, bo każdy może zajmować się innym modułem.

Wady

Jak każdy sposób tak i ten ma swoje wady. Niestety przy większych modułach możemy spotkać się z problemem wyszukiwania dokładnie tego czego potrzebujemy. W każdym module może być przecież więcej niż jeden kontroler, serwis, filtr czy widok. Mimo, że wszystko mamy w jednym miejscu może to się zrobić nieco upierdliwe. Z pomocą może przyjść bardzo przemyślane nazywanie poszczególnych plików, ale nie zawsze o tym pamiętamy, a że właśnie pamięć jest najbardziej zawodna w życiu człowieka to jednego dnia możemy pomyśleć, że to świetna nazwa, ale już po tygodniu nie będziemy wiedzieli o co nam chodziło.

4. Mix

Ostatni sposób, który chciałbym opisać to mix sposobu drugiego i trzeciego. W sposobie tym najpierw dzielimy aplikację na moduły i takie też foldery tworzymy, a następnie w każdym folderze tworzymy kolejne foldery, które odpowiadać będą funkcjom.

mix

Zalety

Zdecydowanie najwięcej w przypadku dużych projektów. Mamy logiczny podział na moduły, a dodatkowo nie ma problemu z odróżnieniem kontrolerów od serwisów, czy fabryk. Porządek w tym przypadku widać na pierwszy rzut oka. W Visual Studio nie musimy oglądać wszystkich plików, które mamy w projekcie. Wystarczy pozwijać nie potrzebne na tę chwilę moduły i podfoldery i widzimy tylko i wyłącznie to nad czym pracujemy.

Wady

Jednakże nie ma rozwiązania idealnego. Ten sposób mimo, że bardzo elegancki wymaga od nas największych nakładów pracy. Fakt jest to praca tylko odrobinę dłuższa, ale jednak trzeba poświęcić ten czas na to, żeby przygotować foldery na każdym stopniu.

 

Jaki sposób jest najlepszy?

No i na to pytanie tak jak już wcześniej wspominałem nie ma jednoznacznej odpowiedzi. W przypadku małych projektów myślę, że sposób 2, albo 3 zdecydowanie będzie najbardziej przyjazny ze względu na to, że możemy się skupić szybko na kodzie, a nie na budowania drzewka folderów.

Raczej starałbym się wystrzegać sposobu pierwszego, bo możemy nabawić się jedynie złych nawyków (nie tylko jeśli chodzi o JS). Przecież wielu z nas na studiach była powtarzana jak mantra maksyma, że jeden plik/klasa na jedną funkcjonalność.

Sposób 4, ostatni zdecydowanie najlepiej nada się przy dużych projektach, gdzie musimy działać z naprawdę dużą ilością plików.

Co wybrałem do Social Cooking?

Oczywiście w związku z tym, że portal w planach ma być naprawdę potężną machiną to od samego początku stosuję sposób numer 4. Będzie on dla mnie najbardziej wygodny mimo, że pracuję sam ze względu na to, że już w zamyśle mam kilkanaście kontrolerów, dziesiątki serwisów i setki widoków. Mam nadzieję, że starczy mi siły na nudne tworzenie kolejnych drzewek folderów 😉

Related posts