Qué es el Código Limpio?

Antes de que arranquemos a hablar del Código Limpio, quiero que hagamos un pequeño ejercicio.


Si te presento el siguiente código puedes determinar de que se trata sin necesidad de ver mas nada?

public ArquillianCucumber(final Class<?> klass) throws InitializationError {
   super(klass);
}

Aquellos que conocen Java pueden inferir que estamos viendo un método constructor (es un metodo publico sin especificar tipo de retorno), igualmente sabemos que es posible que este método retorne una excepción de tipo InitializationError y que el constructor utiliza el método constructor heredado por su padre para hacer una tarea.

Adicionalmente, si conoces suficiente sobre BDD y Testing con Java Enterprise Edition pudieses adivinar que forma parte del proyecto CukeSpace, que busca mezclar los proyectos de Cucumber con Arquillian.

Si nos damos cuenta pudimos entender mucho de la formación técnica del código sin entender su intención o el propósito de su ejecución.

Veamos que dudas quedaron en el aire:

  • Qué hace la clase ArquillianCucumber?
  • Que hace el argumento “klass“?
  • Es importante que su tipo sea parametrizado de forma indeterminada? (esto lo hace la aplicación del símbolo “?” en tipos genéricos)

Quizas si exploramos en la herencia y ubicamos al padre de ArquillianCucumber esto se aclare; veamos ahora el código del constructor padre que esta clase esta invocando.

public Arquillian(Class<?> klass) throws InitializationError {
super(klass)
}

Pues no ayuda mucho!

Seguimos prácticamente con las mismas incógnitas, solamente que ahora sabemos que ArquillianCucumber es hijo de Arquillian, pero aun no sabemos mucho de su propósito. Dicho esto, podemos empezar a sospechar un patrón (muy común en la programación moderna):

  • La intención del código heredado es propensa a perderse en el camino.

Veamos al constructor padre de Arquillian a ver si podemos por fin descifrar este misterio.

public BlockJUnit4ClassRunner(Class<?> testClass) throws InitializationError {
   super(testClass);
}

Pues aquí tenemos un progreso significativo, vamos a repasar un poco lo que hemos descubierto

  • Las clases son Runners, es decir se encargan de la ejecución de código
  • Particularmente se encargan de la ejecución de clases completas
  • Funcionan con el framework JUnit en su version 4
  • Podemos inferir que el parámetro que reciben, llamado “testClass“, es la clase de prueba que se va a ejecutar.
  • Y por ultimo al saber que el parámetro es una clase de prueba sabemos que puede ser de cualquier tipo, por lo tanto debe utilizar el comodín “?” en el tipo Class.

Ahora mi pregunta es: cual es la diferencia entre estos tres bloques de código?

La respuesta es evidente, uno nos revela su intención y propósito de forma clara, a través de los nombres que define, mientras que los otros no.

Es tanto así, que no tuvimos necesidad de seguir subiendo en clases padres para entender por completo el constructor; confiamos en la descripción que obtuvimos, y esta es una señal clara que acabamos de ver Código Limpio.

NOTA: El código de estos métodos se extrajo de sus respectivos repositorios Github.

Código Limpio y Programación Limpia

Quizás puedas decirme que es injusto juzgar el propósito de una clase a partir de uno de sus métodos, las clases deben juzgarse en un todo y debemos hacer estudio e interpretación de todo lo que tenemos para determinar el propósito.

Déjame responderte a esto con una sola frase: Patrañas.

Todo código debe revelar de forma clara su intención, y si el método constructor es en el que nos basamos para construir la clase, entonces el mismo debe revelar la intención de la clase, si no de manera especifica, debe darnos ideas a groso modo que luego podemos explorar a detalle. De esta forma, debemos tomar en consideración que nuestro código esta hecho no solo para ser ejecutado sino también para ser leído e interpretado, y cada método/procedimiento/función sirve un propósito que varia según el tipo de orientación pero que igual debe expresarse de forma clara.

De esta forma cuando un código, sin importar el lenguaje en el que se escriba o la orientación que reciba (objeto, procedimental o funcional), expresa claramente sus propósito e intenciones recibe el nombre de Código Limpio, y a la practica de desarrollar el mismo se le conoce como Programación Limpia.

Si queremos entender el movimiento del Código Limpio, hace falta conocer un poco a su fundador Robert C. Martin, alias el Tío Bob.

El Tío Bob

Robert C. Martin

Robert C. Martin

El Tío Bob es una leyenda dentro del mundo de la informática, no solo por sus amplios conocimientos técnicos, aunque no esta de mas decir que en mas de 40 años de carrera ha utilizado TODO lo que se puede utilizar para programar, sino por ser también uno de los fundadores del movimiento ágil (es uno de los autores del Manifiesto Ágil), baluarte del profesionalismo en el mundo de la Ingeniería del Software, y defensor de la optimización del trabajo de equipos de desarrollo.

Durante los años ha utilizado su capacidad de explicar practicas y conocimientos técnicos de alto nivel a profesionales como manera de impulsar el profesionalismo de nuestra carrera; es conocido como el autor de algunos de los libros mas valorados en nuestra área y por dar extensas charlas sobre lo que el considera las practicas profesionales que debe seguir un ingeniero de software (una búsqueda rápida en Youtube nos muestra algunas de las mas interesantes).

Dicho todo esto, se puede decir que su trabajo mas famoso es su libro “Código Limpio: Manual de Estilo para el Desarrollo Ágil de Software“.

