Szoftverfejlesztési törvények
Architektúra¶
| Törvény | Lényeg |
|---|---|
| Conway törvénye | A szervezetek a kommunikációs szerkezetüket tükröző rendszereket terveznek |
| Hyrum törvénye | Elegendő API-felhasználó esetén minden megfigyelhető viselkedés függőséggé válik |
| Gall törvénye | A komplex működő rendszerek egyszerű működő rendszerekből fejlődnek ki |
| Szivárgó absztrakciók törvénye | Minden nem-triviális absztrakció szivárog valamilyen mértékben |
| Tesler törvénye | A komplexitás csak áthelyezhető, nem szüntethető meg |
| CAP-tétel | Az elosztott rendszer a konzisztencia, elérhetőség és partíciótűrés közül csak kettőt garantálhat |
| Második rendszer effektus | A sikeres kis rendszereket túltervezett utódok követik |
| Az elosztott számítástechnika tévedései | Nyolc hamis feltevés, amit az elosztott rendszerek tervezői tesznek |
| Nem szándékolt következmények törvénye | A komplex rendszerek változtatása meglepetéseket hoz |
| Zawinski törvénye | Minden program addig növekszik, míg levelet nem tud olvasni |
Csapatok¶
| Törvény | Lényeg |
|---|---|
| Brooks törvénye | A késésben lévő projekthez adott ember csak tovább késlelteti |
| Dunbar-szám | ~150 stabil kapcsolat a kognitív határ |
| Ringelmann-effektus | Az egyéni termelékenység csökken a csoportméret növekedésével |
| Price törvénye | A résztvevők négyzetgyöke végzi a munka 50%-át |
| Putt törvénye | Aki érti a technológiát, nem vezeti; aki vezeti, nem érti |
| Peter-elv | Az alkalmazottak az inkompetenciaszintjükig emelkednek |
| Buszfaktor | Hány ember elvesztése sodorná veszélybe a projektet |
| Dilbert-elv | A cégek az inkompetens alkalmazottakat vezetői pozícióba léptetik |
Tervezés¶
| Törvény | Lényeg |
|---|---|
| Korai optimalizálás (Knuth) | Minden rossz gyökere |
| YAGNI | Ne adj hozzá funkciót, amíg nem szükséges |
| Parkinson törvénye | A munka kitölti a rendelkezésre álló időt |
| Kilencven-kilencven szabály | Az első 90% = az idő 90%-a; a maradék 10% = a másik 90% |
| Hofstadter törvénye | Mindig tovább tart a vártnál, még ezt a törvényt is beszámítva |
| Goodhart törvénye | Ha egy mérőszám célponttá válik, megszűnik jó mérőszám lenni |
| Gilb törvénye | Bármi, amit mennyiségileg kell mérni, mérhető |
Minőség¶
| Törvény | Lényeg |
|---|---|
| Cserkész-szabály | Hagyd jobban a kódot, mint ahogy találtad |
| Murphy törvénye | Ami elromolhat, az el is romlik |
| Postel törvénye | Konzervatív légy abban, amit csinálsz; liberális abban, amit elfogadsz |
| Törött ablakok elmélete | Ne hagyd megjavítatlanul a "törött ablakokat" |
| Technikai adósság | Minden, ami lelassít a fejlesztésben |
| Linus törvénye | Elég sok szemmel minden bug sekély |
| Kernighan törvénye | A hibakeresés kétszer olyan nehéz, mint a kódírás |
| Tesztelési piramis | Sok gyors unit teszt, kevesebb integrációs, minimális UI teszt |
| Peszticid-paradoxon | Ugyanazon tesztek ismétlése idővel kevésbé hatékony |
| Lehman törvényei | A valóságot tükröző szoftvernek evolúálnia kell |
| Sturgeon törvénye | Mindennek a 90%-a hulladék |
Skálázás¶
| Törvény | Lényeg |
|---|---|
| Amdahl törvénye | A párhuzamosítás gyorsulása korlátozott a nem-párhuzamosítható rész által |
| Gustafson törvénye | Nagyobb problémamérettel jelentős gyorsulás érhető el párhuzamosítással |
| Metcalfe törvénye | A hálózat értéke a felhasználók számának négyzetével arányos |
Tervezési elvek¶
| Törvény | Lényeg |
|---|---|
| DRY | Minden tudásnak egyetlen, egyértelmű reprezentációja legyen |
| KISS | A lehető legegyszerűbb |
| SOLID | Öt fő irányelv a karbantartható és skálázható kódhoz |
| Demeter törvénye | Egy objektum csak közvetlen barátaival kommunikáljon |
| Legkevesebb meglepetés elve | A szoftver úgy viselkedjen, hogy a legkevésbé lepje meg |
Döntéshozatal¶
| Törvény | Lényeg |
|---|---|
| Dunning–Kruger-hatás | Minél kevesebbet tudsz valamiről, annál magabiztosabb vagy |
| Hanlon borotvája | Soha ne tulajdoníts gonoszságot annak, amit butasággal is megmagyarázhatsz |
| Occam borotvája | A legegyszerűbb magyarázat a legpontosabb |
| Elsüllyedt költségek tévedése | Ne ragaszkodj a döntéshez csak azért, mert már befektettél |
| A térkép nem a terület | A valóság reprezentációja nem egyenlő a valósággal |
| Megerősítéses torzítás | A meglévő hiedelmeidet megerősítő információkat favorizálod |
| Amara törvénye (Hype ciklus) | Rövid távon túlbecsüljük, hosszú távon alábecsüljük a technológia hatását |
| Lindy-hatás | Minél tovább használnak valamit, annál valószínűbb, hogy tovább is fogják |
| Első elvek gondolkodás | Bontsd alapvető építőkövekre, majd építs fel onnan |
| Inverzió | Oldd meg a problémát az ellenkező irányból |
| Pareto-elv (80/20 szabály) | A problémák 80%-a 20% okból származik |
| Cunningham törvénye | Az interneten a legjobb mód a helyes válaszhoz: téves választ írni |
Kapcsolódó témák¶
- AI és automatizáció — vibe kódolás, agent gazdaság
- Szoftverfejlesztés — architektúra, minőség, skálázás
Forrás¶
- Weboldal: Laws of Software Engineering
- Link: https://lawsofsoftwareengineering.com/
- Törvények száma: 56
- Kategóriák: Architecture, Teams, Planning, Quality, Scale, Design, Decisions
- Feldolgozva: 2026. április 22.