A rossz szoftverarchitektúra kritériumai

A rossz tervezés kritériumai

Az élet egyszerűen működik: gyakran ahhoz, hogy okos legyél, nem kell hülyeségeket csinálni. Ez vonatkozik a szoftverfejlesztésre is: a legtöbb esetben ahhoz, hogy valamit jól csináljunk, csak nem kell rosszul csinálni.

A legtöbb programozónak van tapasztalata a rendszer rosszul megtervezett részeivel kapcsolatban. De még szomorúbb, hogy a legtöbben átélik azt a szomorú élményt, amikor ráébrednek, hogy ti vagytok egy ilyen rendszer szerzői. A legjobbat akartuk, de úgy sikerült, mint mindig.

A legtöbb fejlesztő nem törekszik rossz architektúrára, és sok rendszer esetében eljön az a pont, amikor azt kezdik mondani, hogy az architektúrája szörnyű. Miért történik ez? Az építészeti tervezés kezdettől fogva rossz volt, vagy idővel rossz lett?

A probléma gyökere a „rossz” tervezés definíciójának hiánya.

Számomra úgy tűnik, hogy minden programozó számára a tervezés minőségének megértése és „romlása” okai a legfontosabb tulajdonságok. Mint a legtöbb esetben, itt is a probléma azonosítása a legfontosabb, és a megoldás technológia kérdése.

A „rossz tervezés” meghatározása

Ha úgy dönt, hogy dicsekedni kezd a kódjával egy programozótársa előtt, nagy valószínűséggel nevetségessé válik a válasz: „Ki csinálja ezt?”, „Miért van ez így?” és „másképp csinálnám a dolgokat”. Ez nagyon gyakran előfordul.

Minden ember más, de a kódot továbbra is programozótársaidnak írod, így az egyes funkciók fejlesztése során mindig szükséged van egy felülvizsgálati fázisra, amikor mások megnézik a kódodat.

De még akkor is, ha sok mindent meg lehet csinálni különböző módon, vannak olyan kritériumok, amelyekben minden fejlesztő egyetért. Bármely kódrészlet, amely megfelel a követelményeknek, de egy (vagy több) jellemzőt mutat, rossz tervezés.

Rossz dizájn:

• Nehéz megváltoztatni, mert minden változás a rendszer túl sok más részét érinti. ( Merevség , merevség).
• Változások végrehajtásakor a rendszer többi része váratlanul meghibásodik. ( Fragility , Fragility).
• A kódot nehéz újra felhasználni egy másik alkalmazásban, mert túl nehéz eltávolítani az aktuális alkalmazásból. ( Mozdulatlanság , Mozdulatlanság).

A vicces pedig az, hogy a rendszerből szinte lehetetlen olyan darabot találni , ami nem tartalmazza ezeket a tulajdonságokat (vagyis rugalmas, megbízható és újrahasznosítható), megfelel a követelménynek, ugyanakkor rossz a kialakítása. .

Így e három jellemző segítségével egyértelműen meghatározhatjuk, hogy egy terv „rossz” vagy „jó”.

A "rossz tervezés" okai

Mitől merev, törékeny és mozdíthatatlan egy design? A modulok merev kölcsönös függése.

Egy terv merev, ha nem lehet könnyen megváltoztatni. Ez a merevség annak a ténynek köszönhető, hogy egy szövött rendszerben egyetlen kódrészlet változtatása lépcsőzetes változásokat eredményez a függő modulokban. Ez mindig megtörténik, amikor egy személy dolgozik a kódon.

Ez azonnal megnehezíti a teljes kereskedelmi fejlesztési folyamatot: amikor a lépcsőzetes változtatások számát a tervező vagy a fejlesztő nem tudja előre megjósolni, lehetetlen megbecsülni egy ilyen változás hatását. Ezért az ilyen változtatásokat a végtelenségig próbálják elhalasztani.

Ez pedig kiszámíthatatlanná teszi a változtatás költségeit. Ilyen bizonytalansággal szembesülve a vezetők vonakodnak a változtatásoktól, ezért a terv hivatalosan merevvé válik.

