Mientras más simple, mejor. Esto es algo que a menudo olvidamos cuando desarrollamos software: nos vemos tentados por usar patrones de diseño, frameworks, tecnologías, herramientas... sin considerar otras opciones más simples aunque menos populares. Si hay dos formas de implementar algo y son funcionalmente equivalentes y no añaden ninguna repetición al sistema, hay que elegir la solución más simple.
Consideraciones para no agregar complejidad al proyecto
Si tenemos un martillo todo, todo nos parece un clavo
Este es un mal hábito común entre los desarrolladores que acaban de aprender algo nuevo y están ansiosos por aplicarlo. De repente, todo parece aplicar a este nueva tecnología/framework... Algunos ejemplos:
- ESB: "¡Ya sé! ¡Comuniquemos la capa de negocio y la capa de interfaz de usuario de esta aplicación de escritorio a través del ESB!"
- Spring: "Tengo que crear una clase auto, que tiene 4 puertas, mejor que asigne esta dependencia con Spring!"
Que puedas hacerlo no quiere decir que debas hacerlo
Esto es común en desarrolladores senior que están ansiosos por demostrar lo avanzados que pueden ser sus diseños. Por ejemplo:
- Abstracción: "La clase tablero para este juego de ajedrez es demasiado rígida. La voy a cambiar para que sea una grilla 2D dinámica que nos permite crear tableros de ajedrez de 12*12, 4*6 o cualquier otra dimensión arbitraria"
Mientras más cosas puedan fallar, más cosas van a fallar
Algo que todo desarrollador debería recordar siempre. Siempre cometemos errores. La cantidad de errores que cometemos es proporcional con la cantidad de cosas que desarrollamos y su comlejidad. El camino más seguro es no escribir código o no agregar complejidad.
Mientras más preparado esté el código para cambiar, más dificil va a ser de cambiar
Esta es una paradoja interesante. Es un escenario común en donde un desarrollador muestra con orgullo algo de código y explica que, por su diseño, cualquier cambio futuro relacionados con su clase pueden hacerse por configuración. Tres meses después, el primer requerimiento de cambio demuestra que va a haber que cambiar el código, y que por estar sobre-diseñado, hay que aplicar más esfuerzo en hacer el refactor.
Agregar complejidad... si hace las cosas más fáciles!
Espero no estar dando el mensaje equivocado con este post; no estoy diciendo que está mal usar frameworks, herramientas, o nuevas tecnologías. Sino, estoy diciendo que si estas herramientas no se usan de manera apropiada la complejidad puede superar a cualquier flexibilidad que ofrezcan. La clave es saber cuando usarlas. Veamos tres consejos que nos pueden ayudar.
Usarlas para quitar duplicación en el código
Este es uno de las causas más legítimas para agregar una herramienta/framework/tecnología al proyecto; la duplicación hace que le mantenimiento sea una pesadilla.
Usarlas por la flexibilidad que brindan
Spring, Hibernate y otros frameworks son ejemplos de frameworks excelentes cuando se necesita flexibilidad.
Usarlas porque es más facil que implementar la funcionalidad nosotros mismos
Si necesitamos pruebas unitarias no escribamos nuestro propio framework, usemos cualquiera de la familia de xUnit o TestNG, por ejemplo.
