Este es un proyecto cancelado que no recibe actualizaciones. No obstante, puedes acceder a su archivo como referencia.

Versión Cero

Prioridades al escribir código

Sergio Montoro

La programación requiere de un difícil compromiso entre los muchos objetivos de nuestro código. ¿Debe ser rápido? ¿Debe ser mantenible? ¿Cuales son las prioridades de nuestro código?

por Sergio Montoro Ten, 3 enero 06

Un principio básico de cualquier estrategia es que implica renunciar a unas cosas para conseguir otras. Si no hay compromiso de renuncia, entonces no hay estrategia, sólo fuerza bruta.

Curiosamente, cuando se fabrica software rara vez se define explícitamente una estrategia para su desarrollo. Se elaboran especificaciones, se designan estándares, se imponen normas de codificación, se eligen herramientas de modelado y bug tracking… Pero es poco frecuente encontrar un apartado en el proyecto que diga qué estrategia se debe seguir al escribir el código.

La estrategia de codificación a la que me refiero consiste en fijar una serie de prioridades a la hora de tomar decisiones, por ejemplo:

1. Corrección
2. Usabilidad
3. Mantenibilidad
4. Portabilidad
5. Claridad
6. Consistencia
7. Testeabilidad
8. Eficiencia computacional
9. Tamaño del ejecutable
10. Uso de estándares

La lista anterior, por supuesto, debe cambiar en contenido y orden para cada proyecto. Lo importante es llegar a un acuerdo y que todos los programadores la conozcan.

Aunque las prioridades cambien, existe una, al menos, que debería ser siempre la estrella: que el programa funcione bien, en el sentido de que para todas las entradas aceptables proporcione salidas correctas.

Esto que parece obvio como primera prioridad, paradójicamente, no siempre se cumple. En el (ya algo vetusto) libro The Psychology of Computer Programming Gerald Weinberg expone un ejemplo de ello. Cuenta el caso de un programa para hacer la lista de componentes de un automóvil a partir de los extras solicitados por el cliente: aire acondicionado, elevalunas eléctrico, etc. Dicho programa se había ido codificando manualmente hasta convertirse en un spaghetti cuyo mantenimiento era una pesadilla. Llegado un punto el equipo decidió substituir la monstruosa complejidad ciclométrica del viejo programa por un nuevo sistema de decisión basado en matrices externas al código. Las reglas codificadas a fuego en el programa se re-escribieron con matrices. El problema era que el nuevo programa era muchísimo más lento que el anterior, y, peor aún, no se habían trasladado bien todas las intrincadas reglas del código a las matrices y el nuevo sistema sencillamente producía escandallos incorrectos. Esto producía conflictos entre los programadores, partidarios de seguir invirtiendo en el nuevo sistema, y los usuarios, que preferían continuar con el antiguo, porque en último término la calidad es lo que percibe el usuario final.

Otro error estratégico común es la falta de foco en lo que se está haciendo. Muchas veces he escuchado a programadores que describen sus programas en términos de cómo están hechos, o de lo que puedes hacer con ellos, pero no en términos de lo que hacen realmente. No hay que olvidar que una de las causas principales de que fracasen tantos proyectos informáticos es que los programadores, y sus jefes, son incapaces de acotar y priorizar las funcionalidades requeridas. Para ilustrar esto gráficamente, en una etapa de mi carrera trabajé para un empleador que fabricaba un ambicioso ERP. Era un sistema parametrizable y con su propio lenguaje de programación. Tenía tantas herramientas que, al final, el primer año de producción de la nueva versión había transcurrido desarrollando los kits de desarrollo mientras que la funcionalidad real que debía tener el ERP estaba prácticamente sin hacer.

Comentarios
1 Cesar Tardaguila
4 enero 2006, 00:42

Es difícil, desde luego, determinar cuál debe ser la primera prioridad en cada caso, sobre todo por eso, porque dependerá del proyecto.

En mi caso personal, y por mi experiencia durante los últimos años, lo tengo bastante claro. Lo primero es la robustez del código, incluyendo dentro de la robustez la mayor cohesión posible y el menor acoplamiento posible, lo que lo va a hacer escalable, fácil de mantener y portable. A partir de ahí lo más importante serían la legibilidad y la eficiencia.


2 rastafari
4 enero 2006, 11:29

Es muy cierto que es habitual olvidar cuales son las prioridades a la hora de escribir el código o diseñar el proyecto y al final estos elementos quedan en manos de la decisión o el empeño personal de cada analista o programador.

Se cometen muchos errores de esta indole, como por ejemplo dedicarle mucho tiempo a optimizar una rutina cuando se va a ejecutar en un proceso que no es critico, dedicar mucho tiempo ha hacer un diseño extensible de una parte del proyecto cuando en realidad se va a implementar una funcionalidad muy concreta que no va a extenderse en el futuro, y así muchos otros errores.

Eso si, yo no hablaria sólo de prioridades a la hora de escribir código sino de prioridades a la hora de diseñar y escribir código, estos errores de no tener claras las prioridades se cometen también en la etapa de diseño.

Otro tema es a que nivel definir estas prioridades, a nivel de proyecto me parece demasiado arriba, es muy posible que dentro de un mismo proyecto diferentes partes del mismo no requieran las mimas prioridades, como ejemplo en un determinado proyecto teniamos un proceso que se debia ejecutar en forma de servicio de manera indefinida, al estar programado en C++ era fundamental poner cuidado y eliminar todos los posibles leaks, por tanto el codificar con especial cuidado para no perder ni un byte de memoria era fundamental en esta parte del proyecto. Esto no era necesario con otras partes del código donde no realizar pruebas exhaustivas de consumo de memoria y codificar con “menos cuidado” podia ser aceptable.


3 Sergio Montoro Ten
4 enero 2006, 11:57

Alfredo, tienes razón en que el nivel en que se fijen las prioridades puede ser importante.

Hay que tener una política global pero luego hay que saber flexibilizarla con “mejores prácticas” para cada departamento.

Tan malo es no tener ni idea de por dónde se navega, como aplicar un rumbo a timón fijo contra viento y marea.

Acerca de las sobre-optimizaciones, una vez a mi me dijeron una frase de esas con las que te quedas: “Oye, ¿tu sabes lo que le cuesta un IF a la CPU? Entonces, ¿para qué te vas a molestar en quitarlo?”


Acerca - Contacto - Información legal y técnica - Condiciones de uso - Noticias sobre el mundo del Desarrollo de Software.