archivo

Archivo de la etiqueta: programador

Este antipatrón surge en aquellos casos en los que los desarrolladores (o el equipo de desarrollo) dan por correctas determinadas funcionalidades sin haber pasado el suficiente número de casos de prueba que permitan testearlas teniendo en cuenta diversas casuísticas en los juegos de datos, en la interacción con terceros sistemas o en la propia operativa del usuario.

El testing de fogueo es una de las causas que provocan que un mayor número de defectos se detecten más tarde de lo que debieran, como por ejemplo en la integración con otros módulos, con otros sistemas o incluso en producción.

Aplicando testing de fogueo se obtiene una imagen del estado del proceso de desarrollo que no se corresponde con la realidad, por eso insisto mucho en que las funcionalidades tienen que estar bien probadas porque de lo contrario se crean expectativas en cuanto al avance de los trabajos que pueden provocar que, cuando nos demos cuenta de los problemas, sea demasiado tarde para reaccionar.

No se debe confundir con el antipatrón: “No probado pero finalizado, ya que este tipo de prácticas no son necesariamente provocadas por la necesidad de cumplir unos plazos más o menos complicados, sino que vienen “de serie” con los desarrolladores.

Ya lo decía Doug Linder: “Un buen programador es aquel que siempre mira a ambos lados antes de cruzar una calle que tiene un único sentido“.

Este antipatrón surge como consecuencia de múltiples cambios en una aplicación que se llevan a cabo de forma simultánea en el mismo, de manera que es posible que se haya aplicado la misma solución en diferentes partes del código, de manera que tendremos clases y/o métodos con un comportamiento parecido aunque tengan codificación diferente.

También es posible que se haya llegado a él, no por el hecho de no poder controlar la programación de personas distintas en diversas funcionalidades de la aplicación, sino por la mala práctica de ir copiando secciones de código, realizando las modificaciones oportunas, achacándolo a las prisas y a la presión por la entrega y/o por terceros.

Como consecuencia tenemos un código más complejo, con más deuda técnica y, por tanto, con un mayor esfuerzo de evolución y mantenimiento (hay que tener en cuenta que es posible que con estas prácticas, para hacer un cambio sea necesario hacer modificaciones en tantos puntos como ese código haya sido replicado).

El principio de Peter fue popularizado por los canadienses Laurence Johnston Peter y Raymond Hull en un libro homónimo publicado en 1969, con la famosa cita: “En una jerarquía, todo empleado tiende a ascender hasta su nivel de incompetencia… con el tiempo todos los puestos tienden a ser ocupados por un empleado que es incompetente para desempeñar sus funciones… El trabajo es realizado por aquellos empleados que todavía no han alcanzado su nivel de incompetencia”.

En ella trata de exponer uno de los principales inconvenientes de las organizaciones con promoción profesional vertical, en las que personas que son altamente competentes en unos puestos concretos, dejan de serlo en el momento en que ascienden a un puesto para que el que se requieren otras aptitudes.

De por sí, por típico en nuestro sector, podría ser considerado un antipatrón más. Sin embargo, en este artículo vamos a ver una versión de dicho principio directamente aplicada al desarrollo de software.

¿En qué consiste? Pues en el deterioro progresivo que sufre un software como consecuencia de su evolución y mantenimiento. Esto es una circunstancia que de manera general se produce en el desarrollo de software si bien puede ser contenida con buenas prácticas o acelerada en el caso contrario.

El antipatrón surge cuando un sistema está en continua evolución y no se toman medidas para mantener bajo control la deuda técnica y para seguir simplificando en lo posible su arquitectura y sus funcionalidades, de manera que si el sistema fue alguna vez útil, dejará de serlo poco a poco.

Como es algo que se suele producir lentamente y que tarda en detectarse, sobre todo si no estás acostumbrado a tener en cuenta estos aspectos, muchas personas consideran que es una forma de muerte silenciosa del sistema de información.

El principal motivo es la falta de cultura de producto por parte de los desarrolladores centrados principalmente en una cultura de proyecto orientada a la agenda y, por encima de ellos, de las organizaciones proveedoras y clientas de este tipo de servicios, que dejan en un segundo plano la calidad del software para centrarse en costes y beneficios.

El desarrollo de software es un continuo adelante y detrás no solo fruto del feedback o del cambios en las especificaciones sino también como parte del proceso de construcción. ¿Quién no tiene que corregir errores?, ¿quién no mejora una sección del código que no termina de convencerle?, ¿quién no tiene que realizar ajustes como consecuencia de evolución solicitada por el área usuaria?.

