Na co zwracać uwagę w architekturze aplikacji?

Pisząc aplikację, należy zwrócić uwagę, by ta nie tylko dobrze działała, ale też była odpowiednio zorganizowana. Przemyślana architektura aplikacji pomoże nam nie tylko w dużych przedsięwzięciach, ale również w tych mniejszych. Pozwoli to zaoszczędzić wiele wysiłku, czasu i pieniędzy. Często też zadecyduje o tym, czy projekt przetrwa, czy nie.

Niełatwo jednak znaleźć odpowiedź na pytanie „Jak zbudować dobrą architekturę aplikacji?”. Pomimo wielu książek i artykułów poświęconych wzorcom i zasadom projektowania (jak chociażby SOLID) pojawia się wrażenie, że brakuje czegoś bardzo ważnego.

KRYTERIA DOBREJ ARCHITEKTURY APLIKACJI.

Ogólnie rzecz biorąc, nie ma powszechnie przyjętego pojęcia „architektury aplikacji”. Jednakże, jeśli chodzi o praktykę, dla większości programistów jasnym jest, który kod jest dobry, a który zły. Dobra architektura aplikacji to przede wszystkim architektura opłacalna, która sprawia, że proces tworzenia i utrzymywania jej jest prostszy i bardziej efektywny. Aplikację taką możemy z łatwością rozbudowywać, modyfikować, testować i debugować.

Dzięki temu możemy sformułować listę dość rozsądnych i uniwersalnych kryteriów:

Wydajność systemu.

Po pierwsze, aplikacja musi rozwiązywać zadania i wykonywać swoje funkcje dobrze i w różnych warunkach. Obejmują one takie cechy, jak niezawodność, bezpieczeństwo, wydajność, zdolność do radzenia sobie ze zwiększonym obciążeniem (skalowalność), itp.

Elastyczność systemu.

Każda aplikacja musi być z czasem modyfikowana - zmieniają się wymagania, dodawane są nowe. Im szybciej i wygodniej możemy dokonać zmian w istniejącej funkcjonalności, im mniej problemów i błędów będzie to powodować, tym bardziej elastyczny i konkurencyjny będzie system. Dlatego też w procesie tworzenia aplikacji staraj się ocenić, co w przypadku, gdybyś później musiał ją zmienić? Zadaj sobie pytanie: „Co się stanie, jeśli obecne rozwiązanie architektoniczne okaże się błędne?", „Ile kodu zostanie w tym przypadku zmienione?". Zmiana jednego fragmentu systemu nie powinna mieć wpływu na inne.

Rozszerzalność systemu.

Możliwość dodawania nowych podmiotów i funkcji do systemu bez naruszania jego podstawowej struktury. W początkowej fazie najlepiej jest umieszczać w systemie tylko podstawowe i najbardziej potrzebne funkcjonalności. Jednocześnie architektura powinna umożliwiać łatwe dodawanie kolejnych tak, by dokonanie najbardziej prawdopodobnych zmian wymagało jak najmniej wysiłku. Wymóg, by architektura systemu była elastyczna i rozszerzalna, sformułowano jako „zasadę otwarte-zamknięte" (druga z pięciu zasad SOLID): jednostki oprogramowania (klasy, moduły, funkcje itp.) muszą być otwarte na rozszerzenie, ale zamknięte na modyfikację.

Testowalność.

Kod, który jest łatwiejszy do przetestowania, będzie zawierał mniej błędów i działał bardziej niezawodnie. Ale testy nie tylko poprawiają jakość kodu. Wielu programistów dochodzi do wniosku, że wymóg „dobrej testowalności” jest również siłą przewodnią, która automatycznie prowadzi do dobrego projektu i jest jednym z najważniejszych kryteriów oceny jego jakości.

Wielokrotnego użytku.

Pożądane jest zaprojektowanie systemu w taki sposób, aby jego fragmenty mogły być ponownie wykorzystane w innych systemach.

Dobrze skonstruowany, czytelny i zrozumiały kod. 

Zazwyczaj wiele osób pracuje nad jedną aplikacją - niektórzy odchodzą, pojawiają się nowi. Po napisaniu zazwyczaj konieczne jest dołączenie do niej osób, które nie uczestniczyły w jej rozwoju. Dlatego dobra architektura powinna umożliwiać nowym osobom stosunkowo łatwe i szybkie zrozumienie systemu. Projekt powinien być odpowiednio skonstruowany, nie zawierać dublowania, posiadać dobrze zaprojektowany kod i najlepiej dokumentację. Jeśli to możliwe, należy stosować standardowe, ogólnie przyjęte rozwiązania znane programistom w systemie. Im bardziej egzotyczny system, tym trudniej jest zrozumieć go innym.

A jakie mamy kryteria złej architektury aplikacji?

Sztywność.

Trudno ją zmienić, ponieważ każda zmiana wpływa na zbyt wiele innych części systemu.

Kruchość.

Po wprowadzeniu zmian, inne części systemu nieoczekiwanie ulegają uszkodzeniu.

Nieruchliwość.

Kod trudno użyć ponownie w innej aplikacji, ponieważ wydobycie go z aktualnej jest utrudnione lub niemożliwe.

► Mam nadzieję, że ten artykuł pomógł Ci zrozumieć, czym jest dobra architektura aplikacji. Ważne, by tworząc ją, myśleć długoterminowo. Budowanie aplikacji, która jest funkcjonalna tylko w danym momencie, to rozwiązanie, które może zatrzymać jej dalszy rozwój i rozbudowę o dodatkowe możliwości. Skontaktuj się z nami, jeżeli poszukujesz ekspertów w tej dziedzinie!