A continuación os dejo un post que escribí en su momento en el blog de Kabel Sistemas de Información.
Principio de simplicidad.
El principio de simplicidad ha de prevalecer siempre. Siempre que te encuentres ante una decisión toma la más sencilla. A menudo cuando creamos piezas sumamente complejas sufrimos un impacto la productividad del equipo ya que es mucho más difícil comprender, entender y usar el código.
Esto sumado a las tiempo que hay que emplear en pruebas regresión cada vez que nos vemos en la tesitura de modificarlo hace que estos códigos sean un lastre a la larga.
En aplicaciones en las que hay códigos sumamente complejos, el equipo de desarrollo pasa más tiempo leyendo y depurando el código que escribiendo código y esto hay que evitarlo toda costa.
Además gran parte de los proyectos de software son después mantenidos por equipos que no han desarrollado las aplicaciones, por lo tanto, la persona que ha creado un código sumamente complejo desaparece y esto suele derivar en códigos que nadie quiere tocar por miedo al impacto que pueda tener.
Nada es reutilizable hasta que se reutiliza.
A menudo, cuando diseñamos los diferentes componentes de la aplicación, pensamos en el futuro de la misma e intentamos crear códigos reutilizables “por si acaso”.
Error.
Nada es reutilizable hasta que se reutiliza. Esta es una gran verdad que tenemos que tener clara en todo momento. Crear un código para posteriormente reutilizarlo (por que sí) implica complicar ese código, cayendo en el punto anteriormente enumerado.
No a soluciones genéricas que se adaptan a todos los casos.
Cuidado con los casos “voy a diseñar un control que valide lo que introduce un usuario, ya sea un mail, un código postal o un DNI”.
Este tipo de acciones, deriva en códigos complejos y a los problemas anteriormente vistos. A menudo, estas piezas de software mágicas resuelven solo lo que contemplan y conforme tienes que ir añadiendo funcionalidad vas complicándolo más y más.
Soluciones concretas a problemas concretos.
Construir de menos a más. Haz refactoring.
Siempre que creemos piezas de software, tenemos que partir de código sencillo y conforme vayamos teniendo necesidades, crecer sobre lo creado anteriormente.
Hacer uso de refactoring (http://en.wikipedia.org/wiki/Code_refactoring) es una buena práctica, dado que, conforme vamos revisando nuestro software, podemos detectar carencias y subsanarlas, además de ir añadiendo funcionalidades necesarias. Por otro lado, el refactoring te va a dar una visión clara de las funciones de que cada una de las partes de la aplicación a lo largo de todo el proyecto.
No a tu framework, usa frameworks ya desarrollados.
Evita en todo momento crearte tu propio framework. Hay gente, equipos enteros que se están encargando de esto. Usa estos frameworks. Ten en cuenta que seguramente, están desarrollados por buenos profesionales, que están perfectamente testeados y que prácticamente en el 100% de los casos, estos frameworks, van a ser bastante mejores que el tuyo.
Usa JQuery, Modernizr, usa el .NET Framework, usa el framework que quieras, pero no te crees el tuyo.
Por ejemplo, no puedes estar desarrollando un framework de acceso a datos cada vez que desarrollas una aplicación. Esto tiene un gran impacto en la productividad del equipo y seguramente no te van a pagar por desarrollar esa pieza, sino por resolver una problemática concreta. Céntrate en tu negocio.
Haz Pruebas unitarias.
El trabajar con pruebas unitarias, puede parecer que tiene un impacto en los tiempos del proyecto, y bien es verdad que dado que tenemos que escribir más código inicialmente vamos a tardar algo más, pero a la larga, nos va a permitir reducir los tiempos.
Si un código no funciona, vamos a detectarlo en el momento en que ejecutamos la batería de pruebas y esto nos permite ser más eficaces dado que sabemos en qué punto concreto falla nuestro software.
Trabajar bajo el paradigma del TDD, nos va a obligar a diseñar el código de una forma concreta (desacoplado) para poder probarlo, obteniendo así un software diseñado de manera “uniforme” a lo largo de todo el desarrollo, lo cual hace más sencillo su posterior uso, reutilización y refactoring por todo el equipo.
Francisco de Goya, en el año 1799, publico una serie de grabados realizados por medio de aguafuerte, aguatinta y retoques de punta seca que llamo Los Caprichos. Mediante estos grabados busco satirizar y retratar la sociedad española de finales del XVIII.
El sueño de la razón produce monstruos, es el grabado 43 de los 80 que componían la serie. Y este, además de posiblemente ser el más famoso de todos, cuenta con un título totalmente inspirador con el que no años después, si no siglos después, nos encontramos que su mensaje sigue siendo totalmente vigente.
En nuestro sector seguro que todos hemos visto casos en los cuales podemos decir que la fantasía ha sido abandonada por la razón y esto se ha traducido en aplicaciones de software monstruosas.
A deshoras 