[OSy] Prubeh studie

[martinec]

Dobry den,

shrnuju, jak probiha studie.

Prubezne vysledky:

Z doposud vyplnenych zaznamu (nedele vecer) je videt, ze nejcastejsi 
chybou (30%) je zapomenuti napsat nejakou implementaci. Nicmene tento 
druh chyb nevypada, ze by byl casove narocny na odladeni. Zabira zhruba 
7% doby ladeni.

Myslim, ze vysoky vyskyt teto chyby se da vysvetlit tim, jakym zpusobem 
probiha vyvoj. Semestralka OSu je totiz specificka tim, ze casto jeden 
clen tymu implementuje kod, ktery jde primo spustit/testovat, a ostatni 
clenove dlouho pisi kod bez moznosti integrace do stavajiciho kernelu. 
Domnivam se, ze v teto situaci je caste, ze se zapomina na jednotlive 
kousky implementace. Jestli si nekdo uvedomujete duvod, proc jsou ty 
chyby tak caste, tak budu rad, kdyz mi to napisete.

Asi je prekvapive, ze nejdele trva odladit logicke/navrhove chyby (~45% 
doby ladeni), prestoze je jich co do poctu okolo jedne petiny. Na 
oduvodneni, proc tomu tak je, si zatim netroufam odhadnout.

Bohuzel absolutni hodnota prumerneho casu vyvoje semestralky neni 
relevantni, protoze se vsichni neucastni studie rovnomerne. Mozna pro 
Vas budou zajimave aspon statistiky tech, kteri se ucastni aktivne:

Median development time od zacatku studie: 23h 40m
Maximum tehoz: 70h
Minimum tehoz: 19h
Nejdelsi doba ladeni: 6h 30m, wrong assumption how software works; po 
diskuzi s autorem jsem zjistil, ze si vyrobil heap corruption

Prumerna doba ladeni zatim asi nema smysl, protoze nekteri z vas se 
poradne k ladeni asi jeste nedostali.

Metodologie:

Budu se snazit dostat se brzy k zaznamum, ktere jste oznacili k review.

Diskutoval jsem uz s dvema tymy, jakym zpusobem vyvijeji a zaznamenavaji 
chyby. Shrnuju nejdulezitejsi poznatky:

- ladeni ve vice lidech
Kdyz ladite chybu ve vice lidech, tak kazdy udelejte zaznam o chybe. Cas 
ladeni napiste kazdy jednotlive za sebe a v pricine chyby by jste se 
meli shodovat. Zaskrtnete flag debugged by more people (ktery je zatim 
ponekud nesystematicky v root cause zalozce).

- memory corruption
Po nejakem popremysleni se domnivam, ze tyto root cause budou asi velmi 
ojedinele. Totiz malokdy bude asi heap corruption root cause problemu. 
Ale myslim, ze pokud nejaka root cause zpusobi korupci pameti, tak to 
snadno muze mit vyrazny vliv na dobu ladeni. Proto by se tato 
"mezichyba" nemela zanedbavat. Udelal jsem tedy k root cause flag 
"memory corruption related".

Prosim tedy, abyste jste pri zaznamenani uvazili, jestli napriklad heap 
corruption je skutecny zdroj problemu. A v obou pripadech zaskrtnete 
flag "memory corruption related".

- kdy nezaznamenavat
Mozna, ze jsem na cviceni rikal vagne, ze zaznamenavat se nema pri 
implementaci. Plati obecne pravidlo, ze zaznamenavat se ma, kdyz se 
program chova jinak nez jste si mysleli. Tedy napriklad pokud jste svuj 
kod spustili (treba i na vyzkouseni funkcnosti kodu, ktery je ve stavu 
uprostred implementace) a on se chova spatne/divne, tak uz objasnujete 
neocekavane chovani.

Jako priklad kdy nezaznamenavat lze uvazovat situaci, kdy si kod po sobe 
jeste jednou prectete nez ho spustite a najdete chybu. Kdyby jste nekdo 
mel pocit, ze jste to delal spatne a ze vam nejake chyby utekly, tak mi 
dejte vedet, abych si to poznacil.

Technicka podpora:

Nejaky cas mi zatim zabrala podpora MSIM debugger. Objevilo se nekolik 
chyb a ty nejdulezitejsi snad brzo opravim. Debugger je ale v tuto 
chvili pouzitelny a pokud vim, tak ho pouzivaji aspon dva lide.

Upravil jsem take webove rozhrani. Asi nejdulezitejsim pridavkem je 
moznost zobrazit seznam vyplnenych zaznamu o chybach. Pripravuju jeste 
pohled na detaily jednotlivych zaznamu.

S pozdravem,
Tomas Martinec