Juanma Santoyo

En ocasiones me llaman friki

Olor de código

| No hay comentarios

Los programadores solemos cometer dos errores:

El primero, pensar que con echar un simple vistazo a un código podemos determinar si es o no es un buen código.

El segundo, pensar que lo anterior es un error.

En realidad, la primera impresión de un código es bastante válida. Cuando un código no nos convence a primera vista, es por que despide un “olor” poco convincente. Lo que vengo a decir, es que esto del olor de código existe y está mas o menos documentado. Sin embargo, no he encontrado nada en español sobre el tema, así que vamos allá:

¿Qué cosas provocan mal olor en nuestro código y como solucionarlas?

  • Código duplicado. A primera vista ya podemos ver trozos de código demasiado parecidos. Probablemente deberíamos encontrar una forma de compartir ese código para no repetirlo por todo nuestro programa.
  • Métodos demasiado largos. Cuando un método es demasiado largo, lo más seguro es que debamos dividirlo en más métodos más básicos. Eso hará nuestro código más comprensible y más sencillo de arreglar cuando falle (porque creeme, fallará).
  • Clases demasiado largas. Un poco en la misma linea que lo anterior, es posible que necesites abstraer un poco más tu código, y dividir una clase en varias clases pequeñas.
  • Envidia de características. Lo mismo te digo una cosa que te digo otra. Si notamos que una de nuestras clases usa excesívamente los métodos de otra, merece la pena cosiderar si realmente esas dos clases deberían estar separadas.
  • Intimidad inapropiada. Una clase no debería depender de otras clases en según que aspectos de implementación críticos. Las clases deberían ser reutilizables y independientes. En estas situaciones tambien deberíamos plantearnos la fusión de las dos clases.
  • Rechazo del legado. Una clase que sobreescribe un método heredado debería respetar el propósito inicial del método. Con esto quiero decir que no es lógico ni aceptable que un método que calcule raízes cuadradas se sobreescriba con un método que elimine acentos en una cadena de texto. No tienen nada que ver el uno con el otro. La pregunta que deberíamos hacernos ahora es: ¿realmente esta clase debería tener este padre y no otro?. Recordemos que la composición siempre es una solución válida.
  • Clases perezosas. Hemos hablado de clases demasiado largas, pero ¿y las clases demasiado cortas?. Puede que debamos integrar su funcionalidad en otra clase.
  • Métodos duplicados. ¿Realmente necesitamos ese método para elevar al cubo teniendo este que eleva al cuadrado?. Mucho mejor si hacemos un método capaz de elevar a n. Debemos evitar tener varios métodos con funcionalidades parecidas y buscar más métodos configurables con parámetros.
  • Complejidad artificial. ¿Estamos ante un problema complicado o nosotros lo hemos vuelto complicado?. No tiene sentido forzar, por ejemplo, el uso de complejos patrones de diseño en problemas que realmente son tan sencillos que no los requieren.

Estas son algunas fuentes potenciales de problemas que podemos llegar a tener y que son fáciles de ver con un vistazo simple al código. El código puede, y debe; ser bonito.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

Deja un comentario

Los campos obligatorios están marcados con *.