---
title: Szoftverfejlesztési törvények
category: concept
sources:
- https://lawsofsoftwareengineering.com/
created: 2026-04-22
updated: '2026-09-26'
tags:
- szoftverfejlesztés
- architektúra
- csapatok
- minőség
- skálázás
- döntéshozatal
- tervezés
confidence: high
summary: '56 szoftverfejlesztési törvény és elv gyűjteménye: architektúra, csapatok,
  tervezés, minőség, skálázás, tervezési elvek, döntéshozatal'
---

## 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ó](../topics/ai-automation.md) — 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.