Regla N°11 de la Ingeniería de Software: El primer código es para entender el problema, los restantes para hacerlo bien.

"En primavera de mi último curso en el instituto de Lisbon (o sea, en 1966) recibí un comentario manuscrito que cambió para siempre mi manera de enfocar las revisiones. Debajo de la firma del director, reproducida a máquina, figuraba a mano lo siguiente: «No es malo, pero está hinchado. Revisa la extensión. Fórmula: 2da versión = 1ra versión - 10%. Suerte.»", Mientras escribo, Stephen King, 2000.

Uno de los desafíos a los que nos enfrentamos los que nos dedicamos a crear sistemas software (de forma empresarial) es que debemos construir herramientas sobre ámbitos de negocio que no dominamos. Con lo cual nos enfrentamos a dos circunstancias:

• Comprender los requisitos de un sistema.
• Construir el sistema en sí.

En una metodólogia tradicional, tendremos el rol de analista, diseñador y codificador. El analista obtendrá los requisitos, el diseñador los convertirá en un modelo codificable, y el programador creara el código fuente. La posibilidad de que esos roles sean personas diferentes dependerá mucho de la empresa y de la situación en particular.

Como defensor del las metodologías agiles, creo que la mejor forma de comprender un problema es descomponiéndolo en problemas más sencillos y solucionándolos uno a uno.

Esto implica que hasta que no tengamos algo de código listo, no comprenderemos exactamente la necesidad que estamos intentando suplir. Es más, el ver la necesidad resulta, pueda cambiar los requisitos y la percepción sobre el problema real a tratar.

Los motivos anteriores hacen que el primer código no sea el más optimo, porque su objetivo está más orientado al análisis que a la implementación. La situación en este punto es tenemos un código que nos muestra una solución, pero es una solución temporal y estática (Si hubiera un cambio en los requisitos sería muy difícil de ajustar estar código para atenderlo).

Es por lo cual necesitamos realizar una segunda revisión del código, en estas caso ya no para resolver el problema de negocio, sino para asegurarnos que nuestro código sea de calidad, cumpliendo los siguientes requisitos:

• Que no tenga código repetido.
• Que se entienda claramente.
• Que tenga los comentarios, que seguramente omitiste la primera vez.
• Y el más importante, que se pueda mantener

Como último detalle debemos tener en cuenta que la segunda revisión debiera tener menos código que la primera escritura, pero no debemos confundirnos entre eliminar código innecesario y hacer el código ilegible o ofuscado. No se trata de eliminar líneas o condesar instrucciones en una sola línea, o cualquier tipo de reducción innecesaria que solo llevara a que el código no sea claro, y que no sea mantenible.