dvrom.eu

Pres de Michael Nygard - El futur de desenvolupament de programari “:

"Parlant de llenguatges, molts dels problemes a què ens enfrontem avui no poden resoldre amb un sol llenguatge o aplicació.
Avui en dia, no es pot explicar adequadament ni raonar sobre el comportament d'un lloc web només examinant el codi de
l'aplicació. Un lloc recull atributs de comportament d'una multitud de fonts: el codi de l'aplicació, la configuració de servidors
web i servidors cache, servidors grid, processament asíncron, elements d'aprenentatge automàtic, dispositius actius de xarxa
(com firewalls aplicatius), i magatzems de dades. "Programació", com el descriuríem avui - programació de comportament
aplicatiu com a tractament de peticions - defineix una porció cada vegada menor del comportament. No tenim eines o
llenguatges per expressar i raonar sobre aquests sistemes distribuïts, estesos i fragmentats. A conseqüència, és difícil
predir la funcionalitat, rendiment, capacitat, escalabilitat i disponibilitat d'aquests sistemes. "

No podria estar més d’acord…

Si t’agraden les fonts de coneixement bons, de fàcil lectura i gratuïts, com jo, segurament hauries de fer una ullada a 97 coses que un arquitecte de software ha de saber.

Cada projecte de software és diferent, i té unes necessitats diferents i úniques, i com Edward Garson assenyala a El context és el rei:

“Crec que hi ha una certa ironia en l’intent de transmetre alguna cosa sobre els ideals de l’arquitectura, quan la premissa amb la què vull començar és que efectivament no hi ha ideals. Si això és així, llavors segurament no hi ha res a escriure, sóc una contradicció i en fer això, corro el risc de provocar la implosió de l’univers o alguna cosa així. “

No obstant això:

“Però, per desgràcia, Ceci n’est pas une pipe.”

Jo si crec que els projectes d’enginyeria de software comparteixen alguns problemes comuns (o almenys ho espero, qualsevol reforç moral és benvingut: l’enginyeria de software és una difícil disciplina on la desesperació és freqüent).

“97 Coses”, assenyala alguns dels temes i solucions que probablement haurien de ser aplicables a qualsevol projecte d’enginyeria de software.

Hi ha alguns noms grans i molts anys d’experiència darrere d’aquests aforismes de saviesa, i en la meva curta carrera fins al moment, he trobat molts dels problemes descrits en “97 Coses” en projectes passats i presents.

Atès que 97 coses són massa per la meva memòria a curt termini, aquestes són les 3 coses que m’esforçaré a recordar:

Michael Nygard és un desenvolupador i arquitecte amb més de 15 anys d’experiència, i també és l’autor de “Release It! Design and Deploy Production-Ready Software”.

Després d’haver trobat aquest llibre en moltes llistes tipus “Llibres que un Enginyer de Programari ha de llegir”, vaig pensar a donar-li una oportunitat.

Això no serà un comentari a fons, ja que ja n’hi ha molts existents, sinó més aviat un resum de les idees que es quedaran amb mi després d’aquesta primera lectura.

El llibre de Michael tracta la problemàtica relacionada amb l’execució exitosa de sistemes de software en producció, i, encara que se centra en sistemes distribuïts d’alta disponibilitat i de gran escala, molts dels temes exposats poden ser aplicats a qualsevol sistema de software.

El llibre cobreix tots els possibles elements i capes de l’enginyeria de software que se m’ocorren: gestió, execució, proves, disseny, desenvolupament…, front-end, back-end, explotació, etc., i en lloc de tractar de respondre a totes les preguntes, més aviat intenta mostrar la bona direcció en la qual anar.

Aquest és, sens dubte, un llibre que segurament torni a llegir en el futur, ja que les idees i situacions que es quedaran amb mi després d’aquesta primera lectura són només aquelles que m’he trobat en projectes actuals i anteriors.

Un dels primers projectes en el qual vaig treballar ha sigut substituït i està ara allà a on sigui que va el codi mort…

Quan miro enrere ara, aquest CMS tan senzill és un dels projectes amb més èxit en el què he participat fins ara, en termes de longevitat (va estar en producció durant els últims 5 anys) i feedback dels usuaris.

També és probablement la solució més simple en la que he treballat (sense processos de desenvolupament complicats, sense codi intel·ligent, abús de patrons…) i em recorda una cita que vaig llegir en algun lloc que ja no recordo, que deia més o menys:

Jo probablement reformularia aquesta afirmació en:

En el mateix sentit, també diria que:

La meva ràpida exposició en els projectes que van seguir a aquest senzill gestor de continguts al gran món de J2EE, frameworks ORM, patrons de disseny, a l’API Java, frameworks Web i altres candidats per a abús, combinat amb la meva mentalitat prepotent de “Puc amb tot! ” de principiant, va portar cap a algun que un altre codi horrible i a alguns sobredimensionats terribles…

No sol la saviesa, sinó també la ignorància, de vegades pot produir els millors resultats…

Proves d’estrès, proves de càrrega, proves de rendiment, proves de capacitat…totes elles es basen en la mateixa idea:

• Els sistemes de programari són construïts normalment per ser utilitzats, i és probable que, en un moment o un altre, es vulgui saber com reacciona el sistema davant d’una gran carga, i, en cas que els resultats no siguin satisfactoris, es voldrà millorar el rendiment del sistema.

Una primera qüestió que es planteja:

Les proves de càrrega s’han de realitzar en alguna fase específica o s’han de realitzar a causa d’algun requisit específic?