Los dos riesgos de un código fuente difícil de entender

Los dos riesgos de un código fuente difícil de entender

Comentaremos de dos maneras en que algo difícil de entender hace que nuestro trabajo sea más complicado.

1. “No lo entiendo, necesito más tiempo”

Las personas pueden estudiar el texto y terminar sabiendo que no comprendieron lo leído. Esto es problemático en el aspecto de que quedan dudas y nos tomará más tiempo hacer nuestro trabajo.

Probablemente necesitaremos buscar a un programador con experiencia previa en dicho código fuente para que nos ayude a mejorar el código para entender. Incluso podría ser mejor borrar y reescribir esa sección de código. De todas maneras, el código anterior debíamos probarlo completo, así que una reescritura podría ser más eficiente que tratar de trabajar sobre algo riesgoso.

2. “Lo entendí mal, e introduje un defecto”

El primer punto es un problema, sin embargo es más problemático cuando las personas creen que comprendieron el texto pero realmente no lo hicieron. En tal caso, tanto el escritor como el lector del texto tienen interpretaciones diferentes. Cuando un programador tiene solamente al código fuente como la fuente de su conocimiento y no es fácil de entender, entonces tomará decisiones equivocadas al programar y al probar.

Para evitar las consecuencias anteriores, tenemos tres técnicas:

1. Nombres claros: Nos ayudan a úbicarnos más fácilmente en los detalles

Necesitamos escribir el código fuente usando las mismas palabras que usan nuestros clientes. Los nombres deben ser pronunciables de manera que podamos hablar de ellos en voz alta.

En el siguiente ejemplo, cada palabra es pronunciable y nos a ayuda a entender cómo se obtiene el “Valor Transado Bruto como número”:

codigo-final

El esfuerzo que invertimos al pensar buenos nombres nos dará ayudará la próxima vez que alguien necesite leer el algoritmo. El retorno de dicha inversión es que  a futuro tendremos menores costos de desarrollo de cada cambio.

2. Pruebas unitarias Nos ayudan a entender qué hace el algoritmo

El código fuente debería explicarse a través de pruebas unitarias. Estas ayudan a entender qué hace dicho algoritmo. Cada prueba unitaria es un ejemplo concreto de datos de entrada y resultados esperados, así que son la mejor documentación que un algoritmo puede tener para evitar que alguien a futuro tome decisiones equivocadas.

En este ejemplo, tenemos los datos de entrada bien descritos . El algoritmo genera el “Monto de la valoración en colones como número” a partir de los “Datos en UDES”.

prueba-unitaria-es-un-ejemplo

Si un programador a futuro introduce un defecto en ese objeto, la prueba unitaria fallará, indicando que el comportamiento ya no es el esperado. Esto evitará que entreguemos un algoritmo incorrecto a nuestros clientes.

El retorno de la inversión que hacemos al escribir las pruebas es que a futuro ahorarremos los costos de corregir errores durante la realización de cambios y además que tendremos menos errores que llegan hasta los usuarios de la aplicación.

3. Una estructura cohesiva: Nos ayudan a entender lo general sin necesidad de leer todos los detalles.

El código fuente debería poderse visualizar como un grafo de comunicación entre clases. Si cada una de estas partes está estructurada como un objeto de responsabilidad única, entonces cada funcionalidad podremos mirarla en su generalidad sin tener que leer los detalles (las variables y sus operaciones), y tendremos una vista como la siguiente:

arbol-de-objetos

Así podremos navegar la estructura sin perder de vista el todo, y cuando realicemos un cambio este quedará restringido a una rama de llamados. De hecho, las pruebas unitarias nos indicarán el área afectada por cualquier cambio o defecto, lo que nos hará más eficientes. En este otro artículo podemos leer más acerca de cómo Trabajar con las pruebas unitarias en un algoritmo con objetos.

El esfuerzo que invertimos al estructurar el código como piezas de responsabilidad única (cohesión), nos paga sus dividendos cuando volvemos a él y nos permite navegar por el algoritmo sin leer todos los detalles. Los buenos nombres nos permiten una comprensión casi a primera vista, y las pruebas unitarias posibilitan un análisis de impacto metódico y confiable.

En resumen, los dos riesgos de un código fuente difícil de entender son mayores costos y tiempo, y la generación de un software con defectos. Un equipo de desarrollo bien entrenado puede evitarlos con buenos nombres, pruebas unitarias y un código bien estructurado.

A través de la serie Algoritmos Mantenibles estudiamos cómo programar de esta manera. ¿Dudas? ¡Será un gusto conversar al respecto!

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

w

Conectando a %s