Skip to content

Principle of Least Astonishment

Miért?
Amikor egy komponens meglepő módon másképpen viselkedik, mint ahogyan várnánk, akkor a felhasználása feleslegesen komplikált és nagy a valószínűsége a hibának.

A szoftverfejlesztés nagy mértékben kreatív folyamat. Ebben a folyamatban fontos az, hogy a belemerüljünk az áramlatba (flow). Amikor elértük ezt az állapotot, akkor a kód már csak úgy dőlni fog. Az áramlat (flow) minden nemű zavara csak megszakításokhoz és végeredményben ahhoz vezet, hogy a rendelkezésre álló időben csak kevés kód jön létre, illetve a kód minősége nem lesz optimális. Mert a fejlesztőnek minden megszakítás után fel kell vennie a fonalat, és újra bekerülnie az áramlatba (flow). A meglepetések zavarok. Megszakításokhoz és hibákhoz vezetnek. Erre egy példa: Amennyiben a fejlesztői környezet úgy van beállítva, hogy a szokásos Ctrl-C billentyűkombináció teljesen más jelentéssel bír, akkor ez akadályozza a fejlesztőt. A fejlesztő minden esetre bosszankodni fog, hogy a „rossz” billentyűkombinációt nyomta meg. Ez akadályozza a kreatív munkát.A szoftvereket a lehető legkevesebb meglepetéssel kellene implementálni. Amikor egy GetValue() nevű lekérdező eljárás nem csak egy értéket ad vissza, hanem egyben a rendszer állapotát is megváltoztatja, akkor a fejlesztő ezt az eljárást a legjobb esetben is elkerüli, mivel furcsa meglepetésekkel számol. Rossz esetben viszont nem tűnik fel neki a furcsa viselkedés időben. (Az olyan lekérdező eljárások, melyek megváltoztatják az állapotot megszegik a Command Query Separation elvet). A tesztvezérelt fejlesztés elősegíti a meglepetésekben szegény interfészek készítését, mivel az interfészt a felhasználásának szemszögéből tervezik és implementálják.

Published inElvek