En este libro, de forma bastante precisa y autoritaria, el Tío Bob describe cual debe ser el comportamiento de un profesional ágil de la Ingeniería de Software y nos plantea lo que para mi ha sido una revelación profesional cuando dice (y parafraseo):

  • Cualquiera que sea capaz de escribir programas en un lenguaje de programación es un “programador“; la diferencia entre un “programador” y un “ingeniero de software” radica en las practicas, la estandarización y el cuidado que damos a nuestro trabajo, no solo para nuestro consumo sino el de los demás. Es decir, la principal diferencia radica en el PROFESIONALISMO.

De esta manera el Tío Bob nos da a entender que no es solo la capacidad técnica lo que guía a un profesional de la ingeniería del software, sino el desarrollo apropiado de software a través de medidas muy puntuales que impulsan el desarrollo ÁGIL de software. Igualmente, nos explica cuales son los elementos necesarios para reconocer el trabajo de un Profesional (con P mayúscula) de la industria del software.

Qué factores determinan al Código Limpio?

Según el Tío Bob, hay 3 factores esenciales para el Código Limpio

  1. Legibilidad de la Fuente, o capacidad del código de explicar su propósito sin necesidad de recurrir a nada mas que el código.
  2. Organización de Elementos, es decir, la estructuración correcta de los elementos de un sistema donde uno espera que estén.
  3. Certeza de Funcionamiento, que se obtiene a través de la implementación de diferentes pruebas que verifiquen nuestros sistemas. El Tío Bob lo lleva un paso mas allá asegurando que “los verdaderos ingenieros de software prueban su código y la mejor manera de garantizar esto es implementando TDD“.

Ahora bien, cual de estos tres puntos podemos considerar como el mas importante?

Factor Principal: Lectura

Nuestro código esta hecho para ser leído.

Es una declaración muy importante y poco valorada ya que como técnocratas que somos, consideramos que el propósito de un código fuente no es ser leído, sino ejecutado por una maquina; aun así puedo asegurarte que eso no es del todo cierto.

Sin duda alguna, el código debe funcionar correctamente; un código sin funcionalidad es inútil, pero en el mundo del desarrollo profesional también debemos considerar de forma consciente la Legibilidad del Código.

Te preguntaras el por qué? pues si lo pensamos de forma técnica, el código fuente nunca es ejecutado, es el código interpretado por un compilador el que se ejecuta. De esta manera no es lo que escribimos sino su interpretación en lenguaje de maquina lo que va al hardware (si programas en Assembly esto no aplica)

Si no me crees, te pido que me digas cual es la diferencia entre los siguientes métodos:

public void recorridofor(int c) { for(int i=0;i<c;++i){System.out.println(arr[i]);} }

public void recorridoDeConfiguracion(int cantidadDeElementos)
{
   for(int indiceElemento=0; indiceElemento<cantidadDeElementos; ++indiceElemento)
   {
      System.out.println(elementosDeConfiguracion[indiceElemento]);
   }
}

A nivel de ejecución(código compilado) son prácticamente idénticos, su velocidad técnicamente es la misma, no hay mayor diferencia al ejecutarse. Es decir, a nivel técnico son iguales, pero cuando nos vamos al nivel humano, aquel en el que se requiere una comprensión un poco mas abstracta de que hace el código, pues es obvio a la vista que el primer método cuesta entenderse, hay una mezcla entre declaraciones, símbolos especiales, palabras claves, etc; mientras que en el segundo método no solo hemos nombrado correctamente los elementos involucrados de manera que revelamos su intención sino que hemos ordenado vertical y horizontalmente el código permitiendo seguir la secuencia de lo que se esta haciendo y entender de manera mas sencilla el propósito del código.

Pregúntate cual de los dos métodos nos da un mayor aire de profesionalismo? cual parece haber sido hecho “de golpe” y sin consideración? cual denota un análisis, así sea momentáneo, por parte de su autor? Las respuestas saltan a la vista.

Una vez hayamos analizado esto, nos damos cuenta que el código fuente profesional no esta pensado exclusivamente para el consumo de la maquina, sino que también se desarrolla pensando en como lo va a utilizar el resto del equipo de desarrollo (rara vez un profesional trabaja solo) o nosotros mismos en un futuro.

Te invito a hacer la siguiente reflexión

  • Cuando estas desarrollando una función nueva, cuantas veces vuelves a leer las funciones que invoca o las estructuras que utiliza? cuantas veces chequeas las variables que utiliza? cuantas veces haces lectura de tu código una vez esta listo? o lo lees conforme lo vas escribiendo?

Ahora que lo dijimos en voz alta y lo consideramos parece obvio, pero normalmente no lo damos por hecho. Es por esto que creo que no exagero cuando digo que leemos mas de lo que escribimos al desarrollar software.


Por ahora dejaremos hasta aquí nuestro estudio del Código Limpio, pero este es un tema que me apasiona mucho y el cual exploraremos en mayor detalle a futuro. Por ahora puedo adelantarte que cuando retomemos el tema de la Programación Limpia, hablaremos de las buenas practicas de lectura y como crear código auto-comentado. Como siempre, espero que este post haya sido de tu agrado.

Hasta la próxima.

Anuncios
Esta entrada fue publicada en Blogging y etiquetada , , , . Guarda el enlace permanente.

Responder

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