Un segment larg dintre dezvoltatorii software consideră că locul de muncă actual este doar o etapă intermediară, că nu este o destinație, ci doar un mod de a ajunge acolo. Sunt persoane care vor să își deschidă propria afacere, altele care se gândesc să presteze servicii de consultanță și în final sunt persoane care vor o tranziție spre arhitectură software. Cea din urmă opțiune este cel puțin din punctul meu de vedere subiectiv, una dintre cele interesante decizii. În acest articol, vă voi arăta modul în care am parcurs personal acest proces și ce învățăminte am tras pe parcurs.
Nu este o rețetă a succesului, ci doar o experiență personală. Sunt sigur că am comis o serie de greșeli și că voi mai face și altele în viitor. Rolurile tind să fie oarecum diferite de la o companie la alta, deci nu fiți mirați dacă vă veți întreba de ce vorbesc despre o anume temă pe care nu o asociați în mod direct cu arhitectura.
În primul rând, voi vorbi pe scurt despre circumstanțele acestei tranziții. Eu activez în special în domeniul SAP. În opinia mea, această specializare este foarte diferită comparativ cu celelalte arii din domeniul IT. Veșnica prezență a unui sistem legacy extrem de complicat, paradigmele practic scoase din uz, amestecul tehnologiilor noi cu cele arhaice și rezistența perpetuă împotriva rescrierii codului sunt doar câteva probleme întâlnite în viața de zi cu zi.
SAP are o tendință pronunțată de a reinventa roata. A construit de-a lungul timpului o serie de concepte, produse și întregi tehnologii de la zero. Există limbaje de programare, baze de date, frameworkuri, servere de aplicații și chiar paradigme de programare care se folosesc exclusiv în ecosistemul SAP.
Pentru a înrăutăți lucrurile, o suită întreagă de tehnologii și produse au fost abandonate pe parcurs, dar în mod firesc, încă există atât clienți care le-au cumpărat cât și programatori care sunt nevoiți să lucreze cu ele.
Compania pentru care lucrez în prezent (msg systems) are un program numit "continuous learning". În cadrul acestuia, participanții își investesc un procent din timpul de lucru în studiul tehnologiilor noi. De obicei, sunt ajutați de colegi deja versați în conceptele respective. Deoarece ideea în sine pare bună, m-am implicat puternic în diverse astfel de activități de mentoring.
În ultimii ani, am descoperit un set de comportamente sau tehnici care fie m-au ajutat, fie m-ar fi ajutat la momentul respectiv dacă le-a-și fi descoperit mai repede:
Implicarea clienților. Din experiență proprie, pot spune că mulți arhitecți fac o greșeală majoră la acest capitol. Se închid într-un așa-zis turn de fildeș, construiesc un set complex de idei și modele, dar nu reușesc să le valideze la timp împreună cu clientul. Un alt comportament similar este cel de a părăsii proiectul de îndată ce faza inițială de proiectare arhitecturală s-a încheiat. Un arhitect bun trebuie să fie parte a echipei până la finalizare. El poate tranziționa și spre un alt rol, de lead developer spre exemplu, pentru a se asigura că viziunea inițială este ajustată și transpusă în realitate.
Stabilirea principiilor. Lipsa unui set clar de principii stabile și bine ancorate poate cauza foarte ușor probleme la toate stadiile unui proiect. Respectarea unui set de principii (spre exemplu "aderarea la semantica verbelor HTTP") asigură atât integritatea structurală a modelului cât și un proces decizional transparent și predictibil.
Perfecționarea continuă. Este greu de atins deoarece se poate cădea foarte ușor în extreme. Dacă nu avem suficientă flexibilitate și preferăm soluțiile pe care le-am întâlnit în trecut, atunci putem ajunge foarte ușor la o situație comparabilă cu reinventarea roții. De fapt, cei de la SAP au parte de problema aceasta în multe dintre produsele lor. În celălalt capăt al spectrului, dacă folosim mereu ultimele apariții din domeniul tehnologic, nu vom reuși niciodată să finalizăm un proiect, echipa fiind mereu ocupată cu migrarea și refactorizarea codului. Un ritm echilibrat de preluare a noilor tehnologii reduce efortul depus pentru dezvoltare, dar nu afectează semnificativ viteza echipei.
Negocierea perpetuă. În mediul în care activez, acest aspect are o importanță mai mare decât de obicei, deoarece sunt implicate trei părți în orice proiect: clientul, SAP-ul și noi. Într-o asemenea constelație, pasivitatea nu își are locul. În schimb, trebuie să fim fermi pe poziție și să deținem argumente solide pentru orice opinie. O tehnică bună este prezentarea mai multor soluții interlocutorului (fie el clientul sau chiar SAP). Apoi o analizăm pe fiecare în parte, o descompunem în avantaje și dezavantaje și, în final, formulăm o propunere pertinentă. Luarea de decizii individuale trebuie evitată. De asemenea, este bine să documentăm firul logic și pașii care au dus la o fiecare decizie.
Rezolvarea problemelor este în însăși natura jobului, dar sunt o serie de situații care ies în evidență:
Implicarea târzie. Se întâmplă des: un alt arhitect începe munca, o abandonează pe jumătate terminată, iar apoi altcineva trebuie să finalizeze arhitectura. Într-un asemenea scenariu, date esențiale despre sistemul proiectat sunt invariabil pierdute, chiar și în cazul extrem de rar al unui transfer de informații eficient.
Folosirea tehnologiilor de o maturitate scăzută. În lumea SAP, are loc o adevărată epidemie de asemenea situații. Folosirea unui framework nou implică de multe ori, o lipsă acută de documentații exacte, liste actualizate de funcționalități sau exemple de utilizare. O strategie de a reduce impactul acestei probleme este de a efectua o analiză detaliată a fiecărei funcționalități furnizate de către framework, înainte de a definitiva aspectele dependente ale sistemului.
Necesitatea de a folosi tehnologii învechite sau pur și simplu "rele". Sunt persoane care descriu un așa-zis "sindrom Stockholm tehnologic", din cauza căruia, spre exemplu, devenim atașați de librării depășite doar pentru că am investit timp îndelungat în aprofundarea și utilizarea librăriei respective.
Existența unei discrepanțe între nevoile clientului și capabilitățile platformei. De regulă clienții se decid anticipat asupra unei platforme țintă, mai ales când vine vorba despre cloud. Poate fi datorită aspectelor comerciale sau datorită unor decizii strategice la nivel de companie. În același timp, clientul expune un set clar de cerințe care trebuie îndeplinite prin construirea de software pe platforma dată. Este rolul nostru să descoperim dacă și cum putem să creăm o punte peste falia dintre caracteristicile oferite de platformă și cele necesitate de client.
În încheiere, reiterez faptul că acest articol a fost bazat pe o experiență personală. Nu este nicidecum perfect sau un model de urmat. Mai degrabă alți programatori în situații similare pot învăța din această descriere pentru a evita anumite greșeli sau obstacole.
În mod cert a fost o călătorie zdruncinată. A fost pavată cu greșeli și gafe? Sigur. Aș face ceva diferit uitându-mă înapoi? Poate. Dar cel mai important este să ne asigurăm că învățăm din greșeli și ne îmbunătățim constant.
de Lucian Mâțu
de Elena Leu
