Posteado por: israelantezana | 3 - enero - 2009

¿Por qué tu código apesta?

Por: Dave Astels

Traducido por: Israel Antezana R. 
Del original en igles en: http://techblog.daveastels.com/2005/01/12/why-your-code-sucks/

Resumen

Si eres como la mayoría, e incluso posiblemente todos, los programadores (este humilde autor incluido) entonces tu código apesta. Quizás no todo tu código, y talvez no todo el tiempo, pero si ciertamente parte de tu código, en algún momento.  

Tu código apesta si no funciona.

¿Tu código funciona? ¿Cómo lo sabes? ¿Puedes probarlo?

Si no tienes pruebas para tu código, este apesta. Y me refiero a pruebas de programador compresibles, de granularidad fina (también conocidas como pruebas de unidad), como también a pruebas de nivel más alto funcional y de integración. Pruebas que están automatizadas. Pruebas que se ejecutan de forma rutinaria. Pruebas de programador que se ejecutan después de que se realiza cualquier modificación al código.

Sin pruebas adecuadas (tanto en término de cantidad  como de calidad) simplemente no puedes tener confidencia de que tu código funciona como se requiere. E incluso si tienes confianza en tu trabajo… ¿Por qué cualquier otro lo debería hacer? ¿Qué sobre las personas que trabajarán con el código después? ¿Cómo saben si el código aún funciona luego de que realizan cambios?

Tu código apesta si no es comprobable

Bien, entonces decides añadir pruebas a tu código. Típicamente esto no es tan fácil. Es muy posible que tu código no haya sido diseñado y/o implementado para ser fácil de probar. Eso significa que tendrás que realizar cambios en él para hacerlo más fácil de probar… sin romper ninguna de sus partes (en la actualidad usualmente esto se conoce como refactorización). Pero ¿cómo puedes rápida y fácilmente decir si has roto algo sin ese conjunto de pruebas de granularidad fina? Esto no es fácil.

Es más difícil de lo que crees. Si decides escribir las pruebas para todo tu código después de que escribes el código, tienes que realizar el esfuerzo adicional de tratar y diseñar/escribir el código para que pueda ser probado.

Mantener un nivel adecuado de pruebas cuando escribes las pruebas después del código que estás probando toma tiempo y planificación. Y si tienes que realizar trabajo adicional para hacer que tu código pueda ser probado…bueno…eso apesta.

Escribir pruebas antes de que escribas el código significa que el código es comprobable por definición. Si trabajas en una prueba a la vez, cosechas aún mayor beneficio, ya que cada prueba solo requiere cambios incrementales al código que sabes que es sólido.

Tu código apesta si es difícil de leer.

El código debería ser fácil de leer. El código debería ser conveniente para leer, no conveniente para escribir, Steve McConnell realizó esta afirmación en su clase magistral en SD West’04.

Varios aspectos están involucrados aquí. Elegir buenos nombres que son auto-explicativos es un buen lugar para empezar. Concéntrate en buscar soluciones simples, incluso si éstas son más prolijas o ineficientes.  No sabremos si la ineficiencia es un problema hasta que realicemos un análisis de rendimiento, luego en el proyecto, en una situación real de producción.

Elige convenciones de formato y estilo lo más pronto posible en el proyecto y apégate a ellas. Exige que todos sigan estas convenciones. Esto será más fácil de realizar si todos participan de las decisiones sobre las convenciones y se apropian de ellas. Esto hará que el código sea uniforme y por lo tanto más fácil de leer.

Y libérate de cualquier y toda duplicación. Más sobre esto después.

Tu código apesta si no es comprensible

Esto está relacionado al punto anterior. El código puede ser fácil de leer, pero no fácil de comprender. Tal vez se lea bien pero es engañoso. Quizás te tomaste el tiempo necesario para elegir un buen nombre para esa variable, pero la forma en la que es usada y lo que significa ha cambiado, pero el nombre no. Eso es peor que usar un nombre en clave… por lo menos en el último caso, el lector conoce el nombre y este es significativo. Si el nombre es engañoso, el lector puede hacer suposiciones infundadas sobre lo que esta pasando en el código, llevando esto a mal entendidos, y eventualmente a errores.

Tu código apesta si dogmáticamente se adapta a un framework de moda al costo de seguir buenas prácticas de diseño/implementación

