Thread on suureks kasvanud, ma loodan, et keegi ei pahanda, kui ma samas 
kirjas mitmele inimesele vastan:

From: Tonis [mailto:tvaga@ut.ee]

>Huvitav kas Eestis on ka kuskil niimoodi asi toimib? Voibolla 
>suuremates
>firmades? Palju neid siinseid ülemusi on, kes koodi oskavad ja ka viitsivad 
>lugeda?

Mul on vinge ambitsioon Eestisse tagasi tulles selliseks ülemuseks hakata ;)

>  Samas selline koguaeg buildimine ja teiste koodi ülevaatamine votab 
>ju kovasti aega(lõbus on muidugi küll ;), eriti kui programmeerijaid 
>palju on ja projekt suur? Kui saab mingi tehnoloogia, naiteks COM abil, 
>ja funktsionaalses stiilis assertida, et miski tootab ja soltumatult 
>teistest komponentides tootab, siis oleks loomulik eraldi kirjutamine.

Ilma COMi (või mõne muu analoogse tehnoloogiata) oleks suurte projektide 
tegemine üldse võimatu (või vähemalt väga raske) ;)
Ja loomulikult seda ka siin majas rakendatakse ja kirjutatakse asju eraldi. 
Versioonikontrolli seisukohalt realiseeritakse seda nii, et projekti 
erinevate osade jaoks tehakse eraldi branchid, kus vastava ala tiimid oma 
arendust teevad, ja neid siis integreeritakse perioodiliselt põhibranchi. 
Selline lähenemisviis aitab kvaliteeti oluliselt tõsta, eriti, kui smoke 
teste teha nii enne kui ka pärast integratsiooni. Sellegipoolest on code review'd ja regulaarne kvaliteedikontroll kriitilise 
tähtsusega, sest kunagi ei ole võimalik vähegi suurema komponendi puhul 
absoluutselt täpselt kirjeldada, mida ta teeb, milliseid kõrvalefekte 
kaasa toob ja millist käitumist teistelt komponentidelt vaikimisi eeldab. 
Seda riski saab vähendada, kui üksikute komponentide koodi kvaliteet on 
võimalikult kõrge, ja siin aitavadki code review'd distsipliini 
säilitada. Igapäevane build on vajalik selleks, et kogu projekti kestel 
tagada, et komponendid koos normaalselt töötaksid. Kui selline 
integratsioon jätta projekti lõpufaasi, on praktiliselt garanteeritud, et 
rahvas veedab mitu lisakuud (kui üksikute komponentide kvaliteet on madal, 
siis võib juhtuda, et ei saagi valmis) üritades asja reaalselt käima 
saada.
Mul pole hetkel ruumi ega aega selle kohta põhjalikumaid näiteid tuua, aga 
sa leiad neid ohtralt Steve McConnelli raamatust 'Rapid Development'. Seni 
pead lihtsalt minu sõna uskuma, et kuigi sellised protseduurilised asjad 
võivad tunduda asjatu overheadina, tasuvad nad end lõpuks mitmekordselt 
ära.


From: Andres Soolo

>Siit ka minu ku"simus, kas too asi, mis ei ole CVS ega VSS, ei saa 
>hakkama mitme arendusthreadiga.

Selle asja nimi on Source Depot, ka siinsamas firmas tehtud, aga ei müüda, 
vaid kasutatakse ainult sisemiselt. Saab hakkama praktiliselt kõigega, mida 
sa suudad ette kujutada, paralleelsete arendusthreadidega siis muidugi ka 
(imho paremini kui ntx CVS, aga mul pole viimasega nii palju praktilist 
kogemust). Nagu ma mainisin, on meil näiteks olemas eraldi branchid 
produkti eri osade jaoks, mida siis integreerida saab. Mingil hetkel tuleb 
branch service packi jaoks. Samaaegselt praeguste bugide fixamisega 
tegeletakse loomulikult ka järgmise versiooniga, aga on hea komme enne 
vingelt mõelda, plaani pidada ja arhitektuuri aretada enne kui koodi 
asutakse kirjutama, nii et järgmise versiooni jaoks eraldi branchi 
loomisega on aega.
Sellepärast ei kirjuta ma ka hetkel rohkem koodi :)


