Dezvoltarea software nu e (doar) cod
Cei mai mulți oameni cred că, dacă faci dezvoltare software, înseamnă că scrii cod.
Și asta e tot, aici se oprește domeniul tău de activitate.
Ideea asta vine și de la modul în care sistemul de educație formează viitorii programatori, încă de la primul contact cu informatica.
Școala îi învață pe elevi că informatica și programarea reprezintă modul prin care poți rezolva probleme matematice, în mare parte, folosind cod.
Toate concursurile și examenele prin care trec elevii în anii de școală sunt cu probleme ale căror cerințe nu diferă mult de cele dintr-o culegere de matematică.
Asta îi face pe viitorii ingineri software să creadă că asta va presupune jobul lor, să rezolve probleme matematice abstracte și izolate prin cod.
Că optimizarea algoritmilor și structurilor de date folosite este ceea ce îi diferențiază pe cei mai buni de cei mai slabi.
Din păcate, dezvoltarea software nu e doar cod.
Și vreau să-ți și argumentez de ce cred asta, ca să nu crezi că e doar o vorbă goală.
Aplicația cu o singură clasă
O să încep printr-o mică poveste relevantă.
La un job anterior, am lucrat pe un proiect cu un context destul de complicat. O companie cu un sistem de gestiune mamut avea nevoie să-l spargă în două și să mute jumătate din operațiunile curente într-un alt sistem nou implementat.
Problema era că aceste sisteme nu se puteau integra direct prin propriile interfețe și servicii, așa că a fost nevoie să dezvoltăm un fel de “pod”, de legătură între ele, care să sincronizeze datele dintr-o parte în alta.
Companie cu mii de angajați și operațiuni de milioane de euro lunar, deci activitatea prin sistemele astea ar fi fost una destul de intensă, așa că era nevoie ca acest serviciu, care urma să facă sincronizarea, să fie extrem de solid, altfel ar fi cauzat întreruperi de operațiuni care ar fi costat enorm.
O altă echipă a companiei la care lucram atunci a început să lucreze destul de intens la acest serviciu.
Multe ședințe, multe discuții, dar și mult progres, din ce auzeam, nu văzusem niciodată codul.
După mai bine de un an de lucru, pentru că aveau nevoie de ajutor, urma să fiu implicat și eu pentru câteva luni.
Prima dată când am deschis codul proiectului, îmi aduc aminte și acum, mi s-a părut interesant, pentru că era complex.
Era complex pentru că tot codul fusese scris să fie înțeles doar de cel care l-a scris inițial.
Și era tot într-o singură clasă, un singur fișier de cod, adică. Câteva zeci de mii de linii de cod.
Pentru că eram mai începător atunci, aveam impresia că asta e vreo practică pe care eu nu o înțeleg, un design pattern, un tip de arhitectură.
Trebuia să fie, altfel de ce ai scrie codul așa, nu?
Proiectul a funcționat în cele din urmă și funcționează și azi pe serverele companiei respective.
Fără arhitectură, fără object oriented design, fără vreun fel de structură sau sens, funcționează, dar are costuri ascunse la care mulți nici nu se gândesc, până într-o zi, când nota de plată pentru astfel de abordări va costa mai mult decât proiectul în sine.
Îți spun toate astea ca să înțelegi că dezvoltarea software nu e doar cod, e și un set de principii care fac codul ăla să fie ușor de înțeles, ușor de extins, ușor de modificat, ușor de reparat atunci când apare o problemă.
Calitatea codului
Calitatea codului e unul dintre indicatorii care atârnă cel mai greu în procesul de dezvoltare software.
Pentru că niciun sistem nu rămâne pe viață așa cum a fost scris inițial, fără vreo modificare.
Sistemele software sunt actualizate extrem de des, iar succesul acestor actualizări este extrem de dependent de calitatea codului lor.
Dacă ai un sistem ca cel pe care ți l-am descris anterior, care crezi că sunt șansele ca o modificare în cod să strice ceva în modul de funcționare? Îți spun eu, cele mai mari.
Chiar și dacă modificarea e făcută de același dezvoltator, riscul tot e mare.
Și atunci, ca să reduci riscurile de a cauza probleme, ca dezvoltator software, te bazezi pe seturi de reguli și principii care să-ți mențină codul curat și să te ajute să extinzi sau să modifici sistemul respectiv fără să-ți pierzi mințile la fiecare linie de cod.
E ca atunci când construim o clădire, trebuie să ne gândim întâi la structura de rezistență, pentru că altfel ne vom bucura de ea doar până la primul cutremur.
Regulile pe care te bazezi și deciziile pe care le iei atunci când dezvolți un sistem software sunt similare.
Sigur, e mult mai rapid să scrii codul fără să-ți pese de asta, dar ce te faci când apare o problemă și va trebui să faci debugging într-un cod din care nu mai înțelegi nimic?
O problemă care ar fi fost simplă de rezolvat într-un cod bine organizat și ți-ar fi luat 30 de minute să găsești sursa și să o repari, acum îți ia două zile, dar ai rezolvat-o introducând o altă problemă fără să-ți dai seama și, câteva zile mai târziu, povestea se repetă.
Vezi ce ziceam mai devreme despre costuri ascunse? Cam așa arată.
Contextul activității de dezvoltare software
Atunci când lucrezi într-o companie, fie o corporație multinațională, fie o firmă mai mică, controlul tău asupra a ceea ce se întâmplă în companie e unul foarte limitat spre 0.
Unde ai, în schimb, control absolut e în codul sursă al sistemului pe care îl dezvolți.
Codul sursă trebuie să fie locul unde ai cea mai multă claritate, într-un mediu în care lucrurile se desfășoară haotic.
Companiile, în special cele mari, operează haotic. Poate la nivel înalt lucrurile sunt mai clare, dar de obicei, la nivelul echipelor tehnice vin multe solicitări, de multe ori în contradictoriu.
Vin multe migrări de infrastructură, de exemplu, care afectează indirect aplicația la care lucrezi.
Vin schimbări și decizii care nu îți vizează proiectul în mod direct, dar care influențează oricum și trebuie să poți reacționa fără să cauzezi impact negativ.
Vin solicitări pentru dezvoltări noi, de cele mai multe ori de la oameni complet non-tehnici, care nu înțeleg complexitățile și provocările tehnice, dar trebuie să înveți cum să le tratezi, să le răspunzi și să influențezi aceste solicitări pentru a păstra proiectul pe direcția bună din punct de vedere tehnic.
Peste toate astea, trebuie să te asiguri că sistemele funcționează 24/7 și orice actualizare de producție are impact operațional minim, indiferent de situație.
Iar lucrurile astea nu le poți obține decât dacă ai luat cele mai bune decizii tehnice în trecut, altfel totul va fi un calvar.
Sper ca această mică fereastră în ceea ce înseamnă dezvoltare software să te ajute să-ți construiești o imagine mai bună a ceea ce urmează să faci, pe lângă programare.
Programarea este importantă, dar e o mică parte. Mie îmi place să cred că abilitatea de a scrie cod e precum cuțitul pentru un bucătar. Faptul că poți să scrii cod rapid și care să meargă nu înseamnă că ai un sistem software calitativ, așa cum nici faptul că un bucătar are un cuțit de calitate și știe să-l folosească nu face ca mâncarea rezultată să fie neapărat bună.
Atât pentru azi, pe data viitoare.