TSM - Haos, meme și tipare de design software

Ariel Pontes - Python Developer @3 Pillar Global

Codul tău nu este DRY/ SOLID/ lizibil/ușor de întreținut. API-ul nu este RESTful. Nu respecți principiul "spune, nu întreba". Codul tău nu este bine documentat. "Comentariile inline miros a probleme". Codul nu este eficient. "Optimizarea prematură este sursa tuturor relelor." Nu ai nevoie de o bibliotecă pentru această funcționalitate; ar trebui să eviți "sincronizarea tehnologică". "Nu reinventa roata."

În această colecție de enunțuri regăsim câteva din principiile și filozofiile care au guvernat în dezvoltarea software. Unele par să le contrazică uneori pe altele, iar dezbaterile pe aceste teme sunt adesea încinse și dezvăluie un anumit nivel de încăpățânare și un fel de primitivism de toate părțile. Putem găsi argumente tehnice pentru a le rezolva?

În acest articol încerc să ofer o privire de ansamblu asupra tiparelor de argumentare care apar adesea din astfel de discuții și să examinăm de ce este atât de dificil să găsim răspunsuri decisive.

Argumente tipice

Apelul la autoritate

Ajunși într-un impas, este un lucru comun să facem apel la autoritate - Renumitul dezvoltator John Doe sprijină acest framework/ principiu/ această bibliotecă/ etc., deci trebuie să fie bun! Acesta nu este un argument decisiv, dar are un anumit grad de legitimitate. Un dezvoltator cu experiență este probabil antrenat să evalueze cel puțin calitățile mai obiective ale unei tehnologii sau ale unui demers.

Apelul la comunitate

O altă variantă a apelului la autoritate este apelul la comunitate, similar cu apelul la mase, dar cu diferența că aria sa este restricționată la comunitatea dezvoltatorilor și nu la populație în general. Aceasta aduce o îmbunătățire față de celălalt argument deoarece, chiar dacă noul trend este imperfect, toată lumea știe că este mult mai bine să lucrezi utilizând tehnologii având o comunitate puternică în spate. Dar a presupune că popularitatea unui trend indică întotdeauna superioritatea sa, este nerealist.

Negarea subiectivității

Inginerilor le este teamă de subiectivitate, iar acest lucru ne face ocazional să ne expunem la a cădea victime efectului de fals consens. Adevărul este că ingineria software este, de fapt, o activitate foarte socială. Programarea în limbaje de nivel înalt este, la urma urmei, o modalitate de comunicare nu numai cu computerele, dar și cu alți programatori. De aceea, nu ar trebui să fie o surpriză că concepte precum "lizibilitatea", care sunt în fond strâns legate de intuiția umană și care pot diferi de la individ la individ, joacă adesea un rol decisiv în hotărârea dacă un tipar este sau nu îmbrățișat de industrie, OOP și MVC fiind exemple destul de ilustrative. Din păcate, deși se dezbate mult pe această temă, prea puțină cercetare se face de fapt în legătură cu potrivirea anumitor tipare de design la aspectele universale ale cunoașterii umane, ca să nu mai vorbim de publicare.

Dar ne este jenă să recunoaștem acest lucru. Și atunci, ce facem? Trăim în negare. Evităm termeni precum "personalitate" și "intuiție" și preferăm termeni pseudo-obiectivi precum "lizibilitate" și "mentenanță". Începem chiar să credem că afirmații de genul "X este mai lizibil decât Y" spun ceva obiectiv despre natura realității. Acest lucru nu înseamnă că un consens nu este niciodată real. Oricine este sănătos la cap va fi de acord că înțelegerea unui serviciu web complex, scris într-un singur fișier cu milioane de linii, este cel puțin o provocare intelectuală serioasă chiar și pentru cel mai experimentat dezvoltator. Dar este important să ținem minte că și cele mai intuitive adevăruri pentru o persoană pot uneori să pară prostii altcuiva.

Știința incertitudinii

Deci aceste argumente nu sunt decisive, dar cu siguranță există altele mai bune. Știința ne poate spune întotdeauna care este cel mai bun lucru de făcut, nu-i așa? Nu întotdeauna…

Memetica

Nu, nu este vorba despre memele de pe internet. Memetica este un câmp de cunoaștere interesat de cum ideile se răspândesc și se adaptează drept răspuns la forțele selecției naturale. Ființele umane sunt o specie socială care a evoluat spre a învăța prin observație și a copia comportamentul celorlalți. Aceasta ne-a permis să acumulăm cunoștințe într-o măsură la care nicio altă specie nu a visat, dar de asemenea ne-a făcut vulnerabili la paraziți culturali: tradiții care nu servesc vreunui scop rațional, dar care totuși sunt copiate din generație în generație, uneori fără a lua în calcul toate aspectele.

"Exemple de meme sunt melodii, idei, expresii clișeu, modă la îmbrăcăminte, feluri de a face oale sau de a construi arcade. La fel cum genele se propagă ele însele în fondul genetic prin saltul de la un corp la altul via spermatozoizi sau ovule, tot așa și memele se propagă în fondul memelor prin saltul de la un creier la altul via un proces care, în sensul larg, poate fi numit imitație." - Richard Dawkins, "Gena egoistă"

Ceea ce vreau să subliniez este faptul că trendurile în codare sunt doar un alt exemplu de meme. Atunci când vine vorba de Darwinism, unii se gândesc poate la "selecția naturală" și sunt tentați să concluzioneze că memetica confirmă că trendurile cele mai populare sunt de fapt cele mai bune. Acest lucru este incorect din mai multe motive:

