A Clean Code elvei segítenek a kód tisztaságának, érthetőségének és karbantarthatóságának biztosításában. Íme a KISS, DRY, YAGNI és SOLID szabályok rövid magyarázata:
KISS (Keep It Simple, Stupid)
Az egyszerűség fenntartása érdekében arra kell törekedni, hogy a kód ne legyen bonyolultabb a szükségesnél. Az egyszerűség megkönnyíti a hibakeresést, a tesztelést és az új fejlesztéseket. Ha egy probléma egyszerűen megoldható, kerüljük a túlbonyolított megközelítéseket, például ne készítsünk túl sok réteget egy egyszerű funkcionalitás megvalósításához.
DRY (Don’t Repeat Yourself)
Kerüljük a kódismétlést azáltal, hogy közös kódrészleteket központosítunk, például funkciókba, osztályokba vagy modulokba. Az ismétlés nélküli kód könnyebben karbantartható, és a változtatások csak egy helyen szükségesek. Ha egy azonos logikát többször használsz különböző helyeken, érdemes azt egy külön függvénybe helyezni, így ha változtatás szükséges, csak egy helyen kell módosítani.
YAGNI (You Aren’t Gonna Need It)
Ne hozzunk létre olyan funkciókat vagy bonyolult logikát, amelyekre az aktuális igények szerint valójában nincs szükség. A jövőbeni igényekre való túlzott előre tervezés időpocsékolás lehet. Ha nem biztos, hogy egy adott funkcionalitásra szükség lesz a jövőben, ne fejlesszük le előre. Ha mégis szükség lesz rá, akkor hozzáadhatjuk később.
SOLID
A SOLID öt, egymással összefüggő objektum‑orientált tervezési alapelv rövidítése. Céljuk a rugalmas, karbantartható, újrafelhasználható és tesztelhető kód létrehozása.
1. Single Responsibility Principle (SRP) – Egyetlen felelősség elve
- Jelentés: Egy osztálynak (vagy függvénynek) egyetlen oka legyen a változásra, azaz egyetlen jól definiált feladata legyen.
- Példa: Ha van egy
Userosztályod, akkor ne abban kezeld az email küldést vagy az adatbázis-mentést is, hanem ezek külön osztályokba kerüljenek.
2. Open/Closed Principle (OCP) – Nyílt/zárt elv
- Jelentés: A szoftvered legyen nyitott a bővítésre, de zárt a módosításra. Azaz a meglévő kódodat ne kelljen mindig átírni ahhoz, hogy új funkciókat adj hozzá.
- Példa: Ha egy fizetési rendszert tervezel, ne írj külön logikát minden új fizetési módhoz a már meglévő metódusban, hanem használj interfészeket és implementációkat, így könnyen bővítheted új fizetési típusokkal anélkül, hogy a meglévő kódhoz nyúlnál.
3. Liskov Substitution Principle (LSP) – Liskov-féle helyettesítési elv
- Jelentés: Egy alosztálynak mindig használhatónak kell lennie az őt helyettesítő szülő osztály helyén, anélkül, hogy ez problémát okozna.
- Példa: Van egy
Bird(madár) osztályod. Ha van belőle származóPenguin(pingvin) osztály, amely nem tud repülni, akkor ne kényszerítsd arra, hogy repülős függvényeket örököljön. Inkább tervezz másként, például különítsd el a repülés képességét.
4. Interface Segregation Principle (ISP) – Interfész szétválasztásának elve
- Jelentés: Több specifikus interfész használata jobb, mint egyetlen általános, nagyméretű interfész.
- Példa: Ha van egy nagy
Printerinterfészed, ami tud nyomtatni, faxolni és scannelni is, de egy egyszerű nyomtatónak nem kell faxolni vagy scannelni, akkor szedd szét kisebb interfészekre (példáulPrintable,Faxable,Scannable), így csak azokat kell implementálnia, amikre ténylegesen szüksége van.
5. Dependency Inversion Principle (DIP) – Függőség megfordításának elve
- Jelentés: Magas szintű modulok ne függjenek közvetlenül alacsonyabb szintű moduloktól, hanem absztrakciókon (interfészeken vagy absztrakt osztályokon) keresztül kapcsolódjanak egymáshoz.
- Példa: Egy webshopban ne közvetlenül az adatbázis implementációját használd egy rendelés kezelésére, hanem egy interfészt (
OrderRepository) definiálj, aminek a konkrét adatbázis csak egy implementációja lesz. Így könnyen cserélheted például az adatbázis típust vagy akár mock adatokat használhatsz teszteléshez.
A SOLID szabályok betartásával a kódod tiszta, könnyen érthető, könnyen tesztelhető, és egyszerűbben módosítható lesz hosszú távon.