Evenimentul de lansare a ediției din mai a revistei TSM a fost găzduit de Code Crafters by BT și a reprezentat un bun prilej de discuții pe tema Software Craftsmanship. Au fost alături de noi la panel:
Cătălin Golban - Head of Department Engineering Systems Vision @ Bosch,
Cristian Cazan - CEO @ CodeCrafters by BT,
Denis Salanța - Head of Development @ CodeCrafters by BT,
Cătălin Golban: Coordonez un departament care se ocupă de conducere automată, secțiunile de embedded, senzori, computer vision și tehnologie de cloud.
Lucian Teodorescu: Lucrez la Garmin și mă pasionează distincția dintre inginer și non-inginer. Obiectivul meu principal la serviciu este cum putem crea ingineri buni și cum putem crea o lume software mai bună.
Denis Salanța: La CodeCrafters avem drept obiectiv creșterea nivelului nostru de profesionalism. Dorim să creștem calitatea codului și să reducem numărul de defecte.
Cristian Cazan: Recent am acceptat să conduc CodeCrafters, o oportunitate pentru mine. Alături de Banca Transilvania suntem foarte entuziasmați să găzduim prima sesiune fizică aici la sediul nostru.
Ce înseamnă să fii un bun profesionist și cum ar trebui să te simți la finalul unei zile de muncă, la modul ideal?
Cătălin Golban: Există câteva ingrediente, dincolo de partea tehnică care presupune că sunt acolo în mod curent. Este important să cunoaștem businessul și răspunsul la întrebarea De ce ?. Trebuie să faci zoom out și să înțelegi mai mult decât bucățica ta de cod. Trebuie să înțelegem ce face echipa și puțin din ce face șeful tău sau echipele conexe de care depinzi. E nevoie de o imagine de ansamblu dincolo de faptul că ești cel mai bun programator. Apoi, trebuie să ai o înțelegere legată de progresul tău profesional, unde ești și unde vrei să ajungi și ce mai vrei să înveți. Tu trebuie să fii cel care face ca lucrurile să se întâmple. E bine să îți iei profesia în mâini și să nu te aștepți ca șeful să îți spună mereu la ce training să participi. Dacă ești profesionist, trebuie să înțelegi că trebuie să gestionezi o complexitate din ce în ce mai mare. Chiar și un junior poate fi profesionist, iar cu timpul să învețe din ce în ce mai mult și să gestioneze probleme complexe. Munca în echipă este foarte importantă, deoarece acolo se fac lucrurile mari.
Lucian Teodorescu: Dacă taskul tău este de a scrie cod pentru a face un feature, ești un bun profesionist dacă, la final de zi, știi unde va fi în sistemul final codul scris, știi care sunt caracteristicile de calitate ale sistemului software pe care îl faci și știi că vei termina softul la timp în mod predictibil și încadrându-te în buget. Este important ca toate aceste aspecte să fie legate de taskul tău.
Denis Salanța: Profesionalismul trebuie să devină stil de viață, iar la finalul zilei vreau să simt că am făcut tot ce s-a putut pentru a implementa cât mai bine funcționalitățile.
Cristian Cazan: Aș mai adăuga că e vorba și de pasiune. Munca nu trebuie văzută ca o datorie, ci ca pe ceva ce vă place. Asta vine și cu o capcană, deoarece, uneori, când faci totul cu pasiune, nu te poți opri. Capcana este burnoutul. Echilibrul trebuie păstrat, chiar dacă sunteți foarte pasionați de ceea ce faceți.
Sunt proiecte care se termină și rău. Care sunt regulile de urmat ca să scriem cod de calitate care nu rănește oamenii, așa cum s-a mai întâmplat în aviație sau în cazul conducerii autonome?
Cătălin Golban: Este foarte important când ai o echipă mare care face sisteme safety-critical. Este la fel de important să vedem despre ce sistem este vorba. Eu nu aș face test-driven development pentru o aplicație care te informează despre ultimele concerte din oraș. Subscriu că trebuie să dozăm efortul și să nu facem overengineering. Să nu testăm prea mult unde nu este nevoie. În schimb, dacă e vorba de sisteme safety-critical sau aplicații cu tot felul de date importante, precum cele bancare, trebuie să respectăm anumite norme. În Automotive avem ASPICE care se rezumă la un set de practici și artefacte pe care trebuie să le livrezi când lucrezi la un proiect. Unii văd acest standard ca un overhead, în timp ce alții chiar înțeleg care este mindsetul din spatele acelui set de reguli. Uneori regulile sunt urmate fără a fi înțelese principiile din spate, alteori vin natural. Trebuie respectate standardele existente care sunt bine gândite și trebuie înțelese principiile de bază.
Lucian Teodorescu: Avem mai multe segmente, Fitness, Outdoor, Automotive, Marine, Aviation. Avem o prezență puternică în toate. Eu am lucrat mult timp în Automotive. Acum tranziționez în Marine. Nu am lucrat pe un software extrem de important, dar găsești aceleași probleme în toate softurile. Momentan, lucrez cu servicii cloud și mă gândesc la scenariile în care va da greș, așa cum mă gândesc la predictibilitate. Când faci un sistem software, trebuie să știi la ce să te aștepți. Trebuie construite sisteme de backup. Absolut tot ce facem în software este un tradeoff între chestii: time to market și features, performance și modifiability, usability și availability. Trebuie să știm foarte clar, înainte să construim sistemul, unde vrem să ne poziționăm, deoarece nu le putem avea pe toate. Nu putem crede că mai adăugăm o linie de cod, iar asta va rezolva problemele. Există anumite similarități cu construirea unei case. Nu putem construi o casă într-un fel, apoi să vină cineva să adauge 50 de etaje pur și simplu.
Denis Salanța: Există și un contra-exemplu din construcții. Empire State Building a fost construită cu o fundație foarte solidă, dar când au început lucrările nu au știut câte etaje va avea. Erau în concurență cu Crysler și știau că vor să construiască mai multe etaje decât concurența. Au reușit să adauge etaje și să depășească Crysler. În software-ul de tip bancar avem câteva principii pe care le implementăm pentru a scădea plaja de eroare. De exemplu, facem deployuri mai mici, dar zilnice. Dacă nu reușim să avem suficiente unit tests, depunem efort mai mare în testele end-to-end ca să acoperim tot ce ne interesează. Ce putem face în echipă este să încercăm să stricăm lucrurile cât se poate de rău, să dovedim că nu merge în anumite scenarii, pentru ca mai apoi să ne regrupăm.
Cristian, povesteam cu tine mai demult despre dezvoltarea profesională în ghilde. Cum am putea aplica acest lucru în software?
Cristian Cazan: Cred că facem acest lucru, deși poate nu este suficient de vizibil. Am fost recent la un training unde se vorbea despre ceasurile elvețiene. Istoric, acestea sunt cele mai bune sau au fost cele mai bune până a apărut quartzul. Elvețienii erau cei mai buni, deoarece aveau o ghildă care știa cum să facă ceasuri precise. După apariția quartzului, deși ghilda a fost destabilizată, ceasurile elvețiene au câștigat înapoi din prestigiu, ceea ce arată că, dacă meseria ta e una foarte bună, poți să te reinventezi și să îți păstrezi renumele. Și Clujul are un renume foarte bun. Suntem considerați Sylicon Valley al Europei de Est și se știe că avem profesioniști. Avem proiecte unde creștem juniori cu care apoi livrăm alte proiecte. Și în zona de leadership este nevoie de o ghildă, iar aici am avut inițiative și în Cluj. În cadrul Leaders Guild Cluj, ne întâlnim și discutăm pe domenii, de obicei asupra unui capitol dintr-o carte aleasă. Analizăm unde suntem noi raportat la recomandările din cărțile respective.
(întrebare din sală) Cum facem să nu existe nevoie de documentație pentru codul scris de noi, astfel încât lucrurile să fie simple, pe înțelesul oricui, chiar și pe înțelesul unui junior? Cum devenim elevețienii softului?
Lucian Teodorescu: Problema fundamentală în software este că indiferent ce facem noi, software-ul este complex. Ce ar trebui să facem noi, este să lucrăm la percepția noastră despre software. Cum putem să facem ca software-ul să fie simplu? Putem reduce technical debtul. Un cod care are o arhitectură bună nu este neapărat un cod bine structurat, cu toate că și asta ar trebui să însemne, dar este un cod care este ușor de înțeles dacă am o documentație de arhitectură bine structurată. Este o provocare mare, pentru că este greu să faci lucrul acesta. Noi avem o problemă de cunoaștere. Noi transferăm cunoaștere între noi, uneori și calculatorului, dar destul de puțin. Marea problemă o avem noi.
Cătălin Golban: Un cod care nu are documentație nu trebuie să fie neapărat de speriat, deoarece are fișiere, foldere. Dacă există un document de arhitectură, poți înțelege ce este acolo. Apoi, poți face o compilare, chiar dacă nu există documentație. Înțelegerea este incrementală. Poți lucra la o funcționalitate mică, apoi la una mare. Așa reușești să înțelegi proiectul din ce în ce mai bine. Lucrurile simple încă contează. Structura proiectului contează.
Denis Salanța: Sunt câteva răspunsuri acoperite în diferite cărți care în domeniul nostru duc la definirea unor principii ce trebuie respectate. Ținând cont de acestea, poți crește calitatea codului. Se pot crea și metrici care să determine dacă un cod este spaghetti code sau nu. Apoi se pot crea metrici de urmărire a progesului.
Cristian Cazan: Când scriam cod, țineam cont de cartea lui Martin Fowler - Refactoring. Improving the design of existing code. Exemplele de cod sunt acum vechi, dar sfaturile sunt în continuare actuale.
(întrebare din sală) În zilele noastre nu mai scrie nimeni codul de la zero. Mi se pare că o parte din complexitate și toate problemele ce vin după, apar din cauză că folosim în produs niște tooluri și librării pe care nu le înțelegem în esență. Cât de mult ne complică codul utilizarea librăriilor de pe piață?
Cătălin Golban: Te contrazic puțin. În unele proiecte scriem codul de la zero. Nu avem ce face, dar este adevărat că avem din ce în ce mai multe tooluri. Există ceva ce nu mi-a plăcut niciodată, anume există un tool sau o librărie pe care nu le înțelegi foarte bine, dar simplifici, mai vine un coleg și face la fel și iese o varză. Nu este în regulă.
Lucian Teodorescu: Codul este mai complex decât în anii 70', dar problema fundamentală este la fel. Și atunci, și acum s-a dezbătut despre care sunt principiile de structurare a codului, astfel încât să poți face abstracții. În anii 70' se discuta la nivel de funcții, acum la nivel de librării. Fundamental, abstracția este aceeași și, fundamental, modalitatea prin care software-ul poate da greș este la fel. După nivelul Hello world, codul nu mai este în capul tău. Când ai introdus o librărie în cod, trebuie să începi să o controlezi.
Denis Salanța: Introducerea unui modul extern este o decizie ce trebuie responsabilizată. Nu putem introduce într-un software bancar orice librărie. Poate trebuie formalizată decizia de introducere a unei librării în cod.
Cristian Cazan: Vulnerabilitățile trebuie luată în considerare.
Cristian, tu ai șansa de a-ți crea o echipă de la zero. Cum ai dori să arate această echipă?
Cristian Cazan: Este a doua oară când am această posibilitate. Aici am început cu o echipă cu care am lucrat foarte bine în bancă, cu care împărtășim aceleași valori, aceleași principii, cu care am un trecut bogat. Am observat că oamenii care lucrează bine împreună au tendința de a se reîntâlni în aceeași companie sau nu. E vorba de încredere dacă vrei o echipă sănătoasă. Ai încredere în cei cu care ai trecut prin niște încercări. Angajările prin recomandări sunt cele mai reușite. Suntem o echipă mică, dar avem planuri de creștere.
Dacă ar fi să evaluăm piața IT din Cluj din punctul de vedere al profesionalismului pe o scară de la 1 la 10, unde ne-am situa?
Cătălin Golban: Mi-e greu să dau un număr. Pe de o parte, cred că avem o oarecare tradiție în Cluj în software development. În Cluj, aveam în anii 70' școală în domeniu. Avem o masă critică de profesioniști ce poate propaga un mindset sănătos. Pe de altă parte, sunt mulți tineri care au intrat în domeniu în ultimii ani și care au nevoie de timp să rezolve probleme și să lucreze în echipă. Industria IT se dublează anual ca număr de profesioniști, iar pe ai noștri îi situez între 5 și 10.
Lucian Teodorescu: Avem o problemă fundamentală în industrie, nu neapărat în Cluj. Nu suntem la nivelul de maturitate al altor domenii inginerești mult mai tinere ca noi. Avem multe practici informale, fără fundament teoretic, fără baze practice. Un exemplu este TDD. Testarea este bună, dar de TDD nu suntem siguri că ne poate duce la rezultate bune fără a da greș.
Denis Salanța: Nu suntem încă de top, dar creștem.
Cristian Cazan: E ca și atunci când faci estimări cu programatorii. Suntem undeva pe la mijloc, în zona unde este loc de creștere. Există zone unde stăm foarte bine, zone unde avem code coverage de 100%. Acolo unde avem de-a face cu aplicații esențiale, sunt multe echipe care testează, multe procese bune, mult profesionalism. Pentru un PoC, poți merge la început și cu mai puțină maturitate în abordare.
de Ovidiu Mățan
de Ovidiu Mățan
de Ovidiu Mățan
