Desde hace algunas semanas he salido de mi “zona de confort”, llevo casi 14 años en el mundo del Java, y me he puesto a aprender PHP con el fin de poder hacer desarrollos en  WordPress. Es éste un gestor de contenidos del que normalmente pensamos que sólo sirve como plataforma de blogs, que también, pero no hay que olvidar que es un muy versátil y se puede extender para que haga prácticamente de todo: desde un catálogo de productos, una tienda online, vender entradas para espectáculos… prácticamente lo que se quiera.

Y la forma de lograr esta extensión y poder adaptarlo a las necesidades de cada uno es con el API que proporciona, y que al final está basado en PHP. Así pues, me he sumergido en el mundo de WordPress, PHP, JQuery, CSS… y todo el equipo.

Evidentemente no soy experto en este lenguaje pero intento adaptarme rápidamente a él. Y al principio, aunque sea de manera subconsciente, intentas verlo tal como ves al lenguaje que conoces que en mi caso es el Java. Y entonces compruebas que tiene alguna particularidad, si lo comparamos, que me hace verlo como un poco “raro”. Me refiero por ejemplo a que no es un lenguaje fuertemente tipado, más bien es dinámico e interpretado, más del estilo a javascript.

Estoy acostumbrado a que ciertas cosas como método que no existen, variables que no corresponden con el tipo esperado, las detecte y avise el compilador con la siempre familiar “aspa” roja. No es el caso en PHP, y muchas veces no ves el problema hasta que ejecutas la página. Esto produce al principio una cierta sensación de “fuera de control” que no es agradable.

La calidad empieza por las pruebas automatizadas

Pues bien, desde el primer momento, para andar con seguridad en este nuevo lenguaje y ser mínimamente productivo me propuse abrazar (con la fe del creyente) la práctica del TDD, que como sabes es el Desarrollo Guiado por Pruebas o Test Driven Development.

Según la Wikipedia, el proceso de TDD es el siguiente:

  1. Elegir un requisito
  2. Escribir una prueba
  3. Verificar que la prueba falla
  4. Escribir la implementación
  5. Ejecutar las pruebas automatizadas.
  6. Eliminación de duplicación (refactorización).
  7. Actualización de la lista de requisitos

Pues bien, puedo decir por experiencia que si aplicamos esto, tendremos varias ventajas practicas.

La primera es la tranquilidad de que una vez se tenga una batería de pruebas mínimamente completa, cualquier cambio o cosa que se añado nueva al desarrollo, puedo confiar en que no voy a romper nada de lo que he hecho anteriormente. Es decir, puedo ejecutar decenas de test de regresión sólo con escribir un comando en la consola.

La verdad es que no deja de sorprenderme cómo puede haber gente a estas alturas de la película que piensa que las pruebas automatizadas con una pérdida de tiempo y que no representan más que trabajo extra. Esto es como el árbol que no deja ver el bosque.

Todo el tiempo que inviertes en hacer una prueba unitaria se recupera multiplicado por diez.

Tu código tendrá infinitamente menos fallos, evitándote en primer lugar quedar mal con el cliente, incurrir en gastos de tiempo y dinero cuando este software falle y además en caso de haber un bug, encontrarlo en mucho menos tiempo.

Pensar antes de hacer

Además, siguiendo TDD, al hacer la prueba antes de la programación de la funcionalidad, te ayuda a concentrarte en lo que quieres obtener, en lo que quieres que te de el programa PHP en este caso. Primero piensas en esta funcionalidad y cómo la vas a usar, que métodos, qué parámetros de entrada/salida y de que tipo. Después lo implementas.

Esto te da cierta perspectiva, pensando primero en lo que “esperan de ti” en lugar a liarte a programar y hacer algo sin sentido.

Los test, la mejor y más fiable documentación

Además los propios test sirven como documentación de como usar el API que estas desarrollando. Está muy bien eso de documentar las funciones o los métodos en la cabecera con comentarios tipo javadoc o su equivalente en PHP. Sin embargo, en muchas ocasiones la procastinación te vence y te dices “ya lo documentaré mañana”. En la práctica, estos comentarios quedan incompletos o desfasados. Sin embargo, esto no ocurre con los test automatizados que has construido, simplemente porque son código “vivo”, definen el “estado del arte” de tu API.

La faceta “underground”

Ponerme con WordPress y PHP, también me ha servido para abrirme a un mundo más “underground”. Entiéndaseme bien lo que quiero decir: en mi trabajo diario, como arquitecto SOA en una gran empresa, tengo que pensar bajo otros parámetros, en como definir servicios SOA reutilizables y multicanal, haciendo una arquitectura que usarán varios equipos de desarrollo, tratando de que todas las aplicaciones se construyan de la misma manera, siguiendo una arquitectura común con el fin de facilitar el mantenimiento y sobre todo que sean estables y fiables sea quien sea la persona que las programe.

Sin embargo, como digo, como programador PHP y WordPress me encuentro en otra perspectiva. Pienso en proyectos más cortos y mucho más rápidos, sin ninguna restricción sobre que tecnología o API usar. Simplemente busco una solución que sirva para resolver mi problema, estudio su uso buscando tutoriales, ejemplos, etc. y si me conviene lo aplico sin más a mi desarrollo. Puedo aplicar las soluciones que vea, sin pensar en las repercusiones que tendrán esta decisiones en un decenas o centenares de personas.

Los extremos se tocan

Al final, por supuesto, ambos extremos se tocan (no son tan distantes) y cosas que descubro en mi faceta de “radical libre” la puedo aplicar a la arquitectura empresarial y conceptos que he aprendido en estos años de creación de frameworks de desarrollo los aplico a veces incluso de manera inconsciente en mi modesto API de wordpress.

En fin, un ejercicio muy enriquecedor. Y lo digo de verdad, sin ninguna pedantería. Para un arquitecto es muy conveniente no perder la perspectiva del desarrollador, ponerse en su piel y ver lo problemas del desarrollo como se ven desde su papel.

También, por supuesto, para un desarrollador es muy conveniente tener claros varios conceptos que podríamos considerar como “arquitecturales”. Al fin y al cabo, ser programador es más que alguien que junta piezas en una cadena de montaje ¿no?.

En Pensando En SOA | El problema de las pruebas de software  Probando un servicio web El problema de las pruebas en SOA

Foto | Matthew Cachia

Anuncios