A projekt egy bizonyos ponton áthalad az „eseményhorizonton”, és arra van ítélve, hogy a merev építészet „fekete lyukába” essen.

A törékenység a rendszer azon tendenciája, hogy egyetlen változás után több helyen is tönkremegy. Általában olyan helyeken jelentkeznek új problémák, amelyek fogalmilag nem kapcsolódnak a változás helyéhez. Az ilyen törékenység súlyosan aláássa a rendszer tervezésébe és karbantartásába vetett bizalmat.

Általában ez volt a helyzet, amikor nem voltak magán módszerek. Elég, ha minden módszert nyilvánossá tesz, és egy törékeny architektúra megjelenésére lesz ítélve. A kapszulázás mikroszinten segít ennek kezelésében. De makroszinten moduláris architektúrára van szükség.

Ha egy projekt törékeny architektúrával rendelkezik, a fejlesztők nem tudják garantálni a termék minőségét.

Az alkalmazás egyik részének egyszerű módosításai hibákhoz vezetnek más, nem kapcsolódó részekben. Ezeknek a hibáknak a kijavítása még több problémához vezet, és a kísérési folyamat egy híres kutyává válik, aki a saját farkát kergeti.

A kialakítás mozdulatlan , ha a rendszer szükséges részei erősen kötődnek más nem kívánt részletekhez. Túl sok a saját kódjuk, a saját egyedi megközelítéseik és megoldásaik.

Emlékszel a JUL loggerre, amelynek fejlesztői minden jó ok nélkül kitalálták a saját naplózási szinteiket? Ez csak a helyzet.

Ahhoz, hogy a tervező képet kapjon arról, milyen egyszerű egy meglévő terv újrafelhasználása, elég csak arra gondolni, hogy mennyire lesz egyszerű használni egy új alkalmazásban.

Ha a tervezés szorosan össze van kötve, akkor ez a tervező megrémül attól, hogy mekkora munkára van szükség ahhoz, hogy a rendszer szükséges részeit elkülönítse a felesleges részletektől. A legtöbb esetben egy ilyen kialakítás nem használható újra, mivel a szétválasztás költsége meghaladja a nulláról történő fejlesztést.

Relevancia

Minden változik, de minden marad a régiben. (kínai közmondás)

Nagyon jó kérdéseket tettek fel fent. Melyek a törékeny és merev rendszerek veszélyei? Igen, mert egy ilyen projekt menedzselésének folyamata kiszámíthatatlanná és ellenőrizhetetlenné válik. Az ára pedig borzasztó.

Hogyan adhatja vagy nem adhatja meg a menedzser engedélyt valamilyen funkció hozzáadására, ha nem tudja, hogy ez valójában mennyi időt vesz igénybe? Hogyan rangsoroljuk a feladatokat, ha nem tudjuk megfelelően megbecsülni a végrehajtásuk idejét és összetettségét?

És hogyan fizethetik ki a fejlesztők ugyanazt a technikai adósságot, amikor mi rake-elni fogjuk, és nem értjük, mennyit rakunk addig, amíg nem rakunk?

A kód újrafelhasználásával vagy tesztelésével kapcsolatos problémák szintén nagyon fontosak. Az egységtesztek nemcsak a vizsgált egységgel kapcsolatos egyes feltételezések tesztelésére szolgálnak, hanem a kohézió mértékének meghatározására is, és az újrahasználat indikátoraként szolgálhatnak.

Íme egy idézet Bob Martintól erre az esetre: „Ahhoz, hogy újra felhasználhassa a kódot, kevesebb erőfeszítést kell tennie annak újrafelhasználására, mint amennyibe kerülne az újbóli fejlesztés . ” Ellenkező esetben senki sem fog foglalkozni ezzel az üggyel.

A tervezési elvek és minták egy célt szolgálnak - a tervezést jóvá tenni. Ha a használatuk nem ad semmilyen hasznot (vagy fordítva, sérti a „jó tervezés” elveit), akkor valami nem stimmel a télikertben, és talán az eszközt más célokra kezdték használni.