miércoles, 28 de mayo de 2008

Codificando... divagando... es lo mismo.

Hace un par de días (en realidad hoy pero no creo que postee esto hasta dentro de un par de días) tuve un amigable intercambio de opiniones con un muy respetado compañero de trabajo, mientras volvíamos a nuestros respectivos hogares. Sé que puede sonar irónico así que aclaro que no lo es, realmente fue un amigable intercambio de opiniones.

En general me cuesta bastante mantener el foco de una discusión amigable cuando no tengo un interés especial en ella y se me presenta como una típica charla inconducente entre amigos. Así que derivamos de aquí para allá hasta hablar de mujeres, tema final para cualquiera de estas situaciones.

Así que antes de hablar de mujeres, hablábamos alrededor de lo que es "programar" (mujeres y computadoras, mujeres y autos, mujeres y fútbol, qué típicos que somos), momento en el que divagué un poco acerca de lo que yo pienso cuando escribo código, tema que pasó pero que me quedó dando vueltas.

El hecho es que quisiera explayarme un poco sobre eso, no para adoctrinar ni para enunciar la verdad revelada -que no la es, realmente- sino porque me da curiosidad saber si es una forma rara de ver las cosas o si por el contrario alguna o mucha gente coincide conmigo.

Vamos primero por la negativa. Cuando programo:

  • No pienso en el problema, porque cuando estoy tecleando es que ya lo tengo resuelto (mi despliegue físico de resolución de problemas se acerca más a la imagen de un tipo tomando una siesta o vagueando por ahí que a la de uno trabajando).
  • Tampoco pienso demasiado en el código en sí mismo, porque ya hace casi dos años que programo en C# con el .Net 2.0 todos los santos días y tengo buena memoria para el lenguaje.

¡Caramba (por no decir mi...)! ¿Es que pienso en algo? Esto explicaría muchas cosas...

Y es que no, no estoy pensando si se entiende por ello el buscar una solución a un problema, o el buscar algo en la memoria. Más bien estoy en un estado parecido al de este mismo momento (ésa es la idea que me llamó la atención). Estoy escribiendo, como quien escribe un documento, una carta, o lo que sea. Y como todo autor, le escribo a un lector imaginario (¡en serio!).

Programo más o menos como escribo. Primero largo todo de una tirada, una especie de memory dump, y después la voy repasando y repasando y repasando, hasta que queda algo que me parece que se entiende. Después compilo, arreglando siempre errores de tipeo o causados por las sucesivas correcciones y pruebo. En general si la prueba no sale bien -sin contar detalles menores que de esos hay miles-, me doy cuenta de que me equivoqué en la resolución del problema (no en la codificación) y vuelvo a ese estado de somnoliencia o vagancia que mencioné antes, que es el de la resolución del problema (por ejemplo ahora que escribí un montón, voy a releer, y talvez borre esta misma frase... ya releí, se queda).

Esto me trae una serie de interesantes reflexiones sobre mí mismo, así que el lector aburrido o molesto por mi estado de brutal egocentrismo (por ahora es MI blog) puede abandonar en este punto, no sin antes comentar si le pasa lo mismo o no, o cómo es que le pasa.

Me cuesta horrores explicar cómo resolver un problema codificando porque yo no lo resuelvo de esa manera. Nunca llegué a entender esos métodos de resolución semi-automáticos que van desgranando la cosa mecánicamente. Uso el lenguaje, los gráficos y las herramientas para ayudarme a dividirlo en partes manejables e ir enfocándolas de a una, para ir anotando, pero no para resolverlo.

Sostengo que el código que no entiendo no sirve, porque me considero un buen lector de código. Creo que nos pasa a todos los que sabemos leer. Si uno lee y no encuentra el más mínimo sentido no dice "esto debe decir algo pero yo no lo entiendo", sino "esto no es castellano". Bueno, yo pienso "esto no es código". Tiendo a evaluarlo por su nivel de comprensión, no por su eficiencia u optimización (tengo que aclarar que usualmente trabajo con sistemas administrativos, en los cuales la optimización es requerida sólo en algunos procesos muy acotados).

