Frameworki architektoniczne (dla Flexa) – moda, czy konieczność?

Podczas ostatniego spotkania udało mi się sprowokować (zażartą) dyskusję na temat sensu korzystania z frameworków architektonicznych w projektach (Flexowych). Wiele razy oglądaliśmy prezentacje różnych frameworków podczas spotkań grupy, prowadzone były dyskusje na temat wyższości jednego frameworka nad drugim. Jednak nigdy nie zastanawialiśmy się wspólnie, czemu korzystanie z frameworków jest ważne, po co i w jakich okolicznościach się je stosuje.

Najczęściej stosowane frameworki architektoniczne dla Flexa:

• Cairngorm (Adobe Open Source)
• PureMVC (Open Source)
• Mate (Open Source)
• Swiz (Open Source)

Poniżej znajdziecie wybrane argumenty za i przeciw stosowaniu frameworków.

ZA:

• Framework ułatwia radzenie sobie ze złożonością aplikacji. Programiści nie muszą tracić czasu na wymyślanie i ustalanie architektury aplikacji (struktury aplikacji, modelu przepływu danych oraz interfejsów między komponentami aplikacji), bo są one zdefiniowane przez framework. Programiści mogą się po prostu skupić na kwestiach specyficznych dla danego projektu, np. na logice biznesowej.
• Framework jest zwykle oparty (zbudowany) na wzorcach projektowych będących zastosowaniem dobrych praktyk projektowania i tworzenia kodu. Stosowanie zasad i ograniczeń zdefiniowanych przez framework zapewnia utrzymanie poprawnej architektury aplikacji przez cały czas trwania projektu.
• Frameworki powstają też po to, aby nie trzeba było za każdym razem wymyślać czegoś, co już zostało wymyślone i przetestowane wcześniej.
• Frameworki ułatwiają ponowne użycie fragmentów kodu w wielu projektach oraz nietworzenie równoległych funkcjonalności w obrębie jednego projektu.
• Frameworki zapewniają integralność kodu. Fragmenty tworzone przez wielu programistów mają szansę lepiej pasować do siebie i być jako całość jednolite w formie. Działanie aplikacji jest dobrze zdefiniowane i wszyscy muszą przestrzegać zasad tworzenia kodu.
• Frameworki są zwykle oparte na doświadczeniu zdobytym podczas tworzeniu wielu projektów, promują dobre praktyki programowania i pomagają rozwiązać często spotykane problemy.
• Frameworki wymuszają organizację elementów aplikacji poprzez zdefiniowanie zasad dotyczących organizacji kodu oraz funkcjonalności (łatwiej wprowadzać później zmiany, wielu programistów bez większych problemów może pracować nad jednym fragmentem kodu, kod jest mniej związany z programistą, który go stworzył).
• Programiści znający wybrany framework szybko mogą się porozumieć w kwestii zasad tworzenia i funkcjonowania kodu. Dołączenie nowego programisty znającego dany framework do zespołu projektowego jest dla tego programisty łatwiejsze, gdy zna on framework wykorzystywany w projekcie.
• Frameworki gwarantują lepsze zarządzanie zmianami poprzez zapewnienie jednolitego podejścia do architektury (w przypadku braku frameworka w dużych i długofalowych projektach architektura może się zmieniać, co może prowadzić do chaosu).
• Testerzy, specjaliści od dokumentacji i inni członkowie zespołów projektowych nie będący w ścisłym gronie programistów mogą łatwiej zrozumieć działanie aplikacji podczas wykonywania swoich obowiązków, jeśli aplikacja jest tworzona wg znanych i dobrze zdefiniowanych zasad (framework).
• Dzięki usystematyzowaniu architektury, w aplikacjach opartych o frameworki wyszukiwanie i eliminowanie błędów jest łatwiejsze.
• Stosowanie frameworków pozwala na zaoszczędzenie czasu i pieniędzy.

PRZECIW:

• Frameworki różnią się między sobą i nie wszystkie nadają się do wszystkich zastosowań. Trzeba poświęcić czas na zapoznanie się z frameworkami w celu wyboru najlepszego dla danego zespołu projektowego oraz założeń projektu. Tylko dobra znajomość frameworka gwarantuje efektywne jego wykorzystanie.
• W przypadku aplikacji wymagających dużej wydajności, może istnieć potrzeba zmodyfikowania kodu frameworka, co może być zadaniem trudnym i wymagającym dogłębnej znajomości jego wewnętrznego działania. W takiej sytuacji mogą też zaistnieć problemy formalne związane z licencjonowaniem modyfikowanego kodu oraz ze zgodnością nowych wersji frameworka z tą wykorzystywaną w projekcie.
• Wykorzystanie frameworka zwiększa objętość kodu. Jeżeli liczba linii kodu związana z projektem jest zmniejsza od liczby kodu frameworka, wtedy należy rozważyć wykorzystanie bardziej lekkiego rozwiązania lub zastosować własną, prostszą architekturę aplikacji.
• Frameworki zwykle rozwiązują najczęściej spotykane (standardowe) problemy. Istnieją założenia projektowe i zespoły, dla których istniejące frameworki nie przyniosą korzyści lub korzyści te będą częściowe – wtedy trzeba rozważyć stworzenie rozwiązania autorskiego (być może opartego na istniejących rozwiązaniach).
• Wykorzystując framework trzeba mieć spore zaufanie do jego twórców. Frameworki zwiększają objętość kodu aplikacji, mogą być zbyt skomplikowane w użyciu, mogą być napisane w niewydajny sposób, mogą zawierać błędy oraz luki bezpieczeństwa.

Korzystanie z frameworków architektonicznych staje się opłacalne lub nawet niezbędne w przypadku pracy wieloosobowej nad złożonymi projektami. Wykorzystywanie frameworków przez pracujących w pojedynkę developerów, zwykle nad mniej skomplikowanymi projektami, może nie przynieść już tak dużych korzyści. Jednak znajomość frameworków, nawet jeśli się z nich nie zawsze korzysta, ma kluczowe znaczenie dla programistów (umiejętność poprawnego tworzenia szkieletu aplikacji, zastosowania wzorców projektowych oraz dobrych praktyk tworzenia kodu, łatwiejsza integracja z członkami zespołów programistycznych w projektach realizowanych w przyszłości).