From: Andres Soolo [mailto:soolo@math.ut.ee]

>>>Oot, see tekitab ku"simuse, kas MS siis mingit CVSi tu"u"pi asja ei 
>>>pruugigi...?
>>oot, kas versioonikontroll iseenesest lubab ilma m6tlemata kakat kokku 
>>kirjutada va?
>Ei, aga versioonikontroll lubab säherdusest kakast väga lihtsalt 
>lahti
>saada.  Ja peaks vähendama shippimiseelset hirmu ja stressi töökohal
>ja suurendama produktiivsust :-)

Esiteks, loomulikult kasutab MS versioonikontrolli, küll mitte CVSi ega 
VSSi, vaid miskit sisemiseks kasutamiseks välja to'o'tatud vahendit, mis 
siinsele metoodikale kõige paremini vastab.

Teiseks, suure projekti puhul ei ole ükski asi lihtne, kakast lahtisaamine 
ammugi mitte. ütleme, et tarvis fixata miski bug, aga sinu fix tekitab 
teise, hoopis hullema bugi. Teed check-in'i ja lähed koju magama. Igal 
öösel tehakse automaagiliselt build, kus vahepeal lisandunud muudatused 
ametlikult kokku kompileeritakse, ja alustatakse smoke testi, mis programmi 
funktsionaalsuse olulisemad jupid üle käib ja kontrollib, et kõik ikka 
töötab. Kui ei tööta, lendab teade valvedeveloperi pagerile (igal 
nädalal on keegi 'valves', kelle poole testijad pöörduda saavad, kui 
mõni oluline asi ei tööta ja nad ise ei tea, kes täpselt vastutav on), 
kes siis kohale tuleb, asja debugib ja sulle hommikul kell seitse kurja 
häälega koju helistab, et näed, sinu komponent ei tööta. Kui hästi 
läheb, siis on tõesti võimalik lihtsalt muudatus tagasi võtta ja tehakse 
uus build ja uus test, aga see võtab üsna mitu tundi aega, inimesed, kes 
igapäevast buildi ootasid, et asja testima asuda, saavad selle varase 
hommiku asemel alles keskpäeval ja sadu inimtunde (mis kokku maksavad 
päris palju raha), on kaduma läinud. Lisaks oled sa ise samas olukorras, 
kus enne, sul on see esialgne bug, päev on kaduma läinud ja inimesed 
pahased, et miks sa ei mõtle, mida sa teed.
Kui tegemist on shippimiseelse olukorraga, on asi veelgi tõsisem, sest 
selle esialgse bugi parandust peavad testijad ka kontrollima, mida lähemal 
tähtaeg on, seda põhjalikum peab see kontroll olema ja seda rohkem teste 
tuleb jooksutada, et ikkagi kindel olla et kõik korras on. Sellises 
olukorras suureneb järkjärgult risk, et päevane viivitus bugi fixamisel 
tähendab lõppkokkuvõttes terve produkti väljalaskmise edasilükkamist, 
see on aga juba väga kallis lõbu.
Selliste riskide vähendamiseks kasutatakse mitmesuguseid lükkeid, näiteks 
suhteliselt paranoiline change control, kus sa iga muudatuse puhul aru pead 
andma, miks seda vaja on, mis juhtub, kui seda mitte teha, kust see bug 
tuli, mis sellist muutust nõuab, milliseid kõrvalefekte see muudatus kaasa 
toob ja lahti seletama, milleks iga uus rida sinu koodis hea on. Kui sellist 
kontrolli ka ei rakendataks, oleks sul endal kasulik need küsimused 
korralikult läbi mõelda, et võtta vastu projektile soodsaim otsus. Selle kohta üks illustreeriv näide ka: oletame, et sul on dll, mis kasutab 
mingit COM objekti mõnes teises dll-is. Kui see sinu dll unloaditakse, siis 
teed oma objektile ilusti Release ja puha, kõik on kena. Kui aga 
stsenaarium mingil põhjusel muutub ja see teine dll varem unloaditakse, 
siis see sinu Release crashib. Tehnoloogiselt ilus ja õige lahendus oleks 
realiseerida mingi mehhanism, mis kontrollib, et need dll-id alati õiges 
järjekorras unloaditaks, aga tähtaeg on lähedal ja selle juures on alati 
võimalik mingi loll viga sisse teha, mis kalliks maksma läheb, 
sellepärast paned sa selle Release'i ümber lihtsalt try-catch bloki, mis on 
oluliselt lollikindlam.

Nii et peaks olema suhteliselt mõistetav, miks teatud olukordades on 
kasulik kirjutada võimalikult vähe ridu.

cheers,
Targo