Probabil am mai povestit pe aici despre faptul că în vara anului 2003 am participat la un stagiu de practică (aka "internship") la Microsoft, tot în cadrul grupului CLR. La vremea respectivă, cantitatea şi calitatea instrumentaţiei disponibile în Windows şi în CLR au fost două din aspectele surprinzătoare pentru mine (în particular, mă refer la instrumentaţia ETW, despre care nici nu ştiam că există la vremea respectivă).

Mai auzisem eu că în codul din nucleul sistemelor de operare, cam 30% din linii conţin funcţionalitatea propriu-zisă, restul de 70% având grijă de tratarea erorilor şi de diverse alte elemente de infrastructură, dar am avut atunci pentru prima dată ocazia să beneficiez în practică de existenţa acelei infrastructuri, din perspectiva consumatorului de informaţie, iar posibilitatea de a vedea câte o "radiografie" a Windows în timp real s-a dovedit nepreţuită.

Tot atunci am auzit de la managerul meu o expresie care mi-a rămas întipărită - "Dacă ai cere cuiva să conducă o maşină fără indicatoare pe bord, ar spune că eşti nebun. Cu toate astea, majoritatea covârşitoare a aplicaţiilor din prezent nu au nici un fel de indicatoare ale stării lor interne."

În ziua de azi este o naivitate să spui că o aplicație este satisfăcătoare din punctul de vedere al calității doar pentru că îndeplinește cerințele funcționale din specificații.

În ultimii ani, ne-am obișnuit faptul că pe lângă criteriul menționat mai sus, o altă cerință minimă pentru orice aplicație este securitatea. E drept, se poate spune că securitatea codului este o consecință a calității lui, dar de obicei securitatea componentelor individuale ale unui sistem nu garantează automat securitatea sistemului pe ansamblu. Mai sunt necesari pași suplimentari la nivel arhitectural, cum ar fi analiza amenințărilor, încadrarea lor în categorii de risc șamd, dar (de multe ori) şi la nivel de implementare.

Similar, o altă cerinţă pe care trebuie să o îndeplinească orice aplicaţie este performanţa. Există, de altfel, oarecare similitudini între performanţă şi securitate, ca aspecte ale unei aplicaţii. E foarte dificil să demonstrezi că o bucată de cod este sigură sau performantă în absenţa unor obiective clare în această privinţă, dar este foarte uşor să recunoşti o aplicaţie nesigură sau neperformantă. Din păcate, pentru relativ mulţi producători de software, aceste aspecte nu apar în planificarea iniţială, ci sunt "ataşate" pe parcurs, atunci când lucrurile încep să scârţâie.

Enumerarea ar putea continua mult și bine. Am putea vorbi despre ușurința instalării, actualizării și ștergerii aplicațiilor, mai ales că "grija" cu care majoritatea producătorilor de software se ocupă de aceste aspecte e îngrijorătoare. Sau am putea vorbi despre instrumentare - subiectul cu care am deschis azi discuția - despre posibilitatea de a privi direct în măruntaiele unei aplicații pentru a înțelege ce se întâmplă cu ea, și mai ales de ce. Sau despre globalizarea și localizarea aplicațiilor, subiecte mult mai dificile decât par. Probabil că oricâte aspecte aș numi, tot aș uita alte câteva, la fel de importante.

Pentru unele probleme, soluțiile tehnice abundă. Când vine vorba de instrumentare, mă refer de exemplu la ETW și WMI, la contoare de performanță, event logging, dar și la soluții low-tech gen OutputDebugString sau scrierea de mesaje într-un fișier. Pentru altele, cum este securitatea, este nevoie de pregătire specializată.

Întrebarea mea este simplă: Pentru a scrie o aplicație, este de cele mai multe ori nevoie de programatori cu aptitudini relativ specializate. Unii sunt mai buni cu bazele de date, alții cu aplicațiile distribuite, alții cu interfețele Windows, web, (XAML?), și tot așa. Nu poți lua pe cineva care a lucrat ultimii câțiva ani în domeniul rețelelor și să-l faci peste noapte specialist în formate audio. Cum punem în echilibru nevoia de a crea aplicații cu adevărat industriale (care îndeplinesc toate criteriile menționate mai sus) cu necesitatea de a utiliza resursele fiecărui programator acolo unde este mai priceput?

Este mai bine ca fiecare programator să devină expert și în securitate, performanță șamd, pe lângă bagajul de cunoștințe specializate la care apelează în activitatea de zi cu zi? Sau este mai eficient să avem specialiști în aceste aspecte, care lucrează cu toate componentele unui proiect și au grijă de aplicație pe ansamblu, dar introduc un nivel suplimentar de indirectare (sau birocrație, sau proces, sau cum vreți să-i spuneți).

Sunt de părere că pentru proiecte mici, cu buget și echipe restrânse, fiecare participant trebuie să poată avea grijă pe cont propriu de aceste aspecte, pentru componentele pe care le construiește. Pe termen lung, însă, cred că e benefică existența unui specialist în performanță sau securitate, care să aibă rol de supervizor și dictator la nivelul întregului proiect. Mai cred și că nu toate aspectele trebuie tratate în mod egal; de exemplu nu mă aștept ca toți programatorii să înțeleagă subtilitățile legate de securitatea sau de internaționalizarea aplicațiilor la același nivel la care o face un specialist; pe de altă parte, însă, mă aștept ca orice programator să știe să folosească un debugger, un profiler, să-și instrumenteze codul și să includă toate aspectele relevante în proiectarea aplicației, de la bun început.

Voi ce părere aveți? Prin proiectele la care lucrați, cum sunt tratate aspectele acestea?