Új hozzászólás Aktív témák
-
vagy csak siman tul keves/tul sok volt a kave, fel ora mulva zart a bolt, tul sokat kajalt a karacsonyi narancsos csokibol... emberek vagyunk es hibazunk.
a Cre hasonlatban azt szoktak mondani, hogy olyan mint egy motoros furesz: zsenialis celeszkoz, viszont nagyon konnyu vele hibazni, es jelenleg alapvetoen olyan dolgokra is hasznaljak mar, amire alapvetoen nem terveztek. gyakorlatilag nagyon low level, az usabilityje nem a legjobb par szempontbol (enged hibazni) es egy kisebb, mukodesbol adodo hiba katasztrofalis lehet. a memallokacio pedig tipikusan olyan dolog, amit nem veletlenul automatizaltak pl javaban, mert annyira konnyu elszurni es az elszurasnak altalaban katasztrofalis kovetkezmenyei vannak.
ne legyel mar paranoid, ez lehetsegesen egy kis programozoi hiba katasztrofalis kovetkezmenyekkel (ld a patkoszeg esete a haboruval analogiakent). ami viszont az ijeszto benne, hogy a "with enough eyesballs, all bugs are shallow" kijelentes erejet megkerdojelezi (cathedral and bazaar, nagyon sokat idezett cikk egyik alaptezise volt egyebkent, egyben a 2000es evek OSS mozgalmanak egyik fo erve). peer reviewvel nem lehet szisztematikusan vegignezni egy kod minden aspektusat (mert emberek vagyunk es hibazunk), tehat minosegbiztositasra a peer review nem eleg. mas kerdes, hogy jelenleg a jelenlegi FLOSS (free/libre/open-source software) egyre inkabb az innovacio/open standards/maintainability fele megy el. masik ijeszto, hogy egy ilyen kis hibanak ekkora eredmenye lehet (avagy a hasznalt eszkozok ekkora hibara hagynak lehetoseget).
ami sulyosabb dolog, hogy ez igy ilyen formaban atment a peer reviewen: de megint, emberek vagyunk. namost a peer review a legolcsobb es leggyengebb formaja a kod minosegenek megallapitasara (ami szerintem kiritikus rendszerekben semmit nem er, mert semmit nem mond a minosegrol). viszont szisztematikusan tesztelni (pl MCDC) nehezebb/sokkal dragabb, model checker / formalis bizonyitas pedig irdatlanul draga es altalanos esetben nagyon nehezen kivitelezheto.
megoldasok egyebkent a problemara latszanak, de coverage alapu tesztnel megint ott az emberi tenyezo, modelleknel / formal bizonyitasnal szinten. viszont igy belegondolva lehet az lesz az eredmeny, hogy FLOSS projekteknel is szigorubb processekre lesz szukseg, ugy viszont a contributorok vonzasa / megtartasa lesz problemas.
lehet mutogatni a programozora, de feleloskeresessel es boszorkanyuldozessel egy letezo problemat nem lehet megoldani. ez a cikk, pontosabban a lessonsok a vegen mar erdekesebbek, avagy a jovoben ilyen problemat hogy lehetne elkerulni. mert az nem allapot hogy egy ilyen apro banalis hibanak ekkora ara van. mert ez az egyesz lenyege, nem pedig az, hogy ki kovette el a hibat.
kicsit sok lett az angol kifejezes, de a magyar terminologiat nem ismerem
Geri Bátyó: csak az nem hibazik, aki nem csinal semmit. a kerdes itt nem az, hogy ki es miert hibazott, hanem hogy lehetne a jovoben hasonlo hibakat elkerulni.
azbest: igen, kb errol van szo.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
Új hozzászólás Aktív témák
it A nyílt projektben dolgozó német fejlesztő tagadja a szándékosságot, és egyszerű programozási hibáról beszél.
