Ricardo Galli ha publicat últimament un parell d’articles molt interessants sobre temes de desenvolupament de software [1][2].

M’agrada la idea que en Ricardo esmenta sobre les conseqüències que pot tenir desenvolupar bé o no un projecte, fer-lo més simple o eficient, o escriure codi fàcil de mantenir:

Un enginyer de software s’ha d’ocupar d’ensamblar bé les peces de què disposa per fer la màquina, i fer que aquesta màquina funcioni bé i d’acord a allò que li han demanat, però no s’ha de preocupar de redissenyar-les cada vegada: cal aplicar allò que s’ha après a la facultat o als llibres i no redescobrir la roda cada vegada.

En aquest sentit, penso, com en Ricardo, que cal aplicar la màxima KISS (Keep It Simple, Stupid) sempre que sigui possible i a tots els nivells (codi del producte, sí, però també la interfície), i també mantenir una bona documentació. Perquè? perquè el concepte d’eficiència no l’hem de mesurar només en cicles de màquina, sino també en hores/persona de manteniment, o en hores/persona d’utilització del producte (digueu-li rendiment, si voleu a això), per exemple.

En el cas del codi, per exemple, aplicar KISS no vol dir ofuscar el codi o treure espais o usar el desplaçament de bits en comptes de multiplicacions si queda més clar una multiplicació, aplicar KISS significa pensar bé el codi que hem de programar, modularitzar per reutilitzar codi i no repetir-ho (copiaferrant de mala manera), parametritzar…

Si a això és lliga a una bona documentació (inclosos els comentaris al codi), els temps de manteniment, modificació o ampliació del producte una vegada finalitzat es veuen molt reduits (bàsicament, perquè no has de redescobrir que vas fer tu o què va fer la persona que va escriure aquell codi)

En el cas del producte finalitzat, per exemple, aplicar KISS significaria generar unes interfícies que no agobiessin a l’usuari, que li permetessin fer la feina amb el mínim de moviments possibles (d’això ja en sabem, els informàtics ;·), però que, alhora tinguessin la possibilitat d’accedir a opcions més complexes, no visibles en un primer moment (la majoria de tasques que fan els usuaris son repetitives, i en comptades ocasions o en moments especials es necessita l’accés a tasques o possibilitats més complexes).

Els projectes, per tant, no s’han de veure com un aïllat que comença i acaba (requeriments, desenvolupament, prova, implementació) més el manteniment posterior o la formació dels usuaris, també cal que comencem a aplicar a la equació elements que ja s’apliquen en d’altres especialitats, per exemple:

  • Criteris mediambientals: Impacte energètic dels servidors (escalabilitat, número de servidors necessaris per suportar el servei), dels clients (cal un pc amb disc dur, tarja de so, etc… o amb un thin client passem?), possibilitat d’emetre resultats impresos (informes, llistats, etc..): es poden substituir per pdfs o anàlisis, enviar per correu o conectar directament amb d’altres plataformes?

  • Criteris ergonòmics: usabilitat, accessibilitat (si, això ja es fa, però no em refereixo a si el botó es veu millor en blanc sobre negre que en negre sobre blanc, o si cal un botó en comptes d’un enllaç, sino si el text del botó és explicatiu per l’usuari, si la pantalla no té masses opcions per allò que cal fer normalment, etc.)

[1] La eficiencia y medio ambiente en la ingeniería [2] Recursividad, punteros, estadísticas y pseudociencia del software