Házlo simple
A raíz de conversaciones recientes con compañeros del trabajo, me ha venido a la memoria un libro que hace tiempo duerme en mi biblioteca: "Better, Faster, Lighter Java".
Hoy en día nadie cuestiona la utilidad y conveniencia de usar Hibernate o Spring, pero en aquel momento (año 2004) eran afirmaciones polémicas. En concreto, el motivo por el cual he vuelto a ojearlo, es la innecesaria complejidad que tienen muchos desarrollos Java.
Aquí van algunas de las ideas expuestas en dicho libro:
- La simplicidad debería ser un valor principal para todos los programadores Java.
- Existe la creencia, de que si programas código complicado, entonces debe ser dios.
- El código simple:
- Se escribe más rápido.
- Se prueba más fácilmente.
- Apenas tiene dependencias externas.
- Si el desarrollo ha ido realmente mal, la opción de tirarlo todo y volver a empezar es factible.
- Si los requerimientos cambias, se puede rehacer el desarrollo con comodidad.
- En contra de lo que pueda parecer:
- Código sencillo no implica código pensado de "manera simple", normalmente es lo contrario.
- Código sencillo no significa que la funcionalidad deba ser obligatoriamente sencilla..
El capitulo del libro en el que se tratan estos temas se titula Keep It Simple, en algunos sitios he visto que le añaden "and Small" para hacer las iniciales KISS, aunque en otros, lo cambian por "Keep It Simple, Stupid" 
Imprimir este artículo
Errores de una arquitectura de software
Eoin Woods, ha publicado un artículo acerca de lo que él considera los 10 errores mas comunes en una arquitectura de software - errores que habitualmente se aprenden por el camino mas difícil: la propia experiencia.
Desde mi punto de vista, si bien todos ellos son importantes (te recomiendo su lectura completa) algunos tienen más "peso" que otros:
- Desde luego el que hace referencia al alcance del sistema (apartado 1) es una verdad universal, más vale que antes de comenzar un proyecto tengas claro lo que quieres hacer y sobre todo lo que el cliente espera.
- Muy relacionado con "lo que el cliente espera" está el apartado 2: contar con todos los interesados. Es muy habitual que cuando comiences un proyecto trates con un "iluminado" que tiene claro como debería funcionar todo, pero que desgraciadamente no ha tenido en cuenta a los que realmente van a usar el sistema. Es una dificil situación, en estos casos la mano izquierda cuenta mucho ya que será necesario acceder a los verdaderos usuarios sin que por ello el "iluminado" se sienta menospreciado.
- El punto 5, aparentemente entra de lleno en conflicto con los plazos y los costes del proyecto. La experiencia demuestra que la formación del equipo de desarrollo, el realización de pruebas de concepto y la evaluación de alternativas de diseño son las mejores garantías de éxito de un proyecto.
- La escalabilidad y rendimiento (apartado 7) deben estar siempre en primer lugar a la hora de tomar decisiones de diseño. En contadas ocasiones una decisión del tipo "no pasa nada, guárdalo en sesión, serán pocos usuarios" no trae disgustos más tarde o temprano.
Imprimir este artículo
¿Qué es un servicio?
Cuando te enfrentas al diseño de un sistema de una cierta complejidad, lees libros y navegas un rato por la red, inevitablemente acabas por llegar a la conclusión que debes lograr obtener un conjunto de servicios cuya suma logre la funcionalidad completa.
Al realizar esta labor te darás cuenta que es difícil decidir qué forma parte del servicio y qué forma parte del dominio de la aplicación. Aquí van algunas directrices que pueden ayudarte:
- La implementación no es parte del servicio.
- Todo aquello que requiere conocimiento del cliente (del servicio), es parte del servicio.
- Los servicios están gobernados por contratos. Los contratos definen qué hace el servicio, cómo lo hace y cuando lo hace.
Un servicio es algo simple, proporciona al cliente una funcionalidad (comunicaciones, acceso a la información, etc. ), actúa en su nombre y lo aisla de los detalles de implementación.
Recalcar que esto no es SOA, pero crear servicios de esta forma es un buen comienzo.
Imprimir este artículo