Personalment, conec alguns desenvolupadors amb molt de talent i que poden crear peces meravelloses de programari sense cap o poc de treball. Per culpa d'aquests individus dotats, la nostra indústria està plena d'expectatives. Però la trista realitat és la següent: no tothom és un desenvolupador ninja, un guru, o una estrella del rock.

I això és exactament el que sóc: un desenvolupador mediocre. Aquest article us guiarà per sobreviure a la indústria si no sou un geni.

Cerco a Google les coses més senzilles tot el temps

No recordo moltes coses. Com ara les funcions i mètodes de les biblioteques estàndard, les posicions dels arguments, els noms de paquets, el codi repetitiu, etc.

Per tant, he d'anar a Google. I ho faig diàriament. També reutilitzo el codi de projectes antics. De vegades, fins i tot copio i pego respostes de StackOverflow o Github. Sí, en realitat és: desenvolupament des de StackOverflow.

Però no sóc l'únic També ho fan molts altres desenvolupadors. Hi ha una discussió a Twitter famosa que va ser iniciada pel creador de Ruby on Rails.

Però, per què és tan dolent? Bé, hi ha diversos desavantatges al respecte:

• Permet copiar decisions de disseny inadequades o codi vulnerable d'altres persones


• Forma una mentalitat específica: si no podem aconseguir alguna cosa a Google, llavors "Houston, tenim un problema"


• Quan no funcioni Internet, no podrem treballar

Com sobreviure:

• Utilitzeu un IDE per obtenir la compleció automàtica i suggeriments, de manera que no haureu de cercat a Google els principis bàsics del llenguatge


• Recordeu on (no com) ja heu resolt aquest problema. Així que sempre podeu mirar la solució


• Tot el codi que enganxeu al projecte s'hauria d'analitzar, refactoritzar i revisar més endavant. D'aquesta manera no farem cap mal al projecte amb el codi incorrecte, però l'ajudem amb la solució ràpida

Les màquines sempre fan el que les diem. De vegades se'ls acaba de dir que ho facin malament. Per tant, el problema principal del desenvolupament de programari no són les màquines, sinó la capacitat mental dels desenvolupadors. És molt limitada. Així que, nosaltres - desenvolupadors mediocres - no podem perdre-la per crear abstraccions complexes, algoritmes foscos o blocs il·legibles de codi llarg. Feu-ho senzill.

Però, com podem dir que aquest codi és senzill i aquell és complex? Hem d'utilitzar el mètode de malediccions/minut per mesurar la qualitat del codi.

El principi és molt fàcil i clar d'entendre. Sempre que trobeu alguna cosa al codi que no enteneu, és massa complexa. Què podem fer?

• Reescriure-la per tenir un disseny més clar


• Proporcionar documentació


• Afegir comentaris a les parts més difícils. Però recordeu, que els comentaris són símptoma d'un problema més complex

• Utilitzeu noms correctes de variables, funcions i classes


• Assegureu-vos que totes les parts del programa només fan una cosa


• Trieu funcions pures en lloc de funcions regulars


• Trieu funcions regulars per damunt de classes


• Acabeu en les classes solament en cas de gran necessitat

Alguns desenvolupadors han demostrat oferir codi d'alta qualitat. Igual que aquesta dona: Margaret Hamilton, enginyera en cap de del Projecte Apollo.

Però, sempre que escric qualsevol codi, no confio en mi mateix. Puc fer malbé les coses fins i tot en les parts més fàcils del projecte. Això pot incloure:

• Errors del llenguatge


• Errors lògics


• Errors de disseny


• Errors d'estil


• Errors de seguretat


• Errors maleïts (els meus favorits de tots els temps!)

El cas és que ningú no hauria d'estar autoritzat a escriure codi amb errors evidents. Almenys, hauríem de provar. Però, com puc protegir el projecte de mi mateix? Hi ha diverses maneres de fer-ho.

Com sobreviure:

• Escriviu tests. Escriviu un munt de tests. Començant per proves d'integració fins a proves unitàries. Executeu-lo al CI abans de cada pull request. Això us protegirà d'alguns errors lògics


• Utilitzeu l'escriptura estàtica o la tipificació estàtica opcional. Per exemple, utilitzem mypy amb python i flow amb javascript. Efectes positius: disseny més net i comprovacions del temps de "compilació"


• Utilitzeu comprovacions automàtics d'estil. Hi ha un munt de comprovadors d'estil per a cada llenguatge


• Utilitzeu controls de qualitat. Algunes eines executen alguns algorismes heurístics complexos al codi base per detectar diferents problemes com ara aquesta línia que té massa lògiques, aquesta classe no és necessària, aquesta funció és massa complexa


• Reviseu el codi. Reviseu-lo abans de fusionar-lo a master. I algun dia després de la fusió


• Pagueu altres persones per auditar el codi. Aquesta tècnica té una gran influència positiva!. Perquè quan els desenvolupadors revisen el codi per primera vegada, és més fàcil que detectin incoherències i decisions de disseny defectuoses

Quan el meu equip va desenvolupar el nostre primer gran projecte de programari fa gairebé deu anys, l'enviarem com a fitxers font de Java. I no es va poder compilar al servidor de destinació. Això va ser diverses hores abans de la presentació al client. Fou un gran fracàs! D'alguna manera vam aconseguir posar-lo en funcionament, però va ser una experiència que ens va canviar la vida.

Això va succeir perquè hi havia molta configuració i molta complexitat en el moment de construir-ho. I no poguérem gestionar correctament la complexitat d'aquest sistema. Des d'aquest dia per reduir la complexitat en aquest pas, intento empaquetar els meus programes en entorns aïllats. Per provar-los en aquest entorn abans que succeeixi el desplegament real.

En els últims anys, amb l'ascensió del Docker (i els contenidors en general), es va fer tan fàcil com mai. Docker us permet executar el desenvolupament, les proves i la producció en un mateix entorn aïllat. Per tant, mai no perdreu res important en el camí.

No? Parlant de mi mateix, sempre oblido alguna cosa en crear servidors, en la configuració inicial o en enllaçar-los. Hi ha tantes coses a tenir en compte!. Amb sort, encara podem automatitzar-lo. Hi ha diferents eines increïbles per automatitzar el procés de desplegament. Com ara: terraform, ansible i packer. Llegiu sobre ells per trobar quina eina necessiteu en realitat per a les tasques.

També intento configurar el CI/CD el més aviat possible. Així doncs, es notificarà si la meva compilació ha fallat en la prova o en la implementació.

Com sobreviure:

• Automatitzeu qualsevol cosa que utilitzeu per implementar


• Utilitzeu Docker per al desenvolupament d'aplicacions, proves i implementació


• Utilitzeu eines d'implementació

Ah, per fi, la meva aplicació està en producció. Ara està funcionant. Puc tenir una breu migdiada, res no es trencarà. Espera, no! Tot es trencarà. I sí, ho dic: tot.

De fet, hi ha algunes eines que faciliten la cerca i la resolució de problemes existents.

• Sentry. Quan es produeixi un error per a qualsevol dels vostres usuaris, se't notificarà. Té llibreries a gairebé qualsevol llenguatge de programació


• Diferents serveis i eines per recollir registres de múltiples processos i servidors en un sol lloc


• Monitorització del servidor. Aquest és el lloc on podeu configurar monitors per a la CPU, discs, xarxes i memòria. Fins i tot podeu detectar el temps d'escala abans que els usuaris puguin trencar el servei

Constantment aprenent

Uau!, hi ha moltes coses per aprendre. Però així funciona. Si volem escriure un bon programari, necessitem aprendre constantment com fer-ho. No dreceres curtes o trucs màgics. Solament aprendre a ser millor cada dia.

En conclusió, hem d'entendre dues coses bàsiques:

• Els problemes els tenim tothom. L'únic que importa és com estem de preparats per a aquests problemes


• Podem reduir l'origen dels problemes a uns ràtios acceptables