ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 148
Numărul 147 Numărul 146 Numărul 145 Numărul 144 Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 91
Abonament PDF

Când automatizăm degeaba

Andrei Olar
Software Architect @ ComplyAdvantage



PROGRAMARE

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:

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.

Referințe

  1. 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)

  2. 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)

  3. 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)

  4. Robert C. Martin, "The Clean Coder: A Code of Conduct for Professional Programmers", ISBN-13: 978-0137081073, Prentice Hall; 1 edition (May 23, 2011)

  5. Michael T. Nygard, "Release It!: Design and Deploy Production-Ready Software 2nd Edition", ISBN-13: 978-1680502398, Pragmatic Bookshelf; 2 edition (January 18, 2018)

Conferință TSM

NUMĂRUL 147 - Automotive

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects