Cât de actual mai este subiectul de software craftsmanship? Am discutat cu invitații noștri despre acest subiect dar și legătura ideală dintre business și echipele de dezvoltare pentru a avea un produs final ideal:
Dan Avram - Deputy Director Retail Products @ Banca Transilvania,
Szilard Antal - Head of Development @ BT Code Crafters,
Alex Cioflică - Software Architect @ Betfair Development Romania,
Daniel Pavăl - Cloud Solutions Architect @ BT Code Crafters,
Roxana Mureșan - Software Architect @ Accenture Industry X,
Ovidiu Mățan: Vă invit pe fiecare să spuneți câteva cuvinte despre voi
Szilard Antal: Sunt Head of Development în Code Crafters, destul de recent în Code Crafters. Lucrez în domeniu de 19 ani în zona de backend. Am coordonat comunități și echipe în diverse domenii: bancar, automotive, plăți și nu numai.
Alex Cioflică: Eu am început în IT în clasa a X-a cu primele proiecte comerciale. Lucrez la Betfair de 14 ani unde am fost inițial programator. Acum sunt Software Architect și am tranziționat spre piața din SUA, total diferită de ceea ce avem în Europa. Este foarte interesant să treci prin multe tehnologii și să trebuiască să cercetezi constant. Cel mai provocator lucru este să îți dai seama ce să nu folosești.
Dan Avram: Am peste 12 ani de experiență în domeniul bancar. La început mă ocupam de partea de gestiune de produse bancare clasice. Treptat, m-am implicat în proiectele de digitalizare ale băncii, cum ar fi client onboarding la distanță. Momentan, sunt parte din proiectul BT One. Banca are multe proiecte pentru digitalizarea produselor self-service, cum sunt de exemplu toate funcționalitățile livrate iterativ în aplicația BT Pay.
Daniel Pavăl: Momentan, sunt Solutions Architect la BT Code Crafters. Vin cu o experiență de Java pe backend. O vreme m-am ocupat pe cont propriu de outsourcing unde am făcut de toate de la programare la achiziție de clienți și relații clienți. Acest proiect și interacțiunea cu angajații mi-a dat o perspectivă care mă ajută și în ziua de astăzi.
Roxana Mureșan: Am 15 ani de experiență în domeniul proiectelor feroviare. Articolul scris pentru revistă abordează inovațiile care pot fi aduse în acest domeniu, industria feroviară fiind una care se modernizează mai greu. Uniunea Europeană susține foarte mult dezvoltarea sistemelor.
În Java Manifesto se pune accent pe indivizi și interacțiuni nu pe tooluri și procese. Cum comentați această viziune?
Szilard Antal: Sunt de acord cu această idee pe care o văd aplicată zilnic. Este clar că indivizii sunt cei care contează. Când produci ceva, este important să știi care sunt oamenii care construiesc acel lucru și să construiești echipele, astfel încât să susții punctele forte ale fiecărui individ. Procesele și toolurile vin să ajute la valorificarea potențialului individului. Unii cred că întâi faci tooluri și procese și ulterior vin oamenii să lucreze cu ele. Eu cred opusul. Totul trebuie adaptat la context, astfel încât să aducă valoare maximă.
Daniel Pavăl: Eu am o tendință spre formalizare și standardizare, dar văd și apreciez nevoia de a face loc flexibilității. Constat că dialogul și comunicarea directă între oameni bat de multe ori procesele. Nu există o rețetă.
Cum ar trebui să arate un cod curat?
Alex Cioflică: Cu siguranță, există multe cărți care explică principiile, dar, pentru mine, un factor important este colaborarea. În Cluj și în România avem oameni foarte buni. Putem învăța unii de la alții cum să scriem și cum să găsim soluții. Noi avem ședințe de arhitectură unde participă programatorii pentru a-și oferi punctul de vedere. Ne centrăm pe DE CE. Am învățat astfel mult unii de la alții. Este un mediu dinamic cu multe voci care au ceva de spus. Vezi cum crește calitatea soluțiilor pe care le implementezi, deși inițial lumea este reticentă la discuții, la prezentări.
Cum interacționați cu programatorii?
Dan Avram: Interacțiunea este foarte importantă. Trebuie să stai cât mai aproape de echipă. Dacă acum câțiva ani, aveai o cerință de business care era preluată de cineva care nu prea punea întrebări până să se apuce de treabă, acum îi implicăm pe programatori din primele momente și ne implicăm pe tot parcursul procesului de dezvoltare. Aveam anterior situații în care erau diferențe mari între ceea ce ceream și ceea ce primeam de la programatori, fiind nevoiți să acceptăm compromisuri, deoarece era important să ieșim pe piață cu produsul. Cu cât e mai clar pentru echipă ce are de făcut, nu doar la nivel de cerință, ci la nivelul efectului acelei cerințe pentru client, cu atât mai mult oamenii devin parte a acelei funcționalități și a succesului.
Cum vezi raportul dintre business și software craftsmanship. Businessul mereu va zice să scoatem pe piață noi funcționalități, iar programatorul va zice că are nevoie de timp să mai îmbunătățească codul. Cum vezi acest echilibru?
Roxana Mureșan: Am avut o discuție pe această temă cu un Delivery Manager. Îi spuneam că nu avem toate testele, iar cele pe care le avem nu sunt complete. Îi spuneam că trebuie să lucrăm un pic pe cod ca să nu mai vină defecte din producție. Persoana mi-a răspuns că este interesată de cât de repede iese produsul, nu de calitatea acestuia. Am fost întrebată de ce iau asupra mea calitatea produsului și i-am spus că așa este profesionist.
Dan Avram: Businessul va dori mereu ca totul să fie rapid, de un nivel calitativ superior și ajustat la buget. Jonglăm cu acest triunghi și este foarte important să fixăm așteptările de la bun început. În sesiunile de demo, putem spune dacă funcționalitatea este suficient de bună pentru lansare în producție. În ceea ce privește ședințele de prioritizare, am fost nevoit de multe ori să renunț la anumite funcționalități, dar este o calitate să poți decide ce este suficient de bun ca să ajungă în producție.
Roxana Mureșan: Uneori, ceea ce este suficient de bun poate să producă mai multe probleme. Alteori, te chinui apoi să repari ceva ce a fost suficient de bun pentru producție la un moment dat.
Cred că singura excepție sunt afacerile de tip start-up. Eu am creat platforma StreamEvent cu trei luni înainte de conferința ITDays din pandemie, în condițiile în care nu știam JavaScript și nu făcusem site-uri. Mi-a ieșit. Singura problema în prima zi de conferință a fost că după primii 200 de participanți autentificați, nimeni nu s-a mai putut autentifica. Am avut 30 de minute de panică în care am deschis codul, am rezolvat problema, apoi totul a mers. Dacă introduci probleme, trebuie să fii conștient că le vei rezolva tot tu.
Daniel Pavăl: Un compromis ar putea fi să vezi care sunt contractele, care sunt sistemele și apoi să lucrezi la integrări. Dacă ai făcut compromisuri de calitate, poți reveni ulterior.
Roxana Mureșan: Îți permite un Product Owner să revii asupra unei funcționalități declarate închise? Sunt de acord cu tine, dar trebuie să fim conștienți de faptul că există Boy Scout Rule. Ai dat de un cod, începi să îl scrii, îl lași cât poți de curat. Cercetașii strâng totul după ei când merg într-o tabară.
Szilard Antal: Ca echipă, ca programatori, trebuie să fim pragmatici. Cu riscul de a-mi atrage critici, vreau să spun că și businessul cere dintr-un motiv. Ajută foarte mult să înțelegi de ce se întâmplă anumite lucruri. Indiferent ce rol ai, altfel poți calibra nivelul de calitate. În domeniul feroviar, siguranța este vitală, dar, la Facebook, dacă nu apare o postare cu pisica ta, nu este chiar așa mare problemă. Chiar dacă suntem oameni tehnici, vom performa din ce în ce mai bine pe măsură ce înțelegem businessul. Trebuie să înțelegem și ce înseamnă a îmbunătăți. Am văzut echipe care au investit foarte mult în automatizare, care au făcut tot felul de dashboarduri, astfel încât au arătat businessului pe date câte releaseuri se fac pe an în condiții de siguranță. Poți convinge pe cineva din business și de importanța de a face refactoring dacă vorbești pe limba potrivită și explici de ce.
Dan Avram: Există un roadmap, multe priorități așteptate de public, prin urmare va fi greu să convingi businessul să renunțe la acest plan. Există o efervescență în domeniul bancar în ultimii ani. Toate băncile au accelerat procesul de digitalizare, iar FinTech-urile au pus presiune și mai mare. Marii jucători s-au adaptat și au trebuit să se adapteze.
Ca programatori, luați decizii de business? Unii programatori consideră că ei și producția sunt una.
Roxana Mureșan: Depinde totul foarte mult de experiența programatorului și aici nu mă refer doar la anii pe care îi are programatorul în spate. Mă refer la numărul de luni pe proiect și la tipul de proiect. Dacă ai avut un proiect bancar și apoi ai trecut pe un proiect feroviar, trebuie să pui întrebări și să clarifici detaliile cu cineva mai experimentat în business. Trebuie să ai curajul să spui NU ȘTIU și să cauți persoanele ce au răspunsuri.
Alex Cioflică: Programatorul nu lucrează izolat. Există testare, există Product Owner. Undeva tot se va găsi informația necesară, iar cazurile cu probleme ar trebui prinse la un code review.
Daniel Pavăl: O altă perspectivă se referă la relația dintre Business Analyst și programatori. Trebuie să existe o osmoză și am văzut foarte des situația în care specificațiile au fost rescrise pe alocuri cu input de la programatori. Trebuie comunicare și colaborare.
Cum vedeți etica în programare? Avem tooluri performante și, dacă am dori, am putea face lucruri destul de rele.
Szilard Antal: Eu cred că avem etică în programare. Avem și ar trebui să avem o etică a muncii. Este alegerea fiecăruia în ce domeniu vrea să intre. Putem avea păreri legate de limitele AI-ului, de rolul său, dar nu este ceva ce putem doar noi rezolva.
Roxana Mureșan: Știu că pentru proiectele open source există o responsabilitate a contribuitorilor. Trebuie să ținem cont că acel cod este folosit de oameni care uneori oferă date confidențiale. Pe lângă date, utilizatori, viață privată, există și reglementări ce trebuie respectate. Nu știu câți dintre voi știți că există Software Craftsmanship Manifesto pe care l-am semnat acum 10 ani și care este încă valid. Cred că ar trebui menționat la nivel de facultate și companie.
Cât de mult luați în considerare AI în ce privește zona de specificații de produs?
Dan Avram: Nu am explorat AI-ul în zona de requirements, acestea venind de cele mai multe ori din feedbackul clienților. Avem un sistem AI ce răspunde întrebărilor clienților. De asemenea, la bancă am introdus AI-ul în diverse soluții și am experimentat intern cu colegii de la HR sau Legal. Avem în vedere soluții interne sau adresate clienților care implică AI pe care le explorăm. Cât despre requirements, noi nu venim cu un document lung de requirements pe care îl prezentăm echipei, ci discutăm cu echipa și ajungem împreună la ele. Pornim de la ce vrem să facem și detaliem procesul împreună. Ulterior, trecem prin documentare, user stories, iar apoi la programare și utilizare efectivă.
Ce tooluri folosiți ca Software Architect?
Alex Cioflică: Folosesc Confluence, tooluri de diagrame, dar mă ajută foarte mult să citesc și să particip la conferințe.
Daniel Pavăl: Și eu folosesc Confluence, un Confluence mare și stufos, iar visul meu este ca acesta să fie indexat, apropo de GenAI. Este un chin să cauți și aș dori să îmi returneze răspunsuri ușor. Ce ar fi dacă ar veni și business requirements indexate și astfel să putem vedea în Confluence direct dacă aceste requirements sunt aliniate cu ceea ce am dezvoltat anterior. Legat de tooluri, mereu mă gândesc cum este mai bine să fac diagrame. Avem în plan să folosim un tool numit Structurizer care te lasă să modelezi tot ecosistemul și astfel să îți fie mai ușor să vezi cine cu cine comunică.
Szilard Antal: Eu sunt curios ce va veni pe tooling din partea de AI. Sunt curios cum vor fi augmentate anumite tooluri. S-ar putea să primim informații legate de cum scriem cod, nu doar de ceea ce scriem, iar asta să ne indice niște tipare cu probleme într-un sistem mai mare. Va fi o zonă interesant de urmărit.
Roxana Mureșan: Mă gândeam dacă ar putea GenAI să facă un code review și să descopere mai mult decât erori statice. Aș vrea să poată să-mi spună dacă acel cod chiar implementează requirementul.
Alex Cioflică: AmazonQ promite să facă acest lucru, să genereze codul într-un anume stil cerut pe baza datelor, pe baza requirementurilor, pe baza codului deja scris. Probabil că un junior nu ar vedea un bug de cod generat de GenAI, dar un senior l-ar vedea.
(întrebare din public): Sunteți familiarizați cu termenul Professional Developer care acoperă tocmai partea de etică și cod de comportament în programare?
Roxana Mureșan: Există un site numit Clean Code Developer care se ocupă chiar de acest subiect. Încearcă să prezinte principiile de lucru și să ridice gradul de conștientizare pe acest subiect. Ceea ce este interesant este modul în care acel site prezintă informația. Practic, o structurează pe 7 nivele, unde primul nivel este acela în care ești conștient că trebuie ținut cont de etică. Pe măsură ce înaintezi îți spune ce trebuie să faci ca să atingi nivelul următor.
Ce sfaturi ați da celor tineri legat de Software Craftsmanship?
Daniel Pavăl: Este foarte important să fii pasionat de ceea ce faci, mai ales că avem colegi care sunt pasionați doar de atractivitatea salarială din IT. Să nu fie superficiali, să nu scrie cod pe fugă.
Roxana Mureșan: Să nu se atașeze de cod și să fie pasionați, deoarece atunci este mult mai ușor să performezi. De multe ori, în câteva luni va veni o cerință de business care te va obliga să schimbi codul scris până în acel moment. Să fie profesioniști și să respecte Boy Scout Rule.
(întrebare din public): Cum recunoașteți un alt Software Craftsman? Sunt câteva indicii care îl dau de gol?
Alex Cioflică: Se vede după cum scrie codul. Se vede după cum merg flowurile și după cum e documentat. Poți urmări ușor logica. Uneori, codul nu se schimbă în 6 luni. Sunt cazuri în care poate stai mai mult pe o bucată de cod, dar apoi acea bucată rămâne validă câțiva ani buni.
Szilard Antal: Un cod bine scris poate fi citit fără comentarii și explicații. Este drept că au apărut și alte aspecte - date private, date sigure - iar un profesionist se va uita și la acestea. Ține și de senioritate și de modul în care acel craftsman înțelege cum poate aduce valoare codul său.
de Tibor Boné
de David Stan
