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.

Concretamente, puedes dotar una clase de la habilidad de obtener o transformar (o obtener y transformar) datos, o puedes dotarla de la habilidad de aplicar esos datos en el nivel más superior del proyecto. Ejemplificando: Puedes hacer una clase que se encargue de obtener datos de una base de datos, pero se debería programar otra clase con la intención de mostrar esos datos en pantalla. He visto códigos donde las clases tienen métodos para obtener y tratar información, y métodos distintos para aplicarla. Tampoco es una mala opción. Quizás un poco incómoda, pero también funcional.

Pero lo que no debe suceder nunca, es que un único método se encargue de obtener la información y de aplicarla. Podría pensarse que es más cómodo, y ciertamente lo es, siempre que nunca en la vida, jamás de los jamases, vayas a usar esa clase en otro proyecto, o tengamos la seguridad de que ese proyecto no va a sufrir ninguna modificación. Por supuesto, esa situación no existe. El cliente nunca se va a conformar con la primera versión acabada del proyecto (nunca), y tu jefe siempre te sugerirá (quizás con una mirada amenazadora) que reutilices el código de un proyecto anterior.

Resumiendo: una clase bien hecha debe cumplir ciertos puntos:

• Debe ser fácil de ampliar.
• Debe ser traspasable a otras aplicaciones de forma íntegra.
• Debe poder ser pasada a un colega, publicada a la comunidad, etc.

Salgo hoy con estas historias, porque después de una semana en modo hardcore developer he conseguido acabar (bueno, prácticamente acabar) el nuevo y espectacular diseño del blog (espero que os guste, seáis quienes seáis los que pasáis por aquí xD). Y entre las funciones de wordpress hay cada cosa… Las funciones devuelven código HTML listo para publicar en el mejor de los casos, de hecho, lo más normal es que directamente impriman la información en la página. Un desastre.

Por ejemplo, si llamas a la función que te permite obtener el listado de categorías, en vez de devolver los datos íntegros, o en su defecto el html ya montado; simplemente imprime el código en pantalla sin dar opción al programador de tratar los datos antes de publicarlos. Vamos, no tiene pies ni cabeza.

La intención no es mala, porque simplifica mucho el trabajo para diseñadores con pocos conocimientos de programación, pero el problema real es que no existe la posibilidad de obtener los datos íntegros antes de mostrarlos en pantalla.

Después de algunos meses con este blog, estoy viendo que wordpress es una maravilla, pero en este aspecto hay que suspenderlos y darles una colleja, para que se espabilen en nuevas versiones.