Inspirat de Ovidiu Șuța (ISDC) prin articolul său "Ce este în neregulă cu IT-ul din România?" din ediția 23 a TSM, simt nevoia de a face un exercițiu de imaginație (sau nu) prin a picta o posibila direcție a viitorului IT-ului românesc.
Părerea care reiesea din articolul menționat și pe care o împărtășesc este aceea că businessul de volum specific modelului outsourcing a devenit dăunator înseși pieței pe care o adresează.
În rândurile următoare vom încerca să propunem moduri care ar putea schimba fața software-ului românesc.
Ca și în cazul unui chirurg, totul se reduce la modul de execuție. Îmbinarea cunoștințelor cu tehnica de lucru trebuie să rezulte în perfecțiune.
Deci avem două părti ale ecuației: pregătirea personalului și calitatea execuției.
În domeniul pregătirii personalului lucrurile stau mult mai bine decât acum 10 ani. Internetul abundă de informații, firmele de atestare s-au maturizat și acum poți obține validarea cunoștințelor în practic orice aspect al activităților software (de la management la framework-uri și limbaje de programare specifice, până la aptitudini de testare validate ISTQB). Singurul obstacol este modul de aplicare în cadrul companiilor.
Învățarea este parte din munca de la birou și orice afacere care își propune să fie pe piață și peste 30 de ani va înțelege că, dacă n-a făcut-o deja, trebuie să își regândească strategia astfel încât să își permită o investiție zilnică în training pe angajat cu tot ce presupune aceasta (e.g. schimbarea formulelor de ofertare a proiectelor, achiziționarea programelor de training etc.).
În ceea ce privește asigurarea calității produselor software consider că practicile autohtone sunt deficitare. Folosirea departamentelor de testare în validarea calității unui produs software este greșit înțeleasă și aplicată. Contrar convingerilor (care par generalizate) ale organizatiilor care s-au grăbit să-și promoveze pe site-urile proprii, spre exemplu, alinierea la standardele ISO, producția de software are foarte puține lucruri în comun cu producția de lapte sau ouă.
Alte mijloace sunt în schimb mult mai potrivite și voi scrie despre acestea în continuare. Ele alcătuiesc corpul acestui articol și le consider absolut necesare când ne referim la calitate.
Versionarea codului sursă în IT-ul românesc a devenit de ceva vreme status quo, în mare parte datorită dinamicii echipelor de dezvoltare, dar și cerințelor clienților. Singurul sfat ar fi să nu rămâneți în urmă cu tendințele, nu folosiți CVS când la modă este GIT.
Folosiți tool-uri integrate și "full-feature" deoarece sunt atât de ieftine și aduc un aport enorm calității. Clientul va avea prin intermediul lor un acces și control de top asupra stării proiectului și îi va spori încrederea în parteneriat.
Un "must" indiferent de limbajul de programare. Nu pot concepe un proiect fără a ști starea codului în orice moment. Unelte ca și Jenkins sunt indispensabile. La orice modificare adusă codului veți fi înștiințați dacă testele automate s-au executat cu succes și dacă metricile de calitate sunt în limitele propuse. Combinat și cu scripturi de instalare, puteți configura un sistem live unde clientul poate accesa oricând cea mai nouă versiune a produsului. Am lucrat în trecut în Germania la un client de renume (ce activa în industria de creare soluții software) care avea ca și unică modalitate de a produce o versiune a produsului compilarea în IDE și arhivarea manuală. Nici urma de Gradle, Maven, Ant sau măcar un bash script. Inutil să spun că o astfel de abordare nu poate fi acceptabilă când discutăm despre calitate (chiar și când nu discutăm despre calitate).
Nu există motiv să nu folosim testare automată. Și mai mult, trebuie să fie de toate formele: unit testing, integration testing, regression automation (e.g. selenium). Am auzit toate motivele pentru a nu le face, însă nici unul întemeiat. Recent mi s-a spus că nu are rost să testăm javascript-ul pentru că oricum e acoperit de tastarea manuală. Am insistat să fie testat automat. Argumentele apoi s-au schimbat: e foarte dificil de testat... Dar "dificil" nu e un argument.
Sunt foarte multe la alegere, unele mai simple analizează convențiile de stil, altele merg până la a măsura complexitatea unui bloc de cod. Construirea unui pachet de bază și aderarea la el face parte din orice setup de proiect. Cele mai relevante sunt:
Aderați la principiile solide și tindeți către simplitate atunci când inspectați codul.
Dând un exemplu în Cluj care să inspire restul comunității. E nevoie de un cadru formal care să ofere greutate și care să fie o declarație de anagajament către menținerea unui standard ridicat de performanță și profesionalism. Un astfel de cadru ar trebui să fie susținut de firmele de software autohtone. Sunt cunoscute deja diverse forme dintre care cel mai recent și promițător este cluster-ul Cluj IT (http://www.clujit.ro) și citez:
About us
Cluj IT is a cluster association aiming to enhance the innovation capabilities and competitiveness of the Romanian IT sector.
Pare promițător și mă determină să îmi imaginez un grup de programatori formând o comisie comună de acreditare a calității proiectelor din fiecare firmă partener la custer. Poate o idee ambițioasă, dar cu siguranță cu un impact bun pe termen lung. Aștept păreri de la cititori.
de Ovidiu Mățan
