Ú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.
-
"engem kizárólag az érdekel, hogy mitől lehetek biztos benne, hogy ugyanebbe a hibaosztályba tartozó hibát nem követnek el mégegyszer"
mivel programozas kurzusokrol beszelsz, gondolom infos?villanyos?mernok hattered van, akkor pedig gondolom a megallasi problemarol hallottal. ami egy eldonthetetlen problema. na, az "adott tipusu hiba nincs a programban" pontosan ilyen eldonthetetlen hiba, a megallasi problemara visszavezethetoen. szoval nem lehetsz benne biztos.
amit lehet csinalni, az az, hogy a programozok csinalnak egy megfelelo coverageju tesztet, ami ugyan meg mindig csak akkor szuri ki a hibat, ha failure szintig propagal, meg ugye ebben is lehet hiba, meg draga, de ugy legalabb ott van a report, hogy adott dolgokat megneztuk, es nem fordulhatnak elo. repulesben pl MCDC a standard, ott se neznek meg minden esetet (gyakorlati kivitelezhetoseg miatt).
pelda:
if (x == 0){
... // do something
} else if (x == 0) {
... // nasty bug happens here
}namost, a masodik ifnel hiaba ott a hiba, amig az elso if ott van, addig sose fog propagalni, hiszen az adott kodresz nem fut le.
coding style meg szep es jo, de altalanos esetben hibak ellen nem ved. peer review ugyanigy nem jo szisztematikus minosegellenorzesre. teszteles igen. viszont a teszteles eroforrasigenyes (mostanaban 50% folotti szamokat is hallottam mar koltsegre projekten belul, ez kritikus rendszereknel joval magasabb), itt meg egy open source projektrol beszelunk, tehat tippre szivszerelembol, szabadidoben fejlesztettek.
valamint felmerul a vegtelenul kinos kerdes, hogy ha ennyien hasznaltak, miert csak par cegnek jutott eszebe vegigtesztelni, ha ennyire fontos cucc volt. es ha megfogtak a hibat par helyen, miert nem szoltak vissza az OO projektnek, hogy baj van?
egyebkent minosegellenorzes programoknal egyre fontosabb szoftverfejlesztes eseten, tehat a dolgok tortennek. ez a bug pedig remek szemlelteto pelda arra, hogy miert nem eleg a peer review. kovetkezmenyei a dolognak biztosan lesznek, viszont rahuzni a programozora a vizes lepedot nem megoldas, ld az indoklas feljebb.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
hibaosztaly alatt szerintem teljesen mas dolgokat ertunk
es itt jon akkor a radikalis velemeny: tehat van egy szarmaztatott ertek ami inkonzisztens lehet, 20 eve ismert problema, 20 eve vetik el, akkor szerintem ezt programnyelvi szinten kene kezelni.
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.
