Noi am evoluat ca specie cu un aliat de nădejde: uneltele. Dacă nu le-am fi creat, ne găseam sfârșitul într-o savană, pe undeva într-un loc frumos. Azi, în programare nu doar că ne folosim de scule - IDE-uri, lintere, servere CI - ci și automatizăm utilizarea lor aproape tot timpul. IDE-urile îți spun în timp ce tastezi dacă ai greșit sau nu, avem integrări cu JIRA care marchează sarcini ca terminate în funcție de alte automatizări, primim notificări pe mail și Slack. Mai pe scurt, azi automatizăm o grămadă de procese și comportamente umane.
În această afacere trebuie adus aminte că programarea e o treabă utilitară. Ai o problemă, o rezolvi - e doar bun simț până aici. În câteva cazuri, poți să o rezolvi cu ajutorul unui program pe calculator. (Dacă ai acces la un programator probabil vor fi prea multe probleme.) În alte câteva cazuri, când ai o sarcină neplăcută și repetitivă, merită să rezolvi această problemă- ghici prin intermediul a ce?- tot cu programe. Sunt extrem de puține cazurile de "artă pentru artă" în care programele pe calculator produc valoare prin ele însele. Concret, le-aș limita la cele posesoare de inteligență artificială și la cele care augmentează relațiile interumane.
Revenind la faptul că automatizarea, în special în medii virtualizate, se face tot prin programe pe calculator, aterizăm taman în miezul problemei. Absolut orice program are cerințe (sau un scop pentru care e construit, vezi mai sus) - la fel și automatizările. Absolut oricărui program i se cuvine mentenanța - la fel și automatizărilor. În contextul rezolvării unei probleme, automatizarea reprezintă în cel mai bun caz un nivel de abstractizare în plus. În cel mai rău, reprezintă o spirală a neputinței de-a rezolva problema inițială, prin care se recurge la soluții derivate tot mai complicate. Sunt cazuri complicate, pentru rezolvarea cărora se apelează la unit tests, integration tests sau la alte lucruri care au nevoie de cunoaşterea intimă a ceea ce se testează pentru ca să funcționeze. Iar pentru cazul cel mai fericit vorbim despre alegerea clasică dintre topor și drujbă. Ambele produc același rezultat. Drujba e mai nouă, dar face mizerie, consumă mai mult, face zgomot și trebuie întreținută. De ce- vă întreb- ne place atât de mult sunetul drujbei?
Istoric, tehnologia informației diferă mult de programare prin perspectiva deservirii nevoilor fundamentale umane. Tehnologia informației a deservit-o pe cea de apărare. Ca să ne înțelegem: fără semnale de fum, fără porumbei mesageri, fără poștalion cum am fi știut dacă ne calcă turcii? În contextul acesta, cred că vestirea rezultatului bătăliei de la Maraton a fost și-ar trebui să rămână o experiență singulară. Și dacă tot vorbim de comunicare, veți observa că n-am menționat nimic despre e-mailurile publicitare sau SPAM. Sper ca aceste repere să delimiteze îndeajuns de clar punctul propriu de vedere cu privire la utilitatea tehnologiei informației.
Interesant este că azi tehnologia informației se leagă aproape în totalitate de software (știți voi… programele care compun stiva TCP a oricărui sistem de operare sau cele ce procesează datagrame, IPTV etc). Tot interesant e că noi comunicăm mai gălăgios ca niciodată: se schimbă între persoane mai multă informație decât s-a schimbat vreodată. În aceste circumstanțe software-ul capătă o răspândire ubicuă. Sfera informațională de azi este similară cu biosfera atât ca întindere, cât și ca pătrundere. Dacă ne aducem aminte de aspectul legat de siguranță, înțelegem că vorbim despre o forță care formează și va forma omenirea. Așadar, automatizarea trebuie făcută în mod responsabil.
Pe de altă parte, programarea permite rezolvarea unor probleme abstracte, cum ar fi cele legate de gestionarea proceselor de reglementare a instituțiilor financiar-bancare prin folosirea tehnologiei. Termenul în engleză care desemnează aspectul acesta este regtech. Aceste probleme presupun existența unui sistem bancar și a unor reglementări a căror aplicare nu poate fi impusă sau supervizată de către persoane fizice sau instituții, astfel încât devin necesare tehnologii dezvoltate taman în acest sens. Aceste reglementări au scopul de a opri fenomene care la rândul lor sunt complexe și abstracte cum ar fi corupția- acum înțelegeți de ce în România aceste tehnologii se întâlnesc cel mult sporadic- , spălarea de bani sau terorismul. Programarea este unică prin faptul că permite și abordarea acestui tip de probleme, de exemplu, prin folosirea inteligenței artificiale. Așadar, ca programatori rezolvăm probleme abstracte și, prin urmare, complexe. Coroborând complexitatea cu răspândirea ubicuă a software-ului, putem spune că este extrem de dificil să identificăm cu exactitate problema pe care o rezolvăm, darămite să avem pretenția că o rezolvăm corect.
Hai să luăm un exemplu simplu și cunoscut: Facebook. Nimeni nu se aștepta ca rușii să creeze o mașinărie de fraudare a alegerilor folosindu-se de Facebook. De ce? Pentru că atunci când vrei să te vezi cu foștii colegi de liceu, genul ăsta de lucruri nu-ți trec prin cap. Ei au exploatat faptul că modul în care relaționăm între noi ca oameni s-a schimbat fundamental odată cu Facebook. Facebook a automatizat mai multe primitive de comunicare interumană precum găsirea unui loc de întâlnire, inițierea conversației etc. Ca atare, a devenit ușor să mimezi comunicarea reală: spațiul problemei de a determina o persoană aievea s-a redus considerabil. Folosind automatizări create cu cele mai bune intenții au fost automatizate comportamente reprobabile: știri false, rasism, ură religioasă sau interetnică.
Dar în fond ce treabă avem noi cu Facebook, cu stadioanele la Euro sau cu turcii? Haideți să ne gândim atunci la toate acele teste care trec în CI și nu surprind defectul care invariabil apare doar în producție. Poate aceasta nu i se întâmplă oricui și ar fi mai bine să ne gândim la erorile de linting sau avertizările compilatorului tratate cu indiferență. Ce-i drept, sunt doar avertismente și pot fi ignorate, dar atunci de ce le mai avem? În fine, pentru mine, cel mai aproape de suflet este rebalansarea automată a unui cluster în funcție de caracteristici ale aplicației, care, evident, sunt înlăturate la un moment dat. Toate aceste exemple ne arată cât de nepregătiți suntem să automatizăm procese din cauza imposibilității de a înțelege problemele pe care vrem să le rezolvăm.
Ca să mai scăpăm de complexitatea inerentă oricărei soluții software moderne, suntem tentați să împărțim problemele mari în probleme mai mici. În fond, putem să ne menținem atenția concentrată cel mult 20 de minute. Neil Postman afirmă că odată puși în fața ecranelor, se scurtează intervalul de timp care ne menținem concentrați asupra unui subiect anume. Așa că ajungem să împărțim problemele inițiale care sunt prea mari în probleme tot mai mici. De altfel, avem și modele arhitecturale care încurajează aceasta. O dată cu rezolvarea problemelor mai mici, sperăm să rezolvăm și problema inițială. Însă uităm că lucruri diferite se dezvoltă în ritmuri diferite și că există impedanță la integrarea oricăror două soluții. Când ne dăm seama că integrarea părților reprezintă o problemă, e tardiv să mai găsim soluții. Suntem introduși fără voia noastră în monoliți, microservicii, biblioteci și funcții lambda până peste cap. În punctul acesta, încercăm să automatizăm aproape toate procesele pentru a putea gestiona complexitatea ansamblului. Ceea ce observăm la final e că nu mai avem aceeași libertate de a crea, întrucât fără rigoare automatizările noastre devin mai greu de întreținut decât soluția în sine. Repet: avem modele arhitecturale care propovăduiesc acest marasm.
Și atunci? Automatizarea e greșită?
Răspunsul meu este un evident "nu". Automatizarea, ca și uneltele înaintea ei și oamenii dinaintea uneltelor, a evoluat pentru a umple un gol. De asemenea, similar uneltelor și oamenilor, automatizarea amplifică efectele proceselor automatizate - spre bine sau rău. Așadar, înainte de a automatiza, trebuie să înțelegem cu exactitate ce parte a cărui proces o automatizăm. Iar înainte de aceasta, trebuie să înțelegem fundamentele, utilitatea a ceea ce facem. În caz contrar, sunt șanse bune să automatizăm comportamente umane reprobabile sau chiar dezumanizarea noastră, să diminuăm creativitatea, să suportăm costuri mai mari de întreținere, să acționăm doar din panică sau să cădem în spirale ale neputinței.
Pentru că automatizările sunt aplicații software, absolut toate premisele dezvoltării unor aplicații sunt valabile şi pentru automatizări, de la cerințe până la deployment. Este nevoie să înțelegem cerințele de funcționare ale unei automatizări, utilitatea ei, cum verificăm dacă e corectă sau mediul în care va rula. Spre exemplu, pentru a verifica automat funcționalitatea unei aplicații, avem nevoie de o altă aplicație care o testează în mod automat. Aplicația care verifică soluția noastră este la rândul ei o soluție care trebuie întreținută și instalată într-un mediu în care va funcționa. Are nevoie de niște cerințe de funcționare - ca și orice altă aplicație. Codul trebuie să fie la fel de inteligibil și să respecte aceleași standarde de calitate ca și ale oricărei alte aplicații.
În final, enumăr câteva automatizări pe care le-am găsit benefice:
Automatizarea testelor de regresie sau acceptare la nivel de sistem;
Generarea de instabilitate în mod haotic în mediile de producție;
Rularea automată a testelor la fiecare commit;
Verificarea automată a respectării contractelor între servicii;
Generarea automată a documentaţiei API-urilor;
Analiza automată a codului pentru a corespunde unor standarde;
Verificarea şi impunerea standardelor cu privire la formatul mesajelor de commit;
Exemple sunt, desigur, mai multe decât cele menționate mai sus. Repet doar că, fără diligență, automatizarea e ca o drujbă: consumă mai mult, face zgomot, trebuie întreținută și , în final, nu e benefică în vreun fel.
Masaaki Imai, "Gemba Kaizen: A Commonsense Approach to a Continuous Improvement Strategy, Second Edition", ISBN-13: 978-0071790352, McGraw-Hill Education; 2 edition (June 13, 2012)
Eliyahu M. Goldratt, Jeff Cox, "The Goal: A Process of Ongoing Improvement", ISBN-13: 978-0884271956, North River Press; 30th Anniversary Edition edition (June 1, 2014)
Neil Postman, "Amusing Ourselves to Death: Public Discourse in the Age of Show Business", ISBN-13: 978-0143036531, Penguin Books; Anniversary edition (December 27, 2005)
Robert C. Martin, "The Clean Coder: A Code of Conduct for Professional Programmers", ISBN-13: 978-0137081073, Prentice Hall; 1 edition (May 23, 2011)