Una balanza que no funciona

Llega el día en que nos dedicamos al desarrollo, ya sea por libre, en una empresa, para investigación o en cualquier otra circunstancia; tenemos que poner en práctica lo aprendido durante tanto tiempo y no estamos haciendo simples ejercicios ni programas de un máximo de 200 líneas (con muchos espacios en blanco, comentarios multi-línea y esas cosas).
Es decir, nos enfrentamos a un proyecto real y tenemos que dar lo mejor de nosotros mismos en su realización.
Como tampoco es un proyecto excesivamente grande decidimos pasar de hacer una planificación previa del proyecto, y decidimos que es más rápido pasar a la acción y ponernos a picar código.
Comprendo que si no se tiene mucha experiencia, es una tarea intelectualmente más ligera ponernos a escribir de forma estructurada nuestros algoritmos, excepcionalmente haciendo alguna función; no tenemos tiempo para separar estructuras, ni para idear algún algoritmo extra que nos simplifique un poco el código, pero no le damos importancia… simplemente nos damos el batacazo cuando el cliente nos pide un pequeño cambio en el código; de repente se nos viene a la cabeza la famosa teoría del caos. Y es que nuestro código es un caos. Y no comprendemos que el cliente (a no ser que seamos nosotros mismos), usuario, jefe, o persona que necesita el programa pero no tiene ni idea de cómo se desarrolla tiende a pensar que todos los cambios son pequeños y que cualquier modificación se hace en 10 minutos; por tanto, la primera versión de nuestro código no va a servir, y tenemos que distinguir entre: pijadas, o modificaciones en la interfaz, cosas que harían el programa más bonito; entrada/salida, tal vez campos de una base de datos que se suponía que teníamos que introducir y que no están (será porque nadie nos había informado de que la posición en que una persona jugaba al fútbol de pequeño era un dato personal básico e importantísimo); o que está visualizando más datos de los que quiere; cambios estructurales, esos ya son más peliagudos, pero bueno.
Lo que quiero decir, es que la versión preliminar que hagamos casi nunca va a ser la buena y tendremos que revisarlo, incluso al cabo de un tiempo, se necesitará añadir una característica más, y la hemos liao si seguimos por este camino.

Tenemos que hacer de nuestro código un arte:

• Podemos comentar en nuestro idioma hasta la saciedad, aunque sin pasarnos.
• Podemos dividir nuestro código, e incluso cuando hacemos cosas muy parecidas podemos unificarlas en una función/clase/proceso diferente. El lema divide y vencerás es muy útil, y a la larga hace nuestra aplicación más facilmente mantenible.
• Podemos separar la lógica del programa, con lo relativo a datos y lo relativo a la visualización (MVC)… programar a pegotón no ayuda.
• A veces, con alguna operación matemática, nos podemos ahorrar una secuencia iterativa
• No por mucho que tarde nuestro programa en hacer una tarea determinada, lo hace más profesional, aunque hay empresas que esto no lo tienen muy claro.

Si bien es cierto que cuando llamamos a funciones estamos haciendo la ejecución de nuestro código más lenta (con operaciones recursivas ya ni hablamos), tenemos que tener en cuenta si podemos sacrificar unos cuantos milisegundos en la ejecución en favor de unas cuantas horas de desarrollo, y es que muchas veces, crear una función, incluso para hacer nuestro código más legible (por ejemplo, si estamos presentando los resultados de una búsqueda, y necesitamos ordenarlos, no tenemos por qué implementar el método de ordenación en el mismo sitio, nos lo podemos llevar fuera; incluso si tenemos que presentarlo de forma bonita para el usuario, podemos hacer una función aparte que presente esos datos), puede ahorrarnos mucho tiempo de mantenimiento; cuando al cabo de dos semanas nos enfrentemos de nuevo a nuestro código, seguro que preferimos ver las cosas más claras.

Dando ejemplos (no todo se hace en los lenguajes mencionados, esto lo podemos extender a muchos lenguajes más):

• Vale, estamos diseñando un sistema de tiempo real y tiene que funcionar rápido, como ejecutamos las órdenes muchas veces, no podemos queremos hacer funciones ni hacer nada complicado, para no ralentizar mucho la ejecución… en C/C++, por ejemplo, podemos crear macros.
• Nuestras necesidades pueden ser más complicadas, tenemos que tener en cuenta que un lenguaje de programación, nos da herramientas básicas, y las podemos extender. Imaginad el uso de mysql_query() [PHP], puede que necesitemos contar cuántas veces se ha llamado esta función. Esto implicaría ver dónde se ha llamado la función e incrementar una variable, aunque tal vez en el futuro tengamos más necesidades.
• Ya no hablamos de la abstracción con objetos, al principio nos choca esa forma nueva de pensar, pero a la hora de embarcarnos en un proyecto, de primeras no la tenemos muy en cuenta. Por ejemplo, en C++ o en PHP es muy cómodo trabajar con una clase que se entienda con las bases de datos, nosotros símplemente tenemos que llamarla siempre que necesitemos algo.
• A la hora de hacer una web dinámica se piensa poco en un posible re-diseño, y cuando este llega nos echamos las manos a la cabeza ya que hemos puesto multitud de código PHP entre el (x)html… podremos crear una biblioteca de funciones dedicada a la exportación web y desde nuestro php llamarlas… haría fáciles los re-diseños.

Todo esto viene unido a un post anterior: Enseñando a programar, sobre todo porque en muchos lugares se enseña programación (me refiero a carreras universitarias que no tienen que ver con informática; algunos ciclos formativos, etc) pero uno de los grandes objetivos es que nos sirva para el futuro; y de poco sirve si no se sientan unas bases. Es importante el reciclaje, la claridad y la sostenibilidad.

Foto: Feliciano

También podría interesarte....