Archivo | enlaces 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

Enlaces de los martes (06-11-2012)

Hace muchos martes que no publicaba una serie de enlaces, así que creo que esta vez la lista ha quedado un poco larga, pero espero que encontréis los enlaces muy interesantes:

  • Branching and merging with git and github, encontrado en Learn Github: Buscando alguna manera de trabajar con ramas en git y github, he encontrado este enlace. Creo que explica de forma muy clara y concisa una forma básica de crear ramas, trabajar en ellas, y pasar los cambios de una rama a otra. Ahora por lo menos, lo tengo mucho más claro.
  • The App Developers Alliance, de Joel Spolsky: Este post me ha gustado especialmente, no por el título, si no por las perlas que Joel dice en el artículo:

Cuando un programador escribe software, escribe un guión para el futuro.

El software es omnipresente.

El software se está comiendo el mundo, así que los programadores son los diseñadores del futuro

Enlaces de los martes (16 oct 2012)

Otro martes más con unos cuantos enlaces interesantes. Esta semana he recopilado temáticas muy diversas, desde temas técnicos (excepciones), hasta temas familiares (geek dads):

Enlaces de los martes (02 oct 2012)

Seguimos, un martes más, con una recopilación de los enlaces que me han parecido más interesantes, espero que a vosotros también os gusten:

  • Los desarrolladores odian las tareas sin valor (inglés), de Java Code Geeks: artículo donde el autor explora las razones de por qué los programadores odiamos las tareas sin valor (o que percibimos que no aportan valor) por ejemplo: una tarea repetitiva, una tarea que debemos hacer cada cierto tiempo, trabajo que antes de estar terminado alguien decide que ya no es necesario.
  • Comunicación productiva en equipo, de Think Wasabi, vía El Canasto: qué importante es una buena comunicación en un equipo. Descubre unos consejos para comunicarte mejor con tus contactos, ya sean del trabajo o no.
  • 6 ventajas de FDD frente a Scrum, de Javier Garzás: en el post anterior acerca de enlaces interesantes, dejé 2 de Javier acerca de la metodología FDD (Feature Driven Development), así que no podía dejar pasar este otro post acerca de esa metodología. Esta vez la compara con Scrum, una metodología ágil mucho más conocida y extendida, pero no por ello tiene que servir para todo tipo de proyectos. FDD se enfoca hacia un público muy distinto al de Scrum.
  • Cursos gratuitos de las universidades de Berkeley, Massachusetts y Harvard: no son simples cursos, creo recordar que son cursos académicos completos, es decir, un año de carrera en cualquiera de estas universidades. Los hay desde Introducción a Ciencia de Computadores (Computer Science) hasta temas tan punteros como Software as a Service (SaaS). Lo único no positivo que les veo es que son en inglés.
  • Groovy: The road map for the popular JVM language (inglés), de InfoWorld: Entrevista a los líderes de los proyectos Groovy y Graisç, Guillaume Laforge y Graeme Rocher respectivamente, donde comentan las futuras funcionalidades del lenguaje groovy y el framework web grails.
  • Prefiero github:pages a wordpress.com, de Roberto Vázquez: He descubierto el blog de Roberto a través de su post sobre la barcampes, y en particular, este post me ha gustado mucho. Me lo apunto como tarea, haré lo posible por tener tiempo para migrar mi blog de wordpress a github:pages, ¿por qué no?
  • Learnable programming (inglés), de Bret Victor, via Linking paths: según la fuente donde encontré el enlace, este es probablemente el ensayo técnico más importante del año, y la verdad es que promete. Fascinante lectura, en serio!

Enlaces de los martes

En los enlaces de hoy he incluido un poco de autopromoción. No me gusta hacerlo, pero por otro lado creo que es muy bueno hacer públicos los pequeños logros que uno va consiguiendo, más que nada para recibir el máximo feedback posible y poder crecer en el ámbito personal.

Además, se nota que estamos en verano, y el ritmo de enlaces interesantes ha bajado bastante. O me estoy volviendo demasiado exigente, quien sabe.

Sin más, ahí van los enlaces:

Enlaces de los martes

Y este martes tenemos otra nueva entrega de enlaces. Espero que os guste, cualquier feedback es bienvenido.

 

Enlaces de los martes

Como el título indica, espero que esto se convierta en una costumbre (sana) para mí.

En mi día a día, leo muchos artículos o gracias a la gente que sigo (blogs, twitter, …) llego a páginas realmente interesantes. Y simplemente no quiero que esos enlaces se queden por ahí perdidos, y además, me gustaría compartirlos.

Así que ahí van mis primeros enlaces de los martes:

  1. De qué hablo cuando hablo de excelencia, de Javier Lafuente Garcia (@jlafuenteg): Un genial artículo sobre la definición de excelencia en el mundo del software.
  2. 25 Best Free Maven Plug-ins to Make Java Developer More Productive, visto en fromdev: Donde se listan plugins esenciales para el trabajo del día a día con maven.
  3. Code School – Try git, visto en github: Una estupenda herramienta para aprender a usar git.
  4. Clientes con los que yo no trabajo, de Asier Marqués: Espero acordarme de este artículo si algún día decido dedicarme a tener mi propio negocio.
  5. El mítico restaurante italiano, visto en Frogtek: Una inestimable alegoría para comprender mejor las metodologías ágiles. No puedes quedarte sin leerlo.

Espero que estos enlaces os sirvan para descubrir recursos muy interesantes y valiosos.