Hogyan programozzák a körülmények összefolyását, Andrew Hunt
Hogyan programozzon véletlen egybe
Tegyük fel, hogy Fred feladata egy program írása. Fred csinál egy programot, megpróbálja futtatni, és úgy tűnik, hogy működik. Fred ír egy másik darabot, megpróbálja elindítani, és újra minden működik. Ebben a helyzetben még néhány hét telik el, de hirtelen a program abbahagyja a munkát, és miután több órát töltött a hiba megszüntetésével, Fred még mindig nem tudja, mi az oka. Fred sok időt tölthet ebbe a töredékbe, anélkül, hogy kilábalhatná a programot. És bármit is tesz, úgy tűnik, hogy a program soha nem fog megfelelően működni.
Fred nem tudja, miért bukik el a program, mert nem tudja, miért dolgozott az elején. Úgy tűnt, hogy a korlátozott "tesztelés" körülményei között működik, amelyet Fred vezetett, de ez csak véletlen volt. A hamis bizalom fogságában Fred elfeledkezett. A legtöbb értelmiségi ismerős Fred képével, de jobban ismerjük őt. Nem hivatkozunk a véletlenre, ugye?
Azonban néha támaszkodunk. Néha könnyű összezavarni egy boldog eseményt célzott tervezéssel. Nézzünk néhány példát.
A véletlenszerű megvalósítás valami, ami egyszerűen azért következik be, mert a program pontosan meg van írva, ahogy írták. Ha nem dokumentált hiba vagy határfeltételek támaszkodik, akkor nem működik.
Úgy tűnik, hogy Fred kétségbeesett kísérletekkel próbál valamit hozni a képernyőre. De ezek a szubrutinok nem úgy lettek kialakítva, hogy ilyen módon hozzáférjenek; bár úgy tűnik, hogy működik, valójában ez csak véletlen egybeesés.
Annak érdekében, hogy ne kapjon új találatokat, amikor a komponens még mindig rajzolódik, Fred nem próbál visszamenni, és megszünteti a hamis kéréseket. "Most működik, hagyjuk abba ...".
Az ilyen gondolatok vezethetnek tévedésben. Miért kockáztatják, elrontsák, mi működik? Így több okból is gondolhatsz:
• A program valóban nem működik, csak úgy tűnik, hogy működik.
• A határfeltétel, amelyre támaszkodhat, csak egy adott eset lehet. Különböző körülmények között (például eltérő képernyőfelbontással) a program másképp viselkedhet.
• A nem dokumentált viselkedés megváltozhat a könyvtár új verziójának kiadásával.
• A kiegészítő és opcionális hívások lassítják a programot.
• A további hívások növelik a hívásokhoz kapcsolódó új hibák bevezetésének kockázatát.
Más fejlesztők által meghirdetett program írásakor hasznos lehet a világos modularizáció és az egyszerű, jól dokumentált interfészek elrejtésének alapelve. Egy egyértelműen meghatározott szerződés (lásd "Szerződéstervezés") kiküszöbölheti a félreértéseket.
Az alprogramokra, amelyeket hívsz, csak a dokumentált viselkedésre támaszkodj. Ha valamilyen okból nem teheti ezt meg, akkor egyértelműen dokumentálja a feltételezést.
Ön is találkozhat egy "véletlen kontextusban". Tegyük fel, hogy egy szervizmodult ír. Mert ebben a pillanatban egy programot írsz a grafikus környezethez, ha a modul a meglévő grafikus felületre támaszkodik? Ön az angol nyelvű felhasználókra támaszkodik? Az írástudók számára? Még mindig támaszkodik bizonyos kontextusokra, amelyek jelenléte nem garantált?
A véletlen egyáltalán félrevezető lehet minden szinten - a követelményektől a tesztelésig. A tesztelés különösen tele van hamis oksági kapcsolatok jelenlétével és az eredmények véletlen egybeesésében. Könnyű azt feltételezni, hogy A hívja az U-t, de amint az a "Debugging" szakaszban szerepel, ezt nem feltételezi, de bizonyítani tudja.
Minden szinten az emberek dolgoznak, mivel számos feltevést tartanak a fejében, de ritkán dokumentáltak és gyakran ellentmondást okoznak a fejlesztők között. Az olyan feltételezések, amelyek nem alapulnak ismert tényeken, megmérgezhetik a projekteket.
Tipp 44: Ne írjon programokat a körülmények egybeesésének számbavételével