Por ejemplo, Bob Martin recientemente tocó el tema de usar dogmáticamente atributos privados y getters/setters para una estructura de datos simple (ejm.: un DTO). Si un atributo es de lectura y escritura de forma transparentemente, ¿por que no simplemente convertirlo en un atributo público?. En la mayoría de los lenguajes puedes hacer eso. De acuerdo, en algunos no puedes. Por ejemplo, tradicionalmente en Smalltalk todos los atributos son privados y todos los métodos son públicos.

En general es algo bueno si podemos deshacernos, o evitar escribir, algún código. Usar un framework pesado generalmente requiere que tengas que escribir cierta cantidad significativa de código que no tiene valor para el negocio.

Existe una variedad de frameworks livianos para Java que son una respuesta a los frameworks pesados (por ejm.: EJB) que se han convertido en temas de dogma últimamente. O’Reilly tiene un nuevo libro sobre este tema, escrito por Bruce Tate.

Cuando tomas decisiones sobre frameworks, debes considerar si un framework liviano puede hacer el trabajo requerido. Usar algo como Hibernate, Prevayler, Spring, PicoContainer, NakedObjects, etc. puede realmente ganar en muchas situaciones. Nunca adoptes a ciegas un framework pesado solo por que es el último grito de la moda. Asimismo, no adoptes a ciegas un framework liviano solo por usar alguno. Trata de siempre dar la debida consideración a tus decisiones.

Tu código apesta si tiene duplicación

La duplicación es probablemente lo más importante de eliminar de tu código.

La duplicación puede tener varias formas:

textual

Esta es la más simple y usualmente la más fácil de encontrar. Esto es cuando tienes secciones de código que son idénticas o muy parecidas. Esto usualmente es resultado de programación copy & paste. Se puede usar muchas técnicas para eliminar esta duplicación, por ejemplo: extraer los métodos y reusarlos, convertir un método en un template method, extraerlo a una superclase, y proveer las variaciones en subclases, y otras refactorizaciones básicas. Puedes ver “Refactoring” de Fowler para más detalle al respecto.

funcional

Este es un caso especial de duplicación textual y está presente cuando tiene múltiples funciones/métodos que sirven para el mismo propósito. Esto usualmente se ve en proyectos que se reparten en grupos y que no se comunican lo suficiente. Esto puede ser el resultado de copy&paste, o puede ser el resultado de desconocer librerías o código existente. Políticas y prácticas que  alientan y promueven el conocimiento de todo el código base y todas las librerías y frameworks que se están usando pueden ayudar a evitar la duplicación funcional.

temporal

Esto es un poco extraño, más obscuro, y no muy fácil de encontrar. Tienes duplicación temporal cuando se realiza el mismo trabajo repetidamente cuando no se necesita. Este no es un problema de la misma forma que las dos formas anteriores de duplicación puesto que en esta no se involucra tener código extra. Se puede convertir en un problema en la medida que el sistema crece y el trabajo repetido empieza a tomar mucho tiempo. Varias técnicas se pueden usar para manejar este problema.

De los tres tipos que he identificado antes, la duplicación textual es la peor. Es la que más fácilmente te puede morder en tanto el sistema crece. Tiene el mal hábito de ser viral: cuando ves código duplicado en el sistema, puede tentarte pensar “oh, bueno, no es un problema si tan solo copio este fragmento de código también. Todos los demás lo hacen”. Es como el tema de la ventana rota del que  Dave Thomas & Andy Hunt hablan al respecto. Si  no te mantienes atento a  las pequeñas cosas tan pronto como aparecen, pronto todo se irá al caño.

Conclusión

Entonces, tienes buenas  probabilidades de que tu código apeste.

¿Que vas a hacer al respecto? Bueno, primero tienes que reconocer el hecho (y tengo la esperanza de que este artículo haya ayudado con eso) y admitir que existe un problema.

Luego, tienes una opción. Puedes elegir hacer algo al respecto. Puedes aprender nuevas formas de trabajar…métodos que te ayuden a escribir mejor código. Esto es grandioso. Si solo un programador hace esto, estaré feliz.

Tu otra opción es no hacer nada al respecto, y continuar escribiendo el código de la misma manera que siempre lo has hecho.

Es tu elección. Elige sabiamente.


 
About these ads

Responses

  1. Para pensar sobre el punto 1:
    “I perform an occasional unit test after I’ve encountered a failure that I don’t want to have recur, but I rarely write the tests first. If so many experienced developers don’t write unit tests, what does that say?”

    Cay Horstmann
    Professor of Computer Science, San Jose State University

    http://java.sun.com/developer/technicalArticles/Interviews/community/horstmann_qa.html

    Que opinas?


Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Categorías

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

A %d blogueros les gusta esto: