Valores y principios en el desarrollo de software. Hoy, valores.
Kent Beck es una de las personas más importantes e influyentes en la historia del desarrollo de software. Fue el creador de metodologías como eXtreme Programming o XP y TDD (Test Driven Devlopment), y uno de los firmantes del Manifiesto Ágil.
Entre sus muchas publicaciones tiene un libro llamado Implementation Patterns. En él, Kent Beck hace un recorrido por patrones que nos van a ayudar a programar en el día a día siendo más conscientes de cada línea de código que escribamos, como él dice “dejar de fingir que se programa por instinto”. Estos patrones son más básicos que los tan afamados patrones de diseño del GoF. Pero, en mi opinión, estos últimos no se pueden llevar a cabo con eficacia sin tener en cuenta y entender previamente los desarrollados y explicados en Implementation Patterns.
Antes de comenzar con los patrones de implementación, Kent Beck nos hace un repaso sobre la filosofía en los que están basados. Los valores y principios en los que basa su desarrollo y que nos van a servir además de para comprenderlos, llevárnoslos a nuestro día a día para hacer mejor código.
Valores
Hay tres valores firmes y consistentes con la excelencia en la programación: comunicación, simplicidad y flexibilidad.
Aunque algunas veces puedan entrar en conflicto, la mayoría de las veces se complementan los unos con los otros.
Comunicación
El código comunica bien cuando el programador que lo lee puede comprenderlo, modificarlo o usarlo sin dificultad. Muchos programadores se sienten tentados a pensar únicamente en el ordenador, sin embargo, los buenos programadores piensan en las personas que vienen detrás de nosotros para leer nuestro código.
Cuando leemos código limpio nos resulta más fácil de leer, es más rentable en términos de tiempo ya que la lectura es más rápida y esto implica que también sea más rentable en términos de economía. La mayor parte del coste del software incurre después de que el software ha sido desplegado por primera vez. Si pensamos en las modificaciones y extensiones posteriores de un programa podemos llegar a la conclusión de que leemos muchas más veces código de las que lo escribimos nuevo.
Para comunicarnos correctamente con nuestro código es imprescindible tener un amplio conocimiento del dominio del problema y del dominio de la solución. No es posible escribir programas de forma correcta, legible y comunicativos para otros programadores si no somos capaces de expresarnos con absoluta claridad y sencillez.
Simplicidad
Eliminar el exceso de complejidad lleva a aquellos que lo leen, usan y modifican a comprenderlos de forma más rápida. Hay complejidades esenciales, es decir, inherentes al problema que tenemos que resolver y vienen definidas por él mismo. Y luego tenemos complejidades accidentales, que son aquellas que introducimos los programadores complicando la comprensión del código y su ejecución. Estas últimas las solemos introducir porque no tenemos un conocimiento real del problema o por malas planificaciones.
Aún así, la simplicidad es algo subjetivo. Un código puede ser simple para un programador experto y no tan simple para alguien sin experiencia. El conocimiento y la madurez pueden hacer tener distintas opiniones sobre la simplicidad de un código a dos programadores.
Además, la simplicidad hace posible la innovación. La tendencia general en el desarrollo de software es hacerlo todo mucho más simple. Desde las herramientas para su desarrollo hasta las herramientas orientadas al testing o la puesta en producción. Todas ellas hacen el camino del programador más sencillo, pero, para todas ellas ha hecho falta innovar, investigar y mejorar su producción.
La comunicación y la simplicidad suelen ir de la mano. A menor complejidad de un sistema más fácil será de comprender. Y a mayor foco en la comunicación más sencillo será ver que complejidad puede ser descartada.
Flexibilidad
La flexibilidad suele ser la justificación más utilizada para la mayoría de las malas prácticas y diseños. Solemos introducir mucha complejidad para hacer nuestras aplicaciones más flexibles, sin tener en cuenta que la flexibilidad debería ser entendida en la forma en que los programas cambian y no de la multitud de posibilidades de configuración que pudieran tener para adaptarnos a los problemas que podamos tener hoy o en el futuro. No es esta flexibilidad a la que nos referimos.
Los programas deberían ser fáciles de cambiar. La flexibilidad que queremos es aquella que nos haga más fácil las modificaciones el día de mañana, una flexibilidad basada en diseños más simples y una buena cobertura de tests y no basadas en diseños especulativos con propiedades o características innecesarias y que no aportan valor real a la solución.
La simplicidad nos ayuda a tener flexibilidad futura eliminando todas aquellas características que no aportan valor y que hacen el software más complicado. La comunicación también puede ayudarnos. Un código que se lee, entiende y comprende bien es más flexible puesto que es más sencillo de modificar en un futuro.
Comunicación, simplicidad y flexibilidad. Fácil, ¿verdad? :p
Chimpùn.
Actualización: El 21 de Enero de 2018 escribí el post relacionado principios en el desarrollo de software.
