Hoy he reparado en una web (que he agregado a mis enlaces) que trata sobre temas de la programación y, en definitiva, se centra en hacer buen software.
Es algo complejo determinar qué es buen software y qué no lo es, por lo que estos siete consejos pueden ayudar a detectar lo que se puede considerar buen software y lo que no. En definitiva y después de muchos años desarrollando, así como leyendo a gente que al igual que yo lleva también muchos años en esto, la clave para hacer buen software es programar lo único necesario para cumplir el objetivo marcado, ni una línea más. Y como dice Alberto: no hay problemas difíciles, solo soluciones difíciles.
- Fácil de leer: Si el código es fácil de leer, fácil de interpretar, será fácil de mantener: modificar y ampliar. También necesitará menos comentarios y menos documentación, ya que se entiende de por sí.
- Fácil de usar: Debe de ser intuitivo. Si el código no es intuitivo, es decir, hace algo de una forma que no es la que se espera, puede conducir a situaciones en las que el mantenimiento sea un infierno.
- Fácil de cambiar: No debe de haber lógica duplicada. Cualquier cambio debe de poder realizarse solo en un sitio.
- No uses herramientas, librerías o código de terceros, sino es necesario: Cada vez que se usa un framework, librería o código externo para hacer algo de una forma más fascinante, agregamos complejidad extra al proyecto. Esto es algo peligroso que puede hacer que de repente nuestro código no sea fácil de cambiar o ni siquiera de leer.
- Que parezca simple: Si un código no parece simple, es que no es simple. Si un código parece simple cuando se termina de escribir, viendo su simpleza y pensando incluso que se podía haber escrito en menos tiempo, es que el trabajo se ha hecho bien.
- Lean: Tener en cuenta los principios del lean software development puede ayudar a realizar un código más simple, fácil y bueno. Se basa también en el principio YAGNI (you ain't gonna need it?, ¿realmente lo necesitas?): no desarrollar nada que no haga falta.
- Que sea directo: Esto significa, básicamente, no perderse en capas de abstracción, disparadores y otro código que queda oculto y difícil de trazar. El código tiene que ser directo, fácil de trazar y de seguir, previsible y evidente.
En sí, es sentido común el pensar que, lo que no está hecho no cuesta nada cambiarlo, por ello, sino se desarrolla algo a futuro, pensando en que pueda requerirse, cuando se requiera de otra forma, no habrá nada que cambiar, porque no se habrá hecho nada.
Por otro lado, tomarse el tiempo necesario para no hacer chapuzas, sino modificar lo que haya que modificar y cómo haya que modificarlo, es totalmente necesario y aconsejable para que el código siga siendo bueno.
