He realizado todos los aspectos del desarrollo. Organicé los requerimientos, modelé las tablas, implementé los modelos, los controladores, y las vistas.
Trato de seguir el principio KISS, de mantener las cosas tan simples como sean posibles, pero no suele ser algo fácil.
Muchas veces he tenido la tentación de hacer algo que quede bien, para el futuro, o para cierto público exigente que me imagino debo complacer. Paso algo de tiempo divagando, pero eventualmente (afortunadamente) retomo la forma KISS.
Me parece que cuando uno ve código profesional, y está comenzando, puede tener la falsa impresión de que ese código se produce directamente tal cual lo vemos. Cuando vamos ganando experiencia es que notamos que es necesario pasar por soluciones intermedias para llegar a la solución final.
Pensándolo bien, así ocurre en otros tipos de desarrollo. Y puede que sea la forma natural de hacerlo.
Por ejemplo, una pintura que vemos colgada sobre una pared no es realizada directamente en limpio. Antes hubo un bosquejo, posiblemente sucio y horrible de ver, pero necesario para que llegara a existir. Un bosquejo que fue cambiado y corregido muchas veces antes de dar la primera pincelada. Luego, los colores se fueron aplicando por capas y zonas, de acuerdo a ciertos principios y técnicas, y también sufriendo cambios y correcciones mientras la imagen se aproximaba al ideal imaginado.
No tengo mucha técnica dibujando y mucho menos pintando, sin embargo, recuerdo algunas experiencias.
Recuerdo que, al comienzo, sin mucha guía, hubo veces que intentaba obtener directamente la versión final de una obra. Me concentraba en un área pequeña hasta completarla y luego avanzaba a un área siguiente.
No pasaba mucho tiempo hasta que notaba que algo andaba mal con el rostro que intentaba reproducir. Quizás cada parte por separado estuviera bien, pero el conjunto estaba, como se dice, descuadrado. Descubrí que me iba mejor si trazaba antes algunas líneas guía, que me ayudaran a recordar el tamaño, la posición y la forma aproximada de los ojos, la nariz, las orejas, y los labios, y luego recién desarrollar cada una de esas partes; es decir, bosquejar primero y desarrollar después.
Si se trataba de una imagen de cuerpo entero o donde aparecieran varios personajes, el bosquejo era mucho mejor opción que intentar lograr la composición directamente.
Puede ser que la costumbre de copiar dibujos es la que nos habituó a pensar que hacer una imagen por áreas, secuencialmente, era la única forma.
Pero es cuando uno trata de hacer una composición propia que descubre que es mejor trabajar por capas, iteradamente, mejorando cada vez la capa anterior.
Bailar es parecido. Al menos para mí. Aunque hay personas que insisten en tener memorizados pasos perfectos antes de comenzar a ensamblarlos, yo creo que es mucho mejor tener primero la secuencia, es decir el bosquejo de todo el baile y sus movimientos generales.
De ese modo puedo aproximarme con mas facilidad y menos frustraciones a la idea, y sentir cierta armonía que guía y ayuda a ir puliendo los pasos.
Planear la ruta de un largo viaje también es parecido. Es agotador, y hasta iluso, tener de antemano el detalle de cada tramo de la ruta, porque la práctica está llena de imprevistos. Es mejor hacer un bosquejo general, indicar los hitos principales, e ir desarrollando los tramos a medida que vamos avanzando.
Y para programar, he descubierto que también es similar.
No es malo hacer código repetitivo, usar muchas variables, ni otras cosas que muchos temen como si fueran pecados capitales.
No es malo, del mismo modo que no es malo garabatear una hoja cuando se está bosquejando.
Algunas veces para llegar a cierta posición, incluso puede ser necesario crear material auxiliar que luego se desecha.
Al inicio, lo principal no es la perfección ni la optimización, sino que simplemente funcione. Primero que funcione, luego se optimiza, me parece que dice un dicho de los hacker.
Claro que presentar código repetitivo, con demasiadas variables, o no optimizado, como versión final de un producto es como presentar un bosquejo en lugar del cuadro terminado. No te tomarán en serio, a menos que seas Leonardo.
Además, para desarrollar algo, es importante comenzar. No quedarse atorado en la trampa del perfeccionismo, ni esperar que todas las estrellas estén alineadas para dar el primer paso. Simplemente comenzar; dar el primer trivial paso; escribir código sucio quizá, pero que funcione. Luego se podrá factorizar, reorganizar, simplificar.
Factorizar es extraer el factor común de una expresión, de modo que se forma una expresión más simple o menos repetitiva. Es lo que se hace en álgebra.
Si alguien lo recuerda, no es conveniente factorizar una expresión cada vez que se le agrega algo; suele ser mejor esperar hasta que todos los términos estén presentes, para ver mejor el patrón. Si uno hace una factorización prematura, suele requerir un esfuerzo adicional desatar lo ya atado para ingresar el cambio y luego volverlo a atar.
De modo similar en programación. Es mejor no optimizar prematuramente el código, sino esperar hasta que esté completo para ver mejor el patrón, y luego factorizar. La optimización prematura puede fácilmente complicar el desarrollo. El código optimizado es mucho más difícil de depurar. Se debe optimizar, pero a su tiempo.
No hay comentarios.:
Publicar un comentario