A fi "sănătos" înseamnă "a fi cel mai bun pentru înmulțire" și nu "a fi cel mai bun pentru a ne ajuta să ne atingem scopurile". Uneori acestea coincid, alteori nu. Nicio specie nu e superioară alteia într-un sens absolut. A fi cel mai bun înseamnă să fi cel mai adaptat la un anumit mediu, iar mediile sunt în continuă schimbare. În ecologia organismelor vii, aceste schimbări au loc pe parcursul sutelor sau miilor de ani. În ecologia ideilor, acestea se pot întâmpla în ani sau chiar zile. Evenimente exterioare întâmplătoare pot avea o influență decisivă în privința cărei variante a unei meme devine dominantă, indiferent de abilitatea sa de a-și ajuta gazda să își atingă țelurile. Ceea ce ne aduce la următorul subiect.

Teoria haosului

"Fâlfâitul de aripi al unui fluture în Rio de Janeiro, amplificată de curenții atmosferici, ar putea cauza o tornadă în Texas, două săptămâni mai târziu." - Edward Lorenz

În sistemele foarte complexe, rezultatele sunt foarte sensibile la condițiile inițiale. Acest lucru este adevărat și pentru vreme și pentru biologie. Ființele umane se mândresc adesea că sunt cele mai evoluate animale de pe pământ, dar nu am fi existat niciodată dacă un meteorit uriaș nu ar fi lovit pământul și nu ar fi omorât toți dinozaurii, permițând mamiferelor mici să iasă din ascunzișurile lor și să prospere într-un mediu cu totul nou. Dacă evenimente mici pot face practic imposibil de prevăzut ce specii de animale vor dispărea și care vor prospera, același lucru trebuie să fie adevărat pentru memele de dezvoltare software.

Unul dintre cele mai bune exemple de instrument care devine dominant din motive greșite poate fi găsit în industria de dezvoltare web, prin popularitatea lui PHP. Limbajul este în zilele noastre unul dintre cele mai urâte limbaje potrivit acestui sondaj Hacker Poll și totuși, este încă cel mai adoptat și tehnologia care se dezvoltă cel mai rapid pe baza utilizării în producție (81.7% potrivit w3techs). Acest lucru are sens, totuși, dacă luăm în considerare bariera de intrare joasă pentru noii dezvoltatori, că a fost primul limbaj conceput pentru a servi paginilor web, că este open-source, că a ajuns să domine dot-com bubble, etc. .

În contextul vremii și ecologiei, știința haosului încearcă să meargă mai departe de la a încerca să stabilească lanțuri de cauzalitate pentru a prezice stări viitoare ale unui sistem și în schimb să se concentreze pe găsirea tiparelor statistice în seturi mari de date și să le multiplice prin modele matematice relativ simple. În dezvoltarea software, totuși, este greu de imaginat cum s-ar putea realiza ceva analog.

O inginerie experimentală

Ingineria în general nu este chiar o știință, ci mai degrabă ea se bazează pe o cunoaștere științifică bine stabilită pentru a rezolva probleme specifice. Cunoașterea care susține ingineria software, totuși, este mult mai puțin stabilă decât cea care susține ingineria civilă, de exemplu. Materialele disponibile, instrumentele și cunoașterea științifică a mecanicii la scară umană se modifică foarte încet în comparație cu ritmul alert al lumii IT. Acest sol fertil pentru idei noi ajunge să creeze un fond de meme mult prea complex și imprevizibil. Totuși, ca ingineri nu suntem pregătiți pentru a înțelege ceva din această harababură, așa că trebuie să învățăm cum să gândim ca oameni de știință experimentali."Caracterul incontestabil nu este o virtute a unei teorii, ci un viciu. Orice test autentic al unei teorii este o încercare de a o răstălmăci." - Karl Popper

Concluzie

Prin faptul că am pus mai multe întrebări decât am găsit răspunsuri, nu am intenționat să ofer o rețetă pentru câștigarea oricărei dispute sau pentru luarea întotdeauna a celei mai bune decizii tehnice. Dar ceea ce sper este ca, aruncând lumină asupra subiectului, să creez condițiile unor dezbateri mai constructive, în care părțile să fie mai conștiente de limitările discursului lor și de subiectivitatea experienței lor. Dispute care să nu degenereze în bătălii ale ego-ului într-o lume a dezvoltării software dominată de bărbați și care au drept rezultat decizii care nu sunt întotdeauna asumate în mod arogant drept fiind cele mai bune. Având acestea în minte, ar trebui să ne simțim încurajați să fim critici în legătură cu capriciile de design în timp ce nu suntem stânjeniți să le adoptăm în mod experimental sau de dragul convenției comunității. În final, în lipsa celor de mai sus, sper ca măcar să fi oferit o perspectivă de ansamblu care să provoace gândirea în privința câtorva subiecte interesante care de obicei nu sunt acoperite de comunitatea de dezvoltare software.

"Cel mai mare dușman al cunoașterii nu este ignoranța, ci iluzia cunoașterii." - Stephen Hawking

Bibliografie

Dawkins, R. (1976). The Selfish Gene. Oxford University Press, Oxford, UK

Gleick, J. (1987). Chaos: Making a New Science. Viking Press, New York, US

Rosenberg, A. (2000). Philosophy of Science: A Contemporary Introduction. Routledge, London, UK