Deli

Dobra arhitektura sistema pride do izraza pri dodajanju novih funkcionalnosti in pripomore k enostavnosti vzdrževanja ter nižanju razvojnih stroškov.

Pomembnost-arhitekture-sistema-iPROM-mnenja-strokovnjakov-Nejc-Lepen

Septembra sva se s sodelavcem Luko Andrejakom udeležila londonske konference SymfonyLive, ki jo je predstavil tu. Sam pa sem se podrobneje dotaknil predavanja Hexagonal architecturemessage-oriented software design, o katerem je razpravljal Matthias Eberlei. Ker se v iPROM-u s podobnimi sistemskimi izzivi srečujem prav vsak dan, sem želel temeljiteje predstaviti svoj pogled na pomembnost dobro zastavljene arhitekture sistema in predvsem pojasniti, zakaj je ravno njeno načrtovanje bistveno za vse nadaljnje razvojne in vzdrževalne procese.

Zakaj govorimo o arhitekturi sistema

Večinoma zato, ker si želimo, da pri dodajanju novih funkcionalnosti naše aplikacije oziroma sistemi ohranijo lastnost enostavnega vzdrževanja in nizkih razvojnih stroškov. Iz tega razloga je na njihovo arhitekturo potrebno misliti že na samem začetku razvoja aplikacije. V nasprotnem primeru bodo njihove posodobitve in vzdrževanje stale veliko več kot začetna pravilna postavitev arhitekture.

Klasična postavitev projekta oziroma osnovna zasnova programske opreme si običajno sledi po tem zaporedju:

  • Izbira ogrodja (framework)
  • Postavitev ogrodja
  • Generiranje CRUD kontrolerjev
  • Generiranje entitet
  • Zaključek postavitve

Nice app

KISS (Keep It Simple, Stupid)

Načeloma s takšno, preprosto strukturo ni nič narobe. V kolikor je projekt manjši in se aplikacija ne bo bistveno spreminjala, razvijala ali vzdrževala, bo slednja tudi zadovoljila potrebe, ki temeljijo na predvideni arhitekturi ogrodja.  Pri projektih večje razsežnosti, ki se nadgrajujejo v daljšem časovnem roku,  pa nas »preprosta« rešitev lahko stane veliko več in nas pripelje do zelo zahtevnega vzdrževanja ter dragega dodajanja novih funkcionalnosti.

Kljub temu je ena izmed najpogostejših napak razvijalcev programske opreme ravno ta, da ob sami postavitvi ogrodja ne razmišljajo o nadaljnjih nadgradnjah sistema ter njegovem dolgoročnem vzdrževanju in dodajanju novih funkcionalnosti. Z drugimi besedami – na začetku postavijo preveč preprosto arhitekturo, v kateri je med moduli prisotna pretirana odvisnost.

Razmišljajte dolgoročno

V večini primerov aplikacije niso preproste, poleg tega pa so pri sodobnih večjih aplikacijah vedno potrebne nadgradnje sistema. Vzrok za to so naknadne priključitve novih sistemov, pridobivanje in shranjevanje podatkov v nek »tretji« sistem ter spreminjajoče dinamike trga in vse bolj zahtevnih uporabnikov.

Primanjkljaj dolgoročnega razmisleka še posebej pride do izraza, ko razvijalci programske opreme sistemu dodajajo funkcionalnosti, ki prvotno niso bile razvite izključno zanj ali pa ko morajo vanj dodatno implementirati možnost povezovanja drugih sistemov, denimo preko API-jev ali drugih izvorov oziroma podatkovnih skladišč ipd.

V kolikor se razvijalci programske opreme ne držijo vseh začrtanih arhitekturnih pravil, ki jih na začetku postavi načrtovalec aplikacije, lahko aplikacija konvergira k zelo zapletenemu, skorajda neobvladljivemu sistemu. Takšna, večinoma nepredvidena eskalacija se seveda pokaže tudi pri znatno višjih stroških za vzdrževanje in implementaciji novih funkcionalnosti.

hexagonal-architecture-messageoriented-software-design-4-638

 

Kako se arhitekture sistema lotimo pravilno

Delovanje aplikacije si lahko že v načrtovalni fazi zamislimo na bolj abstraktnem nivoju, ki od nas zahteva postopno reševanje problemov oz. Funkcionalnosti. Za to uporabimo več nivojsko strukturo, pri čemer je ključno, da jedro aplikacije iz osnovne infrastrukture izločimo in ga predstavimo na abstrakten način. Medtem, ko ostale probleme lahko rešujemo preko nivojev in večplastnosti aplikacije.

Kljub temu pa želim poudariti, da univerzalne rešitve ni; kar pomeni, da tovrstnega načrtovanja ne moremo aplicirati na čisto vse projekte. Bolj je pomembno, da razvijalec pri zasnovi arhitekture upošteva več aspektov in da se pri tem nasloni na primere dobre prakse. Predvsem pa je nujno, da se dobro zaveda samega obsega in kompleksnosti projekta, saj ravno na podlagi teh podatkov lahko presodi, kakšna arhitektura bo najbolje delovala in izbere primerno programsko opremo, ki bo ustrezno reševala specifične izzive aktualnega projekta.

hexagonal-architecture-messageoriented-software-design-47-638

Zato bom v naslednjem prispevku podrobneje predstavil načelo heksagonalne arhitekture, ki nam dovoljuje bolj kompleksno in odprto načrtovanje; s tem pa zagotavlja ciljno reševanje nadaljnjih razvojnih izzivov, ki ne posegajo v druge module aplikacije. 

Deli

Deli prispevek prek e-pošte

Vaše kontaktne podatke (ime, priimek in elektronski naslov) ter posredovani kontakt prejemnika (elektronski naslov) potrebujemo, da lahko na prejemnikov elektronski naslov posredujemo vaše sporočilo. Prejetih podatkov ne bomo uporabili za druge namene. Z vnosom vaših podatkov in podatkov prejemnika, izjavljate, da imate od prejemnika pridobljeno privolitev za posredovanje njegovega/njenega kontakta. V kolikor podatkov ne boste oddali, želenega sporočila ne bomo mogli posredovati. Več o vaših pravicah in varstvu osebnih podatkov izveste tukaj.

O avtorju

Nejc Lepen je v iPROM-u zaposlen kot direktor razvojnega oddelka. Njegova ekipa programerjev je zaslužna za razvoj vodilnih novih tehnologij in rešitev – med drugim tudi za upravljanje in nadgradnje oglasnega strežnika iPROM AdServer, ki spada v sam vrh programskih rešitev za upravljanje oglaševanja v digitalnih medijih. Obenem je Nejc tudi administrator iPROM-ove pisarne v oblaku in vodja internega CRM sistema iPROM Intranet, ki našim zaposlenim poenostavljata komunikacijo in omogočata večjo fleksibilnost pri delu ter lokacijsko neodvistnost. Z dolgoletnimi izkušnjami in znanjem je nepogrešljiv člen pri vseh ključnih razvojnih projektih, ki jih iPROM izvaja za naročnike na domačem in tujih trgih.

Vsi prispevki avtorja