miércoles, junio 27, 2007

El mejor código es el que no existe

Bueno, la frase es demoledora y como toda frase lapidaria, conviene matizarla. Pero contiene tanta sabiduría (pesimista o realista, tu eliges) que creo que debe convertirse en uno de los mantras a repetirse frecuentemente.

Me lo recordó hace unos días la entrada de Jeff Atwood, The Best Code is No Code At All, muy recomendable. Si, antes de codificar, de desplegar miles de millones de líneas de código hay que pensárselo muy bien. Codificar es divertido, es muy estimulante... Pero antes de empezar, antes de abrir siquiera el editor debería pasar por la cabeza, en alguna milésima de segundo, al menos alguna de estas preguntas:

  • ¿Debo escribir este código?
  • ¿Estaré reinventado alguna rueda?
  • ¿Soluciona el problema que quiero solucionar?
  • ¿Se puede hacer mejor, más compacto, más legible, solo pensando un poquito antes de teclear?

Ya decía que conviene matizar: el programa vacío no hace nada y parece que es bueno que los programas hagan algo :) Se trata de un un recordatorio ¡Cuidado con el exceso de código! Creo que no hay aberración mayor que valorar la producción por líneas de código; es como si pagaran por bugs cometidos...

Jeff cita otro artículo en el que se exhorta a comenzar con código minimalista y completarlo a través de test. Es una buena idea, pero en estos tiempos de exaltación del Test-driven development conviene recordar también que los test no lo son todo, que pararse a pensar sigue siendo imprescindible.

En resumen serás esclavo de tu código, así que piénsatelo bien ;)

El mejor código es el que no existe, en barrapunto

7 comentarios:

Pablo dijo...

Interesante... entonces si un meme, por ejemplo, es un código de transmisión de la herencia cultural en el tiempo y el espacio, lo mejor sería que no existieran memes?

mig21 dijo...

Advertencia: La siguiente respuesta tiene un valor solo relativo. Se me va a ir la pelota, lo sé. Cualquier parecido con la coincidencia es pura realidad o algo así :P

Uhmmm, que interesante ;) Pero tengo que decir que no. Los memes, nos guste o no son la base de la cultura; sin memes, o con memes vacios, no hay cultura y sin cultura no hay conocimiento conservado, en general para mal. Y como sobre los memes no tengo control hablaré de los programas, sobre los que si lo tengo y la analogía puede, quizás, ser válida. Pero eso lo elige el lector...

Que no existan memes es análogo a que no haya programas: el vacio, la nada. La tesis de esta entrada es: minimiza el tamaño de tu programa maximizando su funcionalidad. Disminuye la entropía del código, pero sin disminur, en lo posible, lo que hace.

Respondiendo a la pregunta y acabando de hacer la analogía, lo mejor es que existan los mejores memes, los más depurados y con menos errores que podamos. Es nuestra responsabilidad eliminar los memes erróneos, depurar los útiles. Lo que ocurre que disminuir la entropía (localmente) consume mucha energía...

Saludos y gracias por tu interesante comentario.

Miguel

Anónimo dijo...

Esto me recuerda a una idea bastante equivocada sobre 'hacer algo es mejor que nada', por lo tanto: ¡algo habrá que hacer!

La realidad es que resulta más fácil no hacer algo estúpido que hacer algo inteligente.

Mark Ranum, creo que era, lo definía como el último nivel del kung fu profesional: obtener reconocimiento por no hacer algo :)

Muy acertado IMHO.

mig21 dijo...

Hola Juanjo!

obtener reconocimiento por no hacer algo

Si, esa es una fase superior. Pero es conveniente que a esa fase lleguen todos los involucrados en un proyecto. Que importante es que se valore la simplicidad en otros ámbitos además de en el técnico (en contraposición a la featuritis A ver si un día me animo a escribir sobre esto, que hay tema...) Todos deben llegar a la vez a la iluminación :)

Un saludo
Miguel

LgEaObNrAiReDlO dijo...

Muy interesante, para resumirlo hay una frase del libro de ingeniería en sistema de Pressman que me quedo grabada (en realidad es lo único que me quedó del libro) que dice así.
"Cuando antes comiences a escribir código más tardarás en terminarlo"

mig21 dijo...

"Cuando antes comiences a escribir código más tardarás en terminarlo"

Uhm... eso tiene dos lecturas y en labios de Pressman me temo que es la que me gusta menos :)

Una lectura es la de que conviene tener los requisitos cerrados para luego hacer un análisis y un diseño estupendos para, por fin empezar a codificar... Eso en el mundo perfecto de los procesos perfectos...

...yo soy más partidario de posiciones más pragmáticas, en las que se parte del hecho de que el diseño habrá que tocarlo y modificarlo, con lo que es mejor tener algo que funcione, pero con una cierta modularización antes que un diseño perfecto sin una línea de código.

Creo que el secreto está en "una cierta modularización": no creo en la modularización perfecta a priori ni en la codificación salvaje. Creo que el mejor método es tomar las microdecisiones del día a día con cabeza, ir construyendo poco a poco, línea a línea, decisión tras decisión algo que vaya teniendo coherencia. Pero no creo en la coherencia a priori, sino en la que va madurando, en la que se va confrontando con los hechos.

En ese sentido la frase me parece correcta: no corras a codificar, piensa un poco, medita sobre la coherencia interna y externa de lo que estás haciendo, piensa si se puede hacer mejor, en menos pasos, etc.

Pero el error contrario es demasiado común: no tener nada codificado y pensar que, con los UML's y el diseño de tablas está el problema solucionado.

Gracias el comentario, Leonardo. Ya ves que has dado con el dedo en la llaga, porque no había escrito un respuesta tan larga en mi vida ;)

Un saludo
Miguel

Anónimo dijo...

Miguel,
Veo que di en la llaga, por supuesto citanmo más frases "todos los extremos son malos" pero el programador sin experiencia (y mucho el ella) se lanzan como locos a escribir sin pensar ni un poco, lo que suele resultar en un sistema que nunca se termina y que al final nadie quiere. Por otro lado el otro extremo es casi peor, suponer que todo está bien porque se tiene un sistema 100% funcional "en papel", gran error, después se lo damos a desarrolladores novatos y listo, total está todo en la documentación; por supuesto que estoy de acuerdo con vos, viniendo de Pressman lo más probable es que apoye la segunda opción, la idea de la frase era causar una reacción. Las metodologías ágiles nos muestran lo que vos comentás, iteraciones, objetivos cumplibles, versiones, pruebas, feedback, agregar funcionalidad, versiones, etc. Bueno es un tema interesante, el punto álgido que veo es que muchas veces pasa desapercibido el echo de que es necesario un ambiente particular para que una metodología ágil funcione, no es cuestión de pararse en un banquito y gritar el manifiesto ágil y todo comienza a mejorar....bueno, es un tema largo.

Saudos, Leonardo.