Este tema lo traté en artículo: “¿Qué es el mantenimiento?” y lo vuelvo a hacer ahora porque realmente el hecho de que en el desarrollo de software la frontera entre la construcción y el mantenimiento sea tan débil (por no decir inexistente) me parece muy interesante ya que refleja un aspecto inherente al desarrollo de software como es su naturaleza evolutiva, es decir, el sistema se desarrolla poco a poco y con el paso del tiempo va adquiriendo forma, en todo ese proceso hay evolución y no solo por los aspectos funcionales (o no funcionales) que se van añadiendo, modificando o eliminando sino porque en ese proceso el software también cambia y no necesariamente para cambiar una funcionalidad (refactorización, corrección de incidencias, etc…).

Esta naturaleza evolutiva junto a otra característica inherente al proceso de desarrollo como es la incertidumbre ponen de manifiesto que el software estará sometido a cambios a lo largo del proyecto (por muy diversas causas) y que será necesario habilitar los mecanismos necesarios para que la adaptación a los mismos se realice lo antes posible.

Me gusta el enfoque que Dave Thomas da sobre este tema (traducción libre): “Si nos fijamos en el tiempo que pasamos programando, escribimos un poco y luego volvemos atrás y hacemos un cambio. O volvemos atrás y corregimos una incidencia. O lo tiras todo o lo reemplazas por otra cosa”.

“Ya he terminado”, “esto ya está hecho”. Puede parecer que todos interpretamos lo mismo pero no es así. En absoluto es así.

En muchos casos “estar hecho” significa que ha programado la funcionalidad y que en el mejor de los casos le ha hecho un testing por encima a la misma, en otros casos “estar hecho” implica haber verificado en profundidad que funcione.

Muchas veces hemos podido escuchar sobre una persona: ¡qué rápido programa!. La velocidad de programación solo es un indicador válido si se contrasta con el número de errores que se han entregado y con la calidad del código.

Es importante que a personas con menos experiencia les indiquemos que es importante entregar pero todavía más importante entregar bien o lo que es lo mismo, es importante que todos tengan una interpretación común de lo que significa “estar hecho”. Si haces tu trabajo rápido y después hay que dedicar el doble de esfuerzo para ponerlo bien (y eso si se han detectado los errores a tiempo y no han llegado a producción) se han creado más problemas que soluciones.

Un amigo me comentó una vez que una cosa es la verificación de aspectos relacionados con la arquitectura del software, buenas prácticas y deuda técnica y otra cosa es el testing y que la mezcla de todos esos conceptos no produce buenos resultados porque se pierde el enfoque en lo realmente importante de cada una de esas áreas.

¿Cuál es mi opinión? Pues que todo es cuestión de definir adecuadamente cuáles son los objetivos en el caso de que todas esas tareas sean realizadas por un mismo equipo.

El esfuerzo de un equipo de testing debe centrarse en localizar el mayor número de errores posibles y los mismos no solo son consecuencia de un mal funcionamiento sino también pueden ser provocados por falta de coherencia funcional (algo muy común) o por problemas de carácter no funcional.

Ese trabajo no es sencillo, hacerlo bien requiere conocimientos y experiencia, sobre todo en contextos donde tienes que ir más allá de una documentación de referencia (algo que ocurre también muy a menudo) y en donde las exigencias son altas.

El testing merece respeto y si desgraciadamente no tiene el que merece no solo es provocado por la actitud de los programadores (que en mi opinión deberían hacer una reflexión al respecto) sino por un mal enfoque y unas malas prácticas que han provocado que en muchas ocasiones el esfuerzo dedicado al testing no haya obtenido unos resultados proporcionales al mismo.

En cierto modo le pasa lo mismo que al desarrollo de software donde los propios desarrolladores nos hemos encargados de maltratar nuestra profesión.

Cuando hablamos de mejorar la productividad o velocidad del desarrollo no solemos pensar en primera instancia en que ese software hay que probarlo, algo que es un error muy frecuente.

De hecho no se puede hablar de incremento de la productividad o de la velocidad si no va aparejado de un mantenimiento o mejora de la calidad de los entregables. De nada sirve llegar una semana antes si después te tienes que llevar dos semanas corrigiendo errores (en el mejor de los casos).

Ya sabemos que el testing se trabaja a distintas escalas, desde las pruebas unitarias, pasando por las de integración hasta llegar a las de sistema/aceptación. En función de la estrategia de desarrollo que utilices podrás trabajar a nivel de testing a menor o mayor nivel pero en ningún caso se puede renunciar a comprobar si lo que has desarrollado funciona y se corresponde con las especificaciones y esta tarea recae en el propio desarrollador y en personal dedicado al testing (si se dispone de él).

Estoy harto de ver casos en los que los desarrolladores no prueba de manera adecuada el software que desarrollan e independientemente de que en algún caso pueda haber dejadez, lo que falla principalmente es la técnica, aunque parezca mentira se puede saber programar estupendamente y después no tener ni idea de cómo hacer un testing efectivo.

Para terminar, os dejo una cita de Mary y Tom Poppendieck (traducción libre): “No importa lo rápido que desarrolles software si no eres capaz de hacerle un testing a la misma velocidad”.