Hatékonyság
A tapasztalt programozók könnyen meg tudják különböztetni a jó architektúrát a rossztól, de ha megkérik őket, hogy írjanak le néhány szóban, valószínűleg nem tudják megtenni. A jó architektúrának nincs egyetlen kritériuma, és nincs egyetlen definíció sem.
Ha azonban belegondolunk, számos kritériumot írhatunk, amelyeknek egy jó architektúrának meg kell felelnie. A jó architektúra mindenekelőtt egy olyan logikus architektúra, amely egyszerűbbé és hatékonyabbá teszi a programok fejlesztésének és karbantartásának folyamatát.
Ha egy programnak jó architektúrája van, mindig elég könnyű megérteni, hogyan működik, és hová kell kódot írni. Egy jól megtervezett programot könnyebb megváltoztatni, tesztelni, hibakeresni és fejleszteni. Az okos emberek a következő kritériumokat fogalmazták meg a jó építészethez:
- Hatékonyság;
- Rugalmasság;
- Bővíthetőség;
- Skálázhatóság;
- tesztelhetőség;
- Kód karbantarthatósága.
A rendszer hatékonysága. A programnak természetesen a rábízott feladatokat kell megoldania, funkcióit jól, változatos feltételek mellett kell ellátnia. Úgy tűnik, hogy minden program azt csinálja, amit tennie kell (ha meg van írva), de gyakran ez egyáltalán nem így van.
Folyamatosan találkozni fogsz olyan programokkal, amelyek nem azt csinálják, amit állítanak.
- A Libre Office a Microsoft Office teljes helyettesítője (nem igazán);
- Az Edge böngésző támogatja az összes webes szabványt (nem igazán);
- A bank törődik felhasználói személyes adatainak biztonságával (valójában nem).
És még nem érintettük a teljesítményt, a megbízhatóságot, az időszerű hibajavításokat vagy az ismert sebezhetőségekről szóló információk közzétételét.
Nyilvánvaló, hogy senki sem tökéletes, de a programnak meg kell oldania az elsődleges feladatait. Ezért hatékonyság nélkül sehol.
Rugalmasság
A hatékonyságnál szerintem csak a rugalmasság fontosabb. Minden alkalmazásnak változnia kell az idő múlásával, ahogy a követelmények változnak, újak kerülnek hozzáadásra. Minél gyorsabban és kényelmesebben módosítható a meglévő funkcionalitás, minél kevesebb problémát és hibát okoz, annál rugalmasabb a rendszer architektúrája.
Nagyon gyakran a kezdő programozók/építészek úgy gondolják, hogy ideális architektúrára van szükségük az aktuális feladatokhoz. Nem. Ideális architektúrára van szüksége az egy év múlva bejelentett feladatokhoz. Önnek, aki már most nem ismeri a jövőbeni feladatokat, tudnia kell, hogy mik lesznek.
Nincs értelme megjósolni őket, mert mindig lesz valami váratlan. De figyelembe kell vennie, hogy ilyen feladatok megjelennek. Ezért a fejlesztési folyamat során próbálja meg felmérni, hogy mit kapunk abból a szempontból, hogyan kell majd változtatni.
Tedd fel magadnak a kérdést: "Mi történik, ha a jelenlegi építészeti döntés hibásnak bizonyul?", "Mennyi kódot módosítanak?". A rendszer egy töredékének megváltoztatása nem érintheti a többi töredékét.
Lehetőség szerint az építészeti döntéseket nem szabad kőbe vésni, és ésszerűen korlátozni kell az építészeti hibák következményeit. "A jó architektúra lehetővé teszi a kulcsfontosságú döntések KÉSLELTETÉSÉT" (Bob Martin), és minimalizálja a hibák "költségét".
Az egyik ilyen megközelítés az alkalmazás mikroszolgáltatásokra bontása: könnyű a már meglévő logikát külön részekre bontani. A legnagyobb probléma azonban az, hogy a jövőben egyszerre több tucat szolgáltatást módosítsunk egy kis funkció megvalósítása érdekében.
Skálázhatóság
A skálázhatóság a fejlesztési idő csökkentésének képessége új emberek hozzáadásával a projekthez. Az architektúrának lehetővé kell tennie a fejlesztési folyamat párhuzamosítását, hogy egyszerre többen dolgozhassanak a programon.
Úgy tűnik, hogy ezt a szabályt magától hajtják végre, de a gyakorlatban minden pontosan az ellenkezője. Még egy szupernépszerű könyv is létezik, a The Mythical Man-Month , amely elmagyarázza, miért növeli meg a fejlesztési időt, ha új embereket adunk egy projekthez.
Bővíthetőség
A bővíthetőség az a képesség, hogy új funkciókat és entitásokat adjunk a rendszerhez anélkül, hogy megsértenék annak alapvető struktúráját. A kezdeti szakaszban célszerű csak az alapvető és legszükségesebb funkciókat beépíteni a rendszerbe.
Ez az úgynevezett YAGNI elv – nem lesz rá szükséged , „nem lesz rá szükséged”. Ugyanakkor az architektúrának lehetővé kell tennie a további funkciók igény szerinti egyszerű növelését. És úgy, hogy a legvalószínűbb változtatások bevezetése igényelte a legkevesebb erőfeszítést.
Az a követelmény, hogy a rendszer architektúrája legyen rugalmas és bővíthető (vagyis legyen képes a változásra és fejlődésre), annyira fontos, hogy ez még külön elvként – a „Nyitott/Zárt elvként” – fogalmazódik meg . A nyitott-zárt elv a második az öt SOLID-elv közül: a szoftveres entitásoknak (osztályoknak, moduloknak, függvényeknek) nyitottnak kell lenniük a kiterjesztésre, de zárva kell lenniük a módosításra .
Más szóval: lehetővé kell tenni a rendszer viselkedésének megváltoztatását és kiterjesztését a rendszer meglévő részeinek átírása nélkül .
Ez azt jelenti, hogy az alkalmazást úgy kell megtervezni, hogy a viselkedésének megváltoztatása és új funkciók hozzáadása új kód (bővítmények) írásával érhető el anélkül, hogy a meglévő kódot módosítani kellene.
Ebben az esetben az új követelmények megjelenése nem jelenti a meglévő logika módosítását, hanem elsősorban annak bővítésével valósítható meg. Ez az elv a "plug-in architektúra" (Plugin Architecture) alapja. Azokról a technikákról, amelyekkel ez megvalósítható, később lesz szó.
Emlékszel a szervletekre és a szűrőkre? Miért volt szükség szűrőkre, és még külön interfészekkel is, ha valójában ugyanaz a logika megvalósítható servletekkel?
A szűrők (szolgáltatási szervletek) koncepciójának feltalálása tette lehetővé a különböző szolgáltatási funkciók külön rétegbe helyezését. És a jövőben a szűrők viselkedésének megváltoztatásakor nem kellett módosítani a servleteket.
A szűrők feltalálása előtt a kérések átirányításáért felelős összes szolgáltatási logika magukban a szervletekben volt. És gyakran egy apró logika változtatás ahhoz vezet, hogy végig kell menni az összes szervleten, és mindegyiken különféle változtatásokat kell végrehajtani.
Tesztelhetőség
Ha Ön Java háttérfejlesztő, akkor a kiszolgálóalkalmazások gyakran REST API-ként tesznek közzé metódusokat. És annak ellenőrzéséhez, hogy minden módszere megfelelően működik-e, tesztekkel kell lefedni őket.
Általában az API-teszt lefedettsége jó stílus. Lehetővé teszi, hogy megbizonyosodjon arról, hogy az API valóban azt csinálja, amire szánták. És ami még fontosabb, módosíthatja a szerver logikáját, és egyszerűen ellenőrizheti, hogy nem tört-e el véletlenül semmit .
Amint elkezdi a teszteket írni, rájön, hogy a legtöbb kód egyáltalán nem tesztelhető: privát módszerek, erős csatolás, statikus osztályok és változók.
„Miért van szükségünk tesztekre, ha a kód működik?” – teszi fel a kérdést a kezdő.
„Miért van szükségünk működő kódra, ha nem tesztelhető?” – teszi fel a kérdést a szakember.
A könnyen tesztelhető kód kevesebb hibát tartalmaz, és megbízhatóbb lesz. De a tesztek nem csak a kód minőségét javítják. Majdnem minden fejlesztő végül arra a következtetésre jut, hogy a „jó tesztelhetőség” követelménye egyúttal olyan irányadó erő is, amely automatikusan jó tervezéshez vezet.
Íme egy idézet az Ideal Architecture című könyvből: „Használja egy osztály „tesztelhetőségének” elvét a jó osztálytervezés „lakmusz tesztjeként”. Még ha nem is ír egy sor tesztkódot, válaszoljon erre a kérdésre 90-ben. Az esetek %-a segít megérteni, hogy a tervezése mennyire jó" vagy "rossz".
A teszteken alapuló programok fejlesztésére egy teljes módszertan létezik, amelyet tesztvezérelt fejlesztésnek (TDD) hívnak. Ez természetesen a másik véglet: írjon kódot, mielőtt kódot írna.
Kód karbantarthatósága
Általában nagyon sokan dolgoznak a programon – vannak, akik elmennek, újak jönnek. Egy programozó átlagos munkaideje egy informatikai cégnél másfél év. Tehát ha egy 5 éves projekthez érkezett, akkor a kollégáinak mindössze 20%-a dolgozott azon a kezdetektől fogva.
A mások által írt program fenntartása és fejlesztése nagyon nehéz. Még akkor is, ha a program már meg van írva, gyakran szükséges folytatni a karbantartást: javítani a hibákat és elvégezni a kisebb javításokat. És ezt gyakran olyan embereknek kell megtenniük, akik nem vettek részt az írásban.
Ezért egy jó architektúrának viszonylag könnyen és gyorsan kell tudnia az új emberek számára a rendszer megértését . A projektnek a következőnek kell lennie:
- Jól felépített.
- Ne tartalmazzon ismétlődést.
- Jól formázott kód legyen.
- Kívánatos dokumentációt mellékelni.
- A programozók számára szabványos és megszokott megoldásokat kell alkalmazni.
Könnyedén értékelheti a projektet, amelyen dolgozik, egy 5 fokú skálán . E követelmények mindegyikéhez csak két pontot kell számolni . És ha 5-öt vagy többet kap, akkor szerencsés.
A programozóknak még a legkisebb meglepetés elve is érvényesül : minél egzotikusabb a rendszer, mások számára annál nehezebb megérteni. Általában a felhasználói felülettel kapcsolatban használják, de alkalmazható kódírásra is.
GO TO FULL VERSION