Töökorraldusest


Tere!

Alar kysis mult mitmesuguseid asju siinse to"o"korralduse kohta, ma saadan 
vastuse teistele ka, vahest pakub huvi.
Yldises korralduses paistab eelko~ige silma produktile orienteeritud 
o~hkkonna loomine. Tahetakse, et igal tegelasel oleks silme ees "big 
picture" sellest, milline see produkt hakkab olema ja mida tegema. Samuti 
ro~hutatakse sinu isiklikku vastutust ja ko`ditatakse enesehinnangut 
ra"a"kides, kuidas N miljonit inimest sinu koodi kasutama hakkavad ja kui 
cool see ikka on. Muidu tuleb veel mainida, et inimesed on mo~nusad ja 
jagavad yldiselt seda o~hinat valmistatava produkti suhtes, seeto~ttu ei 
teki nii kergesti mingit tylpimust - kui sa to"o"le tuled, siis tuled 
selleks, et kirjutada valmis mingi jupp, mida suur hulk inimesi pruukima 
hakkab ja mis nende elu peaks lihtsamaks tegema, mitte selleks, et 
elamiseks raha saada. See viimane on kyll natuke idealistlik variant, aga 
selle peale siin yldiselt ro~hutakse.
Peamine asi on aga see, et kellelgi pole vo~imalust yldisest protsessist 
vo~o~randuda ja ja"a"da kusagile omaette nokitsema. Iga kord, kui oled 
mingi jupi valmis saanud, vaatab mo`ni teine vend sinu koodi rida-realt yle, 
kui ko~ik korras, chekid asja source controli serverisse. Seeja"rel saadad 
kirja tervele grupile, kus kirjeldad, miks seda vaja oli (bugi kirjeldus 
ntx) ja mida sa asja parandamiseks tegid, samuti nimekirja muudetud 
failidest ja mo~justatud binarytest. Yheso~naga on to"o"kollektiivi valvas 
silm sul kogu aeg peal. Ja kui vo~imekust yles na"itad ja mingi vinge asjaga 
maha saad, siis tuleb ko~rvalttoast vend, viipab ukse vahelt ja ho~ikab, et 
"hey, nice check-in" :-) Ja kui mingit ka"kki keerad (juhtub ntx, et sinu 
kood ei kompileeru ja seeto~ttu ei saa yldist buildi teha), siis saad 
ko~vasti pa"he muidugi. Buildi a"rarikkumise va"listamiseks tuleb yldse iga 
kood muidu va"hemalt kahe masina peal kokku lasta, et kindlam oleks.
Teine oluline asjaolu on see, et kord na"dalas ra"a"gid pool tundi oma 
manageriga juttu, annad aru sellest, mis tehtud, mis teoksil ja mis mureks. 
Selle kohta tuleb muidu iga na"dala lo~pus ka aruanne kirjutada, kus paned 
kirja, mida eelmisel na"dalal tegid, mida ja"rgmisel na"dalal kavatsed teha 
ja mis sind to"o"s takistab. 
Samuti pead endale seadma pikemaajalised eesma"rgid, siin on kaks suunda. 
Esiteks pead va"lja mo~tlema mingi karja"a"rieesma"rgi, performance objectives 
(na"iteks millisele ametikohale tahad jo~uda vo~i kui suure osa haldamist
mingist projektist enda kanda vo`tta). Teiseks on enesearendamine, skill 
objectives, mo`tled va"lja, milliseid tehnoloogiaid tahad o`ppida ja milliseid 
vo~imeid arendada. Arutad need eesma"rgid manageriga la"bi ja siis ta ja"lgib 
sind selles osas. Kaks korda aastas on performance review, kus vaadatakse, kui
 ha"sti sa nende eesma"rkidega toime oled tulnud ja pannakse hinne sulle. 
Vastavalt sellele otsustatakse siis ka, mis sinust edasi saab, et kas saad 
ametiko`rgendust ja palgato~usu vo~i lastakse hoopis lahti. Ametid pole va"ga 
rangelt fikseeritud muidu, hinnatakse eelko`ige sinu yldist mo`ju projektile 
(peamiselt selle ja"rgi, kui suur osa produktist sinu disainitud on). Selle 
ja"rgi asub iga vend siis mingil astmel. Developerid alustavad tavaliselt 
kymnendalt astmelt ja saavad ronida neljateistkymnendani (see oleks siis mingi 
selline positsioon, kus sa koostad terve produkti yldise disaini). Vastavalt 
sellele on tavaliselt kujundatud ka alluvusstruktuur,  aga see pole range 
reegel, mo~nele inimesele manageerimine lihtsalt ei istu. Seepa"rast vo`ib 
yheteistkymnenda taseme vennal olla rohkem alluvaid kolmeteistkymnenda taseme 
tegelasel.
Paar so~na kasutatavatest vahenditest. Peamine vahend on Visual C++ 6, see on 
siin yldiseks standardiks. Lisaks kasutan mina veel Office'i Visual Basicut 
selleks, et uurida, mida mingi Office'i produkt yldse teha oskab ja milline 
interface tal programmeerija jaoks on, samuti mingil ma"a"ral IDLi 
COM-interface'ide kirjeldamiseks.
Lisaks on olemas suurel hulgal igasuguseid silumisvahendeid, Visual Studio 
sisaldab endas remote debugeri, peale selle on muid monitoorimise ja silumise 
konfi muutmise jubinaid. Kuna meie systeem on klient-server systeem, siis 
kasutame ka network monitori selle asja ja"lgimiseks ja spetsiaalselt meie 
protokolli ka"sitsi kasutamiseks mo`eldud vidinat. Siis on veel mitmed muud 
vahendid, millega saab ntx registrys olevate klasside infi intelligentselt 
vaadata, uurida, kuidas mingid DLLid teineteisega seotud on jne. 
Tehnoloogiatest on ko~va so~na COM ja sellega seonduvalt ATL (Active Template 
Library), millega COMi vo~imalusi paremini a"Ra saab kasutada. To"o" peamine 
keerukus seisnebki selles, et ko`Ik need tehnoloogiad ei ole tegelikult yldse 
va"ga triviaalsed ja nende efektiivne kasutamine no~uab kyllaltki palju 
o~ppimist ja pingutamist, samuti tuleb ysna loovalt la"heneda probleemile 
juhul, kui sinu arendusplatvorm (Office'i COM-interface minu puhul ntx) ei 
sisalda ko~iki vo`imalusi, mida sul vaja oleks.

Ehk oli abx :)

ko~ike head,
Targo