Skip to content

Kategória: Elvek

Don´t Repeat Yourself (DRY)

Miért?
A kód, illetve a mozdulatok minden megduplázása az inkonzisztenciához vezető úton visz tovább.

A DRY-elv így hangzik: Don’t Repeat Yourself – Ne ismételd magad. A szoftverfejlesztés őskora óta érvényes, különben nem volnának alprogramok, nem volna adatnormalizálás. Ennek ellenére valószínűleg a leggyakrabban figyelmen kívül hagyott elv. Hiszen mi sem egyszerűbb annál, hogy Copy-Paste-tel kódot ismételjünk. Éppen, amikor gyorsan kell valaminek elkészülnie, történik ez meg gyakran.

A piros fokozatú Clean Code fejlesztők tehát éppen ennek az elvnek a betartásában gyakorolják magukat. Tudatosak, amikor kódot vagy egyéb eszközt ismételnek, Felismerik az olyan ismétléseket, amelyeket ők maguk vagy mások követtek el. Megtisztítják az ismétlődéseket refaktorálással – ha nem szól ellene egyéb elv vagy korlátozás.

Keep it simple, stupid (KISS)

Miért?
Aki többet tesz, mint a legszükségesebbet, az megváratja a megrendelőt és a megoldást feleslegesen komplikálttá teszi.

Vagy Albert Einstein szavaival élve: „Mindent olyan egyszerűre kell csinálni, amennyire csak lehet, de nem egyszerűbbre.” A kód továbbfejleszthetősége érdekében kényszerítő feltétel, hogy a kód érthető legyen. Ezért mindig egy tiszta és könnyen érthető megoldásra kell törekedni. Ha az ember a saját kódját rövid idő elteltével már nem érti meg, akkor már kongania kellene a vészharangnak. Még fontosabb azonban, hogy más fejlesztők is gyorsan értség meg a kódot. Ebben a rendszeres review-k és a páros programozás (pair programing) segítenek. Gondoskodnak annak az ellenőrzéséről, hogy valóban a legegyszerűbb megoldás valósult-e meg.Éppen a technikai részletekben rejlik annak a csábítása, hogy komplikált megoldást válasszunk. Az ismert, a kézenfekvő néha „unalmas” – és máris becsúszott egy komplikált megoldás. Ha az egyszerű megoldás működik, akkor azt kell előnyben részesíteni. Ugyanez érvényes az adatstruktúrákra is. Ha elegendő egy IEnumerable, akkor ne használjunk ICollection-t, és végképp ne IList-et.

Óvatosan az optimalizálással!

Miért?
Az optimalizálás mindig sok ráfordítást igényel. Aki ezzel óvatosan bánik, gyakran értékes erőforrásokat kímél annak érdekében, ami a megrendelőnek valóban hasznos.


M.A. Jackson:
Rules of Optimization:
Rule 1: Don’t do it.
Rule 2 (for experts only): Don’t do it yet.

More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity.

Mindig a kód érthetősége áll az előtérben. Az optimalizált kód azonban gyakran több, mint olvashatatlan. Amennyiben az abszolút szükségesre, a legrövidebb formában van egyszerűsítve, lehet, hogy kielégíti a megrendelő funkcionális és nem funkcionális követelményeit – de általában már nem tükrözi őket érthetően. Ez viszont kontraproduktív a szoftver leggyakrabban kívánt hosszú élettartama szempontjából. Donald Knuth már 1974-ben megírta: “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” (Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)

A cserkészszabályt tehát nem úgy kell érteni, hogy egyre csak újabb kódoptimalizálsra kell törekedni. Sokkal inkább az ellenkezőjére vonatkozik: Érthetőség és továbbfejleszthetőség.

Ha tehát a Clean Code fejlesztőnek bizseregnek az ujjai, mert azt hiszi, hogy még egy picike kis performanciát tudna kihozni egy kis optimalizálással, akkor legalább kétszer gondolja át azt. Egyik oldalon rontana az olvashatóságon, másik oldalon valószínű, hogy az ilyen optimalizálásra több ok miatt sincsen szükség. Amennyiben a performanciagond nem csak egy pontban észlelhető és nem egy különleges eset, akkor a következő refaktorálás valószínűleg úgyis gondoskodni fog erről, hiszen akkor egy alapvető strukturális gond az oka. Vagy a következő hardvergeneráció majd kiegyenesíti a performanciatörést. Vagy a megrendelőt nem is zavarja ez. Mindenképpen a megrendelőnek kell jeleznie az igényét az optimalizálásra. Ne hajtsunk végre kódváltoztatást anélkül, hogy a megrendelő ettől hasznot várna. Mert csak az olyat lesz majd hajlandó kifizetni.

Tehát annak a szabálynak, hogy kétség esetén az optimalizálás ellen kell dönteni, egy ennél még alapvetőbb szabály az alapja: YAGNI – You ain’t gonna need it. Ez azonban teljes mivoltában csak a kék fokozat eleme lesz.

PS: Amennyiben minden figyelmeztetés és megfontolás ellenére egy performanciaoptimalizálás éppen elengedhetetlenné válik, akkor mindig csak egy részletes (Profiler-rel történő) elemzés után kezdjünk hozzá. Mert csak az tudja egy optimalizálás alatt és után ellenőrizni, hogyan és mennyire sikeres az, aki előzőleg a Profiler-rel reprodukálható szűk keresztmetszetek helyét megállapította.

Favour Composition over Inheritance (FCoI)

Miért?
A kompozíció segíti egy rendszer laza csatolását (loose coupling) és tesztelhetőségét és gyakran rugalmasabb.

A funkcionalitások újrafelhasználhatósága érdekében az objektumorientált programozás (OOP) két ismert jelöltet nevez meg: A származtatást (whitebox – reuse) és a kompozíciót (blackbox – reuse). Amennyiben az ember egy osztály leszármaztatásával hasznosít funkcionalitásokat újra, akkor a leszármazott osztály függővé válik a szülőosztálytól. Ez egy rendszert sok esetben szükségtelenül komplexé, rosszabbul tesztelhetővé tesz, és megnehezíti a funkcionalitás kicserélését a futásidőben. A Clean Code fejlesztőnek a helyes származtatáshoz tehát a Liskov Substitution Prinziple (LSP) áll rendelkezésére, amelyet ilyenkor követni ildomos.

A kompozíciónál egy osztály egy másikat használ. Amennyiben ehhez egy világosan meghatározott interfészt használunk, akkor ez elősegíti a csatolások szétválasztását. A különböző implementációkat is könnyen lehet kicserélni. Tehát mielőtt az ember a Liskov Substitution-ba belekezd, a Favour Composition over Inheritance megköveteli, hogy feltegyük a kérdést, nem jobb-e a kompozíciót előnyben részesíteni.

Because inheritance exposes a subclass to details of its parent’s implementation, it’s often said that ‘inheritance breaks encapsulation“. (Gang of Four 1995:19)