vs.net 2008: ducă-se!

Aștept cu interes versiunea finală de VS.NET 2010. Release Candidate arată promițător, cel puțin comparativ cu catastrofele care au fost 2008 și 2005 (de la 2002 și 2003 chiar nu aveam așteptări deci nu am reușit să fiu trădat). Sper să nu mă pronunț prematur, nu am apucat să-l frec prea mult dar aberațiile din 2008 nu mi-au sărit în ochi. Probabil sînt altele care așteaptă să fie descoperite, tradiția e prea lungă ca să fie curmată așa brusc.

Performanța din versiunea 2008 chiar și după Service Pack 1 e uneori critică. Unele decizii complet imbecile se văd cu ochiul liber și strigă după ajutor. Unele probleme sînt atît de evident defecte chiar și pentru un începător încît îmi sugerează că șerpăria din interior e scăpată de sub control.

Viteza de reacție cînd lucrezi cu clase de peste 5000 de linii scade dramatic, o admit chiar și autorii. Rico Mariani (responsabilul cu performanța în 2010) parcă accepta faptul dar NUMAI ca să vîndă 2010 care se apropie, nu ar fi spus-o imediat după lansarea versiunii 2008. Da, știu: o să aud virtuoși care vor spune că e vina mea dacă am așa clase și nu știu să scriu sau organizez cod, că un bun programator nu trece niciodată de X linii într-o funcție / clasă / proiect / soluție / carieră (fiecare cu altă valoare pentru X). Ăsta e un non-argument despre care se poate discuta separat. Faptul că problema e recunoscută (și sper rezolvată în 2010) dovedește că există situații din lumea reală în care chiar și programatorii competenți pot fi loviți de ea deci a meritat să fie făcută bine pînă la urmă.

Cum reacționează VS.NET la clase de genul ăsta? Poți avea orice mașină (nici nu mă uit la multe core-uri, nu am AȘA pretenții de scalabilitate), editarea merge sacadat, cu pauze, cu cîte un îngheț pe ici pe colo chiar și la Page Up / Page Down. Experiența de tastare a codului în condiții de genul ăsta poate deveni foarte neplăcută. Permanent riști să pierzi vreo tastă dacă o iei înaintea editorului. În WordStar sau Notepad pe 286 nu aveam surpriza ca editorul să rămînă cu un cuvînt în urma mea și mă îndoiesc că am ajuns să tastez cod ATÎT de neprevăzut de rapid de atunci pînă acum. Dacă editorul nu poate ține pasul la tastare, ceva e defect. Pînă aici aproape pot înțelege: poate sînt lucruri enorm de complicate acolo legate de intelisense. Se poate ierta.

Dar…

Acum 2 zile a luat-o razna CodeRushXPress (știu că nu face parte din VS.NET deși e recomandat oficial dar nu despre el o să povestesc). I-am cerut un Extract Method. A înțepenit (din păcate doar în aparență, în fundal el muncea intens). După un minut de răbdare am înțeles că ieșirea e prin spate și am rezolvat zbaterea din task manager. Am redeschis proiectul ca să aflu că o clasă minimă, de vreo 100 de linii, prin Extract Method-ul eșuat a ajuns să aibă 60.000 de linii, cu mii și mii de metode extrase repetat.

Cum se mișca editorul e greu de descris dar voi încerca:

> Page Down

pauză 5 secunde cu IDE-ul gri urmată de repaint la jumătate de fereastră

> Page Down

îngheț prelungit, repaint aproape complet

> CTRL+END

pauză/îngheț/iarnă (dar după iarnă vine primăvara de cele mai multe ori)

Am înțeles în punctul ăsta ce a făcut Extract Method, am pus un punct de start selecție jos de tot și am dat un CTRL + SHIFT + HOME ca să mă duc pînă sus cu selecția, după care am deselectat începutul (corect) al clasei ca să șterg gunoiul de sub codul corect. Am avut răbdare, am făcut manevra cu minim de acțiuni ale cursorului și cu o singură editare (un singur delete), să nu crape ceva sau să nu dureze fiecare operație mai mult decît ar fi durat restaurarea din backup și rescrierea a 50 de linii de cod. M-am purtat cu el ca și cu oul roșu. Am ajuns fericit la momentul în care urma să apăs delete și am și făcut-o.

3.1GHz, 4G RAM, 4 core, SSD, 30 de secunde de IDE gri. Pentru un DELETE! Nici măcar nu a fost CUT să zici că-l pune în clipboard. OK, a salvat pentru UNDO… 300K de text. Ce a rămas după a fost o clasă curată, corectă și compilabilă. Ce putea face 30 de secunde la o ștergere? Da, știu, nu e scenariul tipic, nu optimizezi de obicei pentru așa ceva DAR de ce ai ajunge să fie nevoie să optimizezi în primul rînd cînd treaba de făcut e chiar elementară?

Era mai ușor să închid IDE-ul, să fac ștergerea din notepad și să redeschid soluția și chiar să o recompilez! Cum s-a ajung la așa ceva? Cu cîrma proiectului scăpată de sub control, cu programatorii care se ocupă de expresii lambda sau LINQ-uri și mai bestiale. Contează cum tastezi? Aiurea! Detalii de implementare. Contează că datagrid sau gridview sînt praf, cam cum au fost lăsate în 2005? De unde, alea-s pentru începători și fraieri.

O altă treabă care îmi spune că VS.NET e scăpat de sub control cel puțin în v2008: am o clasă mai măricică. Lucrez la ea, treaba merge, mă descurc. Soarele-i deja sus pe cer de 2 sulițe. Deodată, în mod cu totul ieșit din comun pentru un scenariu de lucru considerat normal și anticipat de Arhitecți, nu mai am nevoie de fereastra cu clasa respectivă și dau să o închid. Nasol! Tinerii nu s-au gîndit. E bine să rămîi mainstream dacă nu vrei surprize!

Cum funcționează închiderea ferestrei de cod dacă ai ochiul destul de ager:

1) o mică pauză de pregătire a închiderii

2) decolorarea sintaxei din editor (adică redesenarea ferestrei cu cod ce urmează a fi închisă)

3) o altă mică pauză de pregătire a continuării închiderii

4) fereastra de cod e închisă (soarele e sus pe cer de 2.25 sulițe).

Că durează mult închiderea… nu știu ce să zic, pot eventual concepe că există lucruri extrem de complicate, dincolo de imaginația mea, necesare atunci cînd închizi o fereastră (nu, nu e vorba de vreo salvare!). Că în procesul de închidere e nevoie de “decolorarea” vremelnică a sintaxei, asta mă depășește complet. Îmi amintește de Linuxul anilor 90 cînd un resize la cîte o fereastră producea 3-4 redesenări vizibile ale controalelor în diverse faze intermediare. Sau poate e un efect gen “fade out”? Trebuia să îmi dea fiori estetici și nu m-am prins decît acum cînd deja e prea tîrziu: încă o săptămînă și magia va dispărea (SPER!) pentru totdeauna.