Industria software a evoluat în ultimii 70 de ani, ajungând la aproximativ 100 de milioane de programatori. Elementele care ar sta la baza consacrării industriei software ca o profesie propriu zisă ar fi organizarea de programe educaționale specializate și crearea de asociații profesionale. Ca în oricare altă profesie, precum medicina, dreptul sau ingineria civilă, există un set de reguli și practici care au apărut din sânul comunității pentru ca apoi să fie reglementate formal și implementate de un organism oficial.
În 1945, Alan Turing, primul programator, a afirmat: "we shall need a great number of mathematicians of ability" because "there will be a good deal of work of this kind to be done" / "vom avea nevoie de un număr mare de matematicieni abili" deoarece "vom avea foarte multă muncă de acest fel" (https://www.vordenker.de/downloads/turing-vorlesung.pdf p. 11). Alan Turing a anticipat că lumea va avea nevoie de un număr mare de programatori.
În acea perioadă și în anii de după, fenomenul software a căpătat amploare la nivel mondial. Dacă în anii 1960 puteam conduce mașini sau cumpăra pâine fără a avea nevoie de un software care să medieze interacțiunea, acum lucrurile arată cu totul diferit. Omniprezența produselor software chiar și în cadrul aparatelor folosite uzual (prăjitoare de pâine, frigidere, mașini de spălat) ne poate face să ne oprim și să ne gândim la importanța modului în care este scris sau realizat acel produs software pe care îl utilizăm atât de frecvent.
La Conferința NATO de Inginerie Software din Garmisch, Germania, 7-11 octombrie 1968, experții s-au adunat pentru a defini un set de bune practici. Unul dintre participanți, Douglas Ross, care a predat primul curs de Inginerie Software la MIT, spunea: "The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from."/ "Cel mai periculos aspect când vine vorba de software este conceptualizarea, ce pare a fi universal validă, că trebuie să specifici ce urmează să faci, iar apoi să și faci acest lucru. Aceasta este sursa tuturor problemelor noastre." Totul sună foarte familiar cu ceea ce se întâmplă în ziua de azi, când cerințele și specificațiile se schimbă, iar asta presupune actualizarea codului, ceea ce aduce cu sine o serie de probleme (adică defecte).
Pentru a avea software care să funcționeze mai bine, noi, persoanele ce scriem codul, trebuie să acordăm atenție modului în care scriem cod, perspectivei din care scriem și atitudinii cu care ne aplecăm spre munca noastră.
Prezența programelor educaționale și a asociațiilor locale sunt primii pași către cristalizarea profesiei de programator. Ca în oricare altă profesie, există un set de reguli și practici care au apărut din sânul comunității pentru ca apoi să fie reglementate formal și implementate de un organism oficial.
Când spunem despre o profesie că este una cu tradiție, dincolo de suportul oferit de școli, universități sau cursuri, ne mai referim și la setul de legi, regulamente și practici la care aderă toți profesioniștii.
Evenimentele tragice ca urmare a prăbușirii aeronavelor Boeing 737-MAX8 (2018-2019) sau a erorilor de tranzacționare din cadrul Knight Capital Group (2012) au avut la origini o problemă software. De aici rezultă necesitatea stabilirii și a promovării unui set de practici la care să adere fiecare programator pentru a scrie cod care să nu dea greș, datorită faptului că a avut un design bun de la început.
Există o serie de principii propuse ca bune practici în industria software, acestea stând la baza mișcării "Software Craftsmanship" (Arta Software). Există o serie de bloguri, conferințe, întâlniri sau cărți scrise sau coordonate de Bob C. Martin (Clean Code), Andy Hunt (The Pragmatic Programmer) și Sandro Mancuso (The Software Craftsman: Professionalism, Pragmatism, Pride) pe lângă mulți alții.
În paragrafele următoare, voi descrie un set posibil de principii la care noi programatorii am putea adera, toate consacrate de literatura curentă.
O putere mare presupune și o responsabilitate mare. Trebuie să fixăm limite și standarde pentru comportamentul nostru, ceea ce înseamnă că avem puterea de a aduce o schimbare pozitivă de care vom beneficia cu toții.
Ce putem face cu puterea pe care o avem?
Să zicem că trebuie să livrăm o anume funcționalitate și nu avem timp să rulăm toate testele manuale pe toate componentele afectate, deoarece vom rata termenul limită. În acest moment, ar trebui să înștiințăm factorii decizionali cu privire la riscurile la care se expun dacă nu se rulează testele manuale, fiind conștienți că vor fi deranjați de faptul că livrarea se va face cu întârziere. Nu ar trebui să mergem pe scurtături. Ar trebui să rulăm testele manuale pentru a identifica proactiv defectele posibile.
La o companie la care am lucrat, eram gata să livrăm mecanismul de criptare al datelor personale, mecanism care trebuia să se aplice atât in-transit cât și at-rest. Mecanismul de criptare trebuia aplicat în toate cele trei centre de date de pe trei continente. Am implementat, testat și validat funcționalitatea în mediul nostru de integrare continuă și totul era pe verde, era bine.
Am decis să aplicăm schimbările în centrul de date din SUA într-o perioadă cu trafic redus. Lansarea s-a desfășurat conform planului, iar funcționalitate a ajuns live. Am continuat cu centrul de date din Asia. Și de data aceasta totul a mers foarte bine. Apoi, am trecut la centrul de date din Europa unde am ales o perioadă cu trafic redus, noaptea.
Aici am întâmpinat erori, deoarece ingestia de date părea să nu poată aplica criptarea pentru unele interogări efectuate (requests). Am făcut rollback. A durat mai mult de 24 de ore ca să ajungem la starea de dinainte de lansare. Ne-am grăbit să investigăm, să găsim o soluție și am mai încercat o dată. Am eșuat, dar am reușit să restabilim bazele de date mai repede de tura aceasta.
În cele din urmă, echipa a găsit problema. Era o problemă de tip data sharding, deoarece infrastructura din centrul de date din Europa avea un cache Redis cu mai multe instanțe shards pentru distribuirea sarcinii (load distribution), în timp ce celelalte centre de date aveau o singură instanță Redis. Am reușit să facem instalarea în toate cele trei centre de date.
În acest caz, costurile asociate problemei au fost echivalentul câștigurilor noastre pe o zi. Puteam preveni situația dacă testam totul într-un mediu similar cu cel de producție care să aibă configurația corectă (staging sau pre-production).
Prejudiciem funcționalitățile produsului software când introducem defecte. Prin urmare, dacă suntem profesioniști adevărați nu ar trebui să introducem defecte. Este imposibil să scriem software perfect, dar asta nu înseamnă că nu suntem responsabili de potențialele imperfecțiuni. Trebuie să ne asumăm imperfecțiunile pe care le creăm. Un profesionist trebuie să își asume erorile, chiar dacă acestea sunt inevitabile. Trebuie să recunoaștem când greșim și să ne cerem scuze. Scuzele sunt necesare, dar insuficiente.
Pe măsură ce deveniți mai maturi, numărul de erori ar trebui să tindă spre zero. Nu va fi zero niciodată, dar este responsabilitatea noastră să tindem spre zero.
Când facem release inițial sau de versiune nouă, ne-am dori ca cei din echipa QA să nu găsească probleme.
Este neprofesionist să trimitem cod către echipa de QA, știind că avem erori în cod. Ce înseamnă să avem cod defect? Orice cod de care nu sunteți sigur că e bun! Nu trimiteți cod netestat de voi echipei QA. Echipa QA va găsi defecte, cel mai probabil, deci ar trebui să ne cerem scuze, dar și să încercăm să înțelegem de ce s-au întâmplat aceste erori ca să nu le mai repetăm.
Cum știm că avem un cod funcțional? ... Testându-l în multe scenarii.
Unele bucăți de cod sunt greu de testat, deoarece așa au fost gândite. Soluția este de a crea cod care este ușor de testat.
Mike Cohn a propus metafora Test Pyramid (Piramida Testării) pentru a arăta câte teste ar trebui efectuate în fiecare categorie și cât durează acestea ca timp de execuție.
Unit tests (testele la nivel de unitate) - aceste teste durează de la câteva milisecunde la câteva secunde, putând rula în IDE.
Integration/System tests (testele la nivel de integrare/sistem) - acestea sunt teste de integrare a componentelor, rolul lor fiind de a asigura că totul funcționează conform așteptărilor când toate componentele sunt aduse împreună.
UI Tests/End to End tests (testele la nivel de UI/ciclu complet) - aceste teste durează mai mult, testând interfața expusă utilizatorilor, în scenarii complete și diverse. Pot dura câteva minute sau câteva zeci de minute.
Testele manuale și regresia sunt necesare pentru tot ce nu se poate automatiza.
Sursă imagine: https://www.ministryoftesting.com/dojo/lessons/the-mobile-test-pyramid
Structura codului dictează cât de flexibil este acest cod. Dacă structura este compromisă, și viitorul va fi la fel. Principala presupoziție a tuturor proiectelor software este că este simplu să schimbi software-ul.
Schimbările trebuie să poată fi făcute fără costuri exorbitante. De fiecare dată când te uiți la un modul, poți face modificări mici pentru a-i îmbunătăți structura. De fiecare dată când citești codul, îi ajustezi structura.
Există tooluri care fac analiză statică pe codul sursă și care pot arăta complexitatea codului, putând fi integrate în build pipelines pentru a preveni introducerea de cod viciat. - SONARQUBE
Acest fapt este în dezacord cu modul în care majoritatea oamenilor tratează software-ul. Mulți consideră că a face o serie de schimbări continue la nivel de cod este periculos. Nu! Ceea ce este cu adevărat periculos este să permiți unei componente software să rămână statică. Dacă nu o flexibilizezi, când va trebui să o schimbi, vei constata cât de rigidă este.
De ce se tem programatorii să aducă schimbări continue codului lor? Se tem să nu strice ceva! De ce se tem să nu strice ceva?
Sursă imagine: https://it.wikipedia.org/wiki/Spaghetti_code#/media/File:Spaghetti.jpg
Nu au teste.
Dacă ai o suită de teste automate care acoperă aproape 100% din cod, iar această suită poate rula ușor, oricând, nu vă va fi frică să schimbați codul. Cum puteți dovedi că nu vă este frică să schimbați codul? Îl schimbați în permanență.
Pentru a progresa în carieră, va trebui să fiți responsabili și să vă mențineți competențele la zi. Nu este responsabilitatea angajatorului să vă formeze, să vă trimită la conferințe sau să cumpere cărți. Voi sunteți responsabili de acest aspect. Profesioniștii investesc în profesia lor.
Timpul petrecut la companie este pentru a rezolva problemele companiei. În timpul vostru liber, puteți să vă perfecționați citind articole, cod open source sau ascultând un podcast în pauza de prânz sau când sunteți în trafic.
Un programator profesionist trebuie să cunoască și să descrie șabloanele din "Gang Of Four", dar și să poată da sfaturi referitoare la care șablon trebuie folosit în care situație. Trebuie să cunoașteți care sunt principiile SOLID și beneficiile lor asociate. Scrum, Agile, Kanban, Waterfall sunt metodele de livrare software cu care trebuie să fiți familiarizați. Folosiți TDD și/sau scrierea de unit tests, design Object-Oriented, Structured Programming, Continuous Integration, Continuous Development, Pair Programming. Trebuie să cunoașteți următoarele metode de realizare a diagramelor: UML, C4, Structure Charts, flow charts, decision tables.
Trebuie să vă stăpâniți meseria, să vă specializați în ceea ce privește tehnicile, toolurile, terminologiile și ideile vehiculate în dezvoltarea software.
Deși progresele din acest domeniu sunt rapide, continuăm să scriem cod cu IF și FOR, cum se făcea acum 60 de ani. Sunt încă mult proiecte livrate cu prin metodologia Waterfall, dar trebuie să înțelegem punctele forte și punctele slabe ale acestei abordări.
"Those who cannot remember the past are condemned to repeat it."/ "Cei care nu își amintesc trecutul sunt condamnați să îl repete."- George Santayana, The Life of Reason, 1905
Dacă ne uităm la alte profesii, de exemplu doctor sau avocat, trebuie să fie la curent cu ultimele studii din jurnalele de specialitate, cu ultimele legi promulgate, cu situațiile precedente, pentru a oferi soluții pacienților și clienților.
Același lucru trebuie să îl facă și programatorii pentru a oferi cea mai bună soluție din cele disponibile pe piață.
Să citim cărți, articole, bloguri, tweets. Să participăm la conferințe și întruniri. Organizați-vă în grupuri de studiu cu colegi sau prieteni în care să parcurgeți cărți tehnice. Să învățăm lucruri ce ne scot din zona de confort. Dacă știți .NET, învățați Python. Dacă știți Java, învățați Ruby sau PowerShell.
Exersați dincolo de mediul pus la dispoziție de angajator. Așa cum un alergător profesionist face exerciții zilnice pentru a se menține în formă, tot așa și noi ne putem antrena pentru a ne îmbunătăți sau aprofunda competențele.
Faceți code katas, exerciții de programare simple care se rezolvă scriind o metodă sau o funcție. Scopul code katas este de a vă antrena mintea și mușchii pentru a scrie soluții pe care le știți deja. Unele dintre cele mai obișnuite katas sunt: fizz-buzz, factori primi și multe altele pe care le puteți accesa pe www.codewars.com
Scrierea de cod este un efort de echipă la care participă mulți oameni implicați în rezolvarea cerințelor de business. Trebuie să colaborați cu colegii. Programați împreună, planificați împreună, faceți design împreună.
Dacă aveți o atitudine deschisă față de colegi și sunteți dispuși să învățați unii de la alții, veți finaliza totul mai repede cu mai puține defecte. Colaborați cu colegii QA, analiștii de business, experții UI/UX.
Colaborați cu cei din alte echipe de asemenea, spuneți-le ce provocări aveți și cum le-ați putea rezolva.
Spuneți-le colegilor juniori ce știți, fiți mentori pentru ei. Astfel, vă puteți structura informația pe care o știți mai bine, iar transmițând-o mai departe o veți înțelege chiar mai aprofundat. Spuneți-le ce ați învățat din greșeli, ca ei să nu le repete.
Ajutați colegii noi să înțeleagă ce au de făcut în companie. Puneți-vă la dispoziția lor - oferiți-le un plan de învățare, ghidați-i și lucrați împreună.
Se spune că cea mai bună metodă de a învăța ceva este de a preda acel lucru, deci și voi veți beneficia de pe urma acestei experiențe.
Învățați despre domeniul de business pentru care creați software. Încercați să înțelegeți logica cerințelor. Cu ce probleme de business se confruntă utilizatorul final?
Simon Sinek ne arată în cartea sa Start with why cât de important este să mergem dincolo de "Ce faci" și "Cum faci". Să te întrebi mai degrabă de ce faci ceea ce faci și care este scopul muncii tale.
De ce muncești? De ce te trezești dimineața ca să mergi la birou? O faci pentru a scrie cod? Este ușor să spui cuiva la ce lucrezi. Unii știu să facă ceea ce fac foarte bine, dar unii nu știu. Care este misiunea noastră când scriem cod?
Trebuie să mergeți mai departe și să nu vă limitați doar la a implementa un user story pentru a scăpa de el. Dacă lucrăm în contabilitate, trebuie să știm cum funcționează acest domeniu. Dacă lucrăm în publicitate, la fel.
Înțelegând domeniul, chiar dacă nu la nivel de expert, veți propune soluții mai bune și veți înțelege mai bine cerințele de business.
Când intrați într-o echipă nouă sau sunteți nou într-un domeniu, citiți o carte despre acest lucru. Dacă există sesiuni înregistrate cu utilizatorii, urmăriți-le. Puneți întrebări și căutați experți cu care să aveți discuții.
A scrie cod, urmând niște specificații orbește, fără a înțelege cerința de business nu este un semn de profesionalism. Cunoscând domeniul, puteți identifica greșeli sau provocări în cerințe. Ar trebui să vă ajutați colegii ce sunt analiști de business sau manageri de proiect, ca aceștia să înțeleagă mai bine implicațiile deciziilor lor.
Un profesionist va manifesta empatie față de angajator și de problemele cu care se confruntă. Dacă clienții voștri au provocări, înțelegeți-le.
Nu gândiți în termeni de noi vs. ei, deși este cel mai ușor să faceți asta. Manifestați respect!
"The competent programmer is fully aware of the strictly limited size of his skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague"/ "Programatorul competent este complet conștient de dimensiunea limitată a creierului său; prin urmare, abordează programarea cu modestie și evită șmecheriile cu orice preț" afirmă Edsger W. Dijkstra în eseul The Humble Programmer.
Modestia nu este menită să ne suprime opiniile sau să ne facă să ne simțim neînsemnați. Un programator profesionist își va aminti că uneori munca lui nu va fi încununată de succes, că vor fi defecte, dar că asta nu îl va împiedica să își asume greșelile și să învețe din ele.
Modestia ne permite să învățăm de la alți colegi și să fim dispuși să oferim ajutor celor care se află în dificultate.
Este ușor să devii arogant când știi că lucrezi la proiecte de top, dar asta nu îți va aduce beneficii. Te va împiedica să pui întrebări și te va determina să respingi soluțiile celorlalți, pentru că nu sunt ale tale.
Un programator profesionist nu va avea un comportament toxic în interiorul echipei sau al companiei unde lucrează, știind că acea atitudine nu îl va duce departe.
Doresc să închei cu un citat din cartea lui Sandro Mancuso "The Software Craftsman" unde spune că a fi profesionist "is more than being a good developer who writes code well and delivers business value. It's a lifestyle. It's a life where we choose to do things well, to be the best we can be. It's a life where we are prepared to make some sacrifices to learn and help others to learn the craft. It's a life of continuous dedication to the art of writing code."/ "înseamnă mai mult decât a scrie cod bine și mai mult decât a aduce valoare de business. Este un stil de viață. Este o viață unde alegem să facem lucrurile bine, unde alegem să fim cei mai buni. Este un stil de viață pentru care suntem dispuși să facem niște sacrificii pentru a învăța și a-i ghida pe ceilalți să învețe acest meșteșug. Presupune dedicare continuă artei de a scrie cod."