A veces escribo (codifico) mal, lo sé porque hay veces que me leo y no me entiendo. Muchas de esas veces ni siquiera recuerdo haber escrito "esto" (y lanzo un par de amenazas del tipo "¿quién hizo tal cosa?" y quedo bien ridículo cuando el magnánimo control de código fuente me apunta con un dedo condenatorio). En general es cuando lo hago por obligación, y no por un deseo propio.

Bueno, ¿alguien llegó hasta acá? ¡Hey! ¡Ya es de día! ¡Hay que levantarse! Si alguien llegó hasta acá que se haga cargo y deje un comentario.

Saludos.

3 comentarios:

Miguel Angel dijo...

Hola!

Yo creo que soy como tú en ese aspecto... Los problemas los resuelvo (o intento resolver) en un papel, o en dos, o los que hagan falta con una buena cantidad de garabatos de la primera cosa que pille que pinte (rotulador, lapiz, bolígrafo, me es igual). Cuando entre los garabatos creo que tengo una solución entonces lo intento pintar de una manera medio legible. Pero nada de código: cuadrados, flechas, palabras sueltas, números...

Una vez hecho eso entro en "Fase de codificación": Me convierto en una especie de robot monotarea, con la música bien fuerte en los auriculares y tecleo (codifico) a la misma velocidad que escribo estas lineas.

Sí, se puede decir que me pasa lo mismo que a tí :)

Un saludo!

Cerebrado dijo...

Todos pensamos (o resolvemos) antes de escribir. La diferencia radica en el "tamaño" de la porción del problema que tomemos. Si tengo una regla de negocio complicada, decido separarla en partes mas pequeñas, algunas de esas partes ya las habré resuelto antes y la escritura será automática, pero para otras necesitaré un tiempo mas de análisis.

Alguien que ya haya resuelto todo el problema antes (y tenga la solución incorporada) comenzará a escribir inmediatamente.

Cuando se "analiza" mientras se codifica suscede una de dos (o ambas) opciones:

1)La solución encontrada es errónea pero sabemos que estamos cerca y solo hace falta un pequeño replanteo, que se refleja en el código.
2) El lenguaje no permite (o no lo conocemos lo suficiente como para) implementar la solución elegida.

En ambos casos, repensamos despues de empezar a codificar.


Personalmente, cuando estoy terminando de probar una "porción" de la solución, ya estoy pensando en la etapa siguiente, entonces parece que escribo sin pensar, pero lo que realmente ocurre es que las porciones de solución son tan chicas que el tiempo de proceso es mínimo (puede ser porque tengo años de experiencia en ésto), tan pequeño que cabe en el espacio de tiempo que hay entre terminar de escribir una y empezar con la otra.

Sebastián Streiger dijo...

Hola,
Muy interesante el post.
En general, creo que todos los programadores pasamos por esas etapas de resolución y codificación, cada uno con distintas capacidades. Depende de la capacidad de análisis y resolución y de la familiaridad con el lenguaje cuanto le ocupa cada una de las etapas.
En Pair-Programming se sugiere que aumenta la calidad del código porque uno desarrollador se concentra en la parte estratégica y el otro en la codificación en sí.

Respecto de la frase "Nunca llegué a entender esos métodos de resolución semi-automáticos que van desgranando la cosa mecánicamente", entiendo que se refiere (a modo de ejemplo) a la metodología Top-Down. Pero este método solo enuncia como proceder para ir describiendo el problema, que si bien en gran medida condiciona la variedad de ideas que podemos plasmar, de ninguna manera la explica. En esta aspecto, se puede hacer un paralelo con la ciencia: El método científico indica como debe validarse una teoría, pero no explica de ninguna manera cual es la forma de imaginarla. No explica los pasos a seguir para obtener teorías geniales.
Cerebrado: un poco de modestia por favor...