Veel Andres Soolo:

>Idee ongi just selles, et isegi kui unstable build vigane juhtub olema, 
>siis frozen build (mille testimine peaks kõige aktiivsem olema) ikka 
>käib ja testijate aeg raisku ei lähe.

Võimalik, et ma ei saanud nüüd päris täpselt aru, mida Sa silmas pidasid 
või kasutame me termineid erinevalt.
Kui sa frozen buildi all pidasid silmas seda versiooni, mis kohe uksest 
välja hakkab ronima, siis selle destabiliseerimise ohust ning selle 
vältimise lüketest ma rääkisingi.

>Ma kardan, et Targo viimased selgitused on ku"llaltki selle piiri 
>lähedal,
>kust edasist MS oma ärisaladuseks pidama hakkab.  Pane tähele, et ka 
>tollest "Mitte CVS, mitte VSS"'st ei ole ta midagi lähemalt rääkinud.

Nüüd natuke kirjutasin. Tegelikult on point selles, et mul on töö, naine 
ja laps, mis kõik tulevad enne prog-listi, seda ei tule mitte Microsofti 
kuritahtlikkusena tõlgendada ;)
Teiseks on minu meelest huvitavam teema see, milline peaks olema ideaalne 
tarkvaraprojekti korraldus, mitte niivõrd MSi spetsiifika(kuigi siinne 
projektijuhtimine on ideaalile lähedasem kui ükski teine projekt, millega 
ma seni kokku olen puutunud). Sellepärast ei viitsi ma ka alati väga 
detailidesse laskuda. Mingil hetkel tuleb ärisaladus ka muidugi mängu, aga 
sinnani on veel aega.


From: Jaak Pruulmann [mailto:jjpp@meso.ee]

>See on küll üsna kontekstist välja kistud näide aga.. Lühidalt on 
>üleval kirjas, et produkti stabiilsuse säilitamise huvides tuleb 
>aegajalt kirjutada asju mitte päris nii nagu hea ja õige oleks. Küsimus 
>on, et kas siis, kui asi juba korra välja lastud on, tehakse seda laadi 
>"parandustegä ka miskit, st et kas esialgsed eritingimustes tekitatud 
>parandused normaalseteks ka kunagi saavad? või jäävad need ühilduvuse 
>säilitamise nimel igavesti paika?

case by case. Selline asi, nagu ülal kirjeldatud tõenäoliselt jääkski 
nii, kui tegu on tõsisema asjaga, siis avatakse bugide andmebaasis uus bug, 
kuhu pannakse kirja, et seda võiks paremini teha ning märgitakse 
tähtajaks järgmine milestone või release. Lisaks kirjutab vend koodisse 
kõigisse vajalikesse kohtadesse kommentaarid stiilis
// BUGBUG: use better error handling here
Ja võimaluse tekkides käib need kohad üle. Siin tekib muidugi see 
probleem, et paljudel juhtudel on otstarbekam vana koodi mitte torkida, kui 
ta üldiselt ilusti töötab ja sellised kommentaarid võivad kumuleeruda, 
samuti kasutatakse neid suhteliselt kergekäeliselt ka olukordades, kus 
tegelikult mingit bugi ei ole, a la
case 1: ......
case 2: ......
default: Assert( "BUGBUG: this should never happen!" );

Kuni mõni tegelane kõik need BUGBUGid kokku loeb ja ajakirjandusse 
lekitab, et W2K-s on mingi astronoomiline arv parandamata vigu ;( 
(sest nii see uudis W2K 64000 (oli vist?) bugist alguse sai)

cheers,
Targo