Archivo | filosofia dev RSS for this section

Agile principles, patterns and practices in C#

Agile principles, patterns and practices in C#

Robert C. Martin

Por qué lo he leído

Lo he leido porque me he encontrado referencias a este libro en libros anteriores que he leído, en blogs sobre desarrollo de software que suelo leer y en otros muchos sitios relacionados con el software. Si encuentro tantas referencias, será por algo, ¿no? Además, el autor es muy conocido y valorado, así que no había excusa para no leerlo.

Qué esperaba

Me esperaba un libro de Uncle Bob™. Ya he leído alguno del mismo autor, y me gusta su estilo. Algunas veces me parece un poco extremista, pero creo que es así porque cree en lo que hace y eso es lo que predica. Cuando creo que exagera, no le hago mucho caso y sigo hacia adelante, ya está.

Esperaba una descripción de las metodologías ágiles aplicadas al momento de escribir software y encontré …

Qué encontré

… un pedazo de ladrillo! Me asusté cuando vi la extensión del libro, pero enseguida entendí el porqué. El libro está lleno de diagramas UML y de código fuente (primero los tests, por supuesto). Así que es normal que sea tan largo.

En cuanto al contenido, me gustó mucho la descripción que hace de muchos patrones de diseño, (incluso he aprendido alguno que no conocía). En el libro también podrás encontrar una descripción detallada de los principios SOLID y de otros principios sobre cómo organizar y empaquetar los distintos componentes de tu aplicación (clases, paquetes, namespaces, lo que sea).

Conclusiones

Aunque el libro sea muy extenso, me ha gustado por varias razones:

  • He aprendido nuevos patrones de diseño.
  • He podido profundizar sobre el patrón Model-View-Controller (ver enlaces más abajo).
  • He encontrado una descripción muy detallada de los principios SOLID.

Pasajes que quiero recordar de este libro

Un módulo que es difícil de cambiar, está roto y necesita ser arreglado, aunque funcione.

Un módulo que no comunica está roto y necesita ser arreglado.

Cuanto más conocen los programadores sobre todo el proyecto, más sano y más informado está el equipo que lo desarrolla.

Es el big picture lo que mantiene unido el sistema. Es la visión del sistema lo que hace obvia la localización y la forma de los módulos individuales. Si la forma de un módulo es inconsistente con la metáfora, es el módulo quien está mal, no la metáfora.

Al final, el código fuente es el diseño.

Se sabe que el software se está pudriendo cuando empieza a mostrar alguno de los siguientes síntomas: rigidez, fragilidad, inmovilidad, viscosidad, complejidad innecesaria, repetición innecesaria u opacidad.

El elemento más volatil en los proyectos software son los requisitos. Vivimos en un mundo de requisitos cambiantes, y nuestro trabajo es estar seguros de que nuestros software puede sobrevivir a esos cambios, así que no culpes a los requisitos cambiantes por los fallos en el software.

Los principios SOLID: Single responsability principle, Open close principle, Liskov substitution principle, Interface segregation principle, Dependency inversion principle.

Un motivo de cambio es un motivo de cambio sólo cuando el cambio ocurre, mientras tanto no.

Strategy and Template method son las formas más comunes de satisfacer Open closed principle. Estos patrones representan una clara separación de la funcionalidad genérica de la implementación detallada de esa funcionalidad.

Fool me once, shame on you. Fool me twice, shame on me. Inicialmente, escribimos nuestro código pensando que no va a cambiar. Cuando ocurre un cambio, implementamos abstraciones que nos protegen de futuros cambios de esa misma naturaleza.

Liskov substitution principle nos lleva a una importante conclusión: un modelo, visto aisladamente, no puede ser validado significativamente. La validez de un modelo puede ser expresado solo en términos de sus clientes.

Liskov substitution principle clarifica que en la programación orientada a objetos, una relación de herencia pertenece al comportamiento que puede ser asumido y que los clientes dependen de este comportamiento, lo contrario de lo que normalmente se cree, que la herencia pertenece al estado

El diseño de grandes sistemas depende críticamente de un buen diseño de componentes (paquetes, entregables, …), de esta forma, los equipos individuales puede enfocarse en componentes aislados en lugar de preocuparse por el sistema completo.

Las interfaces pertenecen al cliente que las usa, no a la implementación. El enlace lógico entre el cliente y el interfaz es más fuerte que la relación entre el interfaz y sus implementaciones. Es tan fuerte que no tiene sentido desplegar el cliente sin el interfaz, pero sí que lo tiene desplegar el interfaz sin sus implementaciones.

Otras lecturas y enlaces relacionadas

Anuncios