ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
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 44
Abonament PDF

Haos, meme și tipare de design software

Ariel Pontes
Python Developer @3 Pillar Global



PROGRAMARE

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

NUMĂRUL 143 - Software Craftsmanship

Sponsori

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