Testing Colombia

Testing con calidad

Metodologias

Principios del code clean (Codigo Limpio) Cometarios, Parte 1

Los principios del código limpio son sin duda alguna un tema muy importante para el desarrollo de software e incluso para el testing de software, debido a que en estas dos actividades sea al escribir nuevo código o al leer codigo existente para generar nuevas funcionalidades salen a relucir problemas tales como:

  • Códigos muy complejos de entender
  • No sigue ningún patrón de diseño.
  • Esta excesivamente documentado y también escaso de documentación.
  • Código repetitivo.
  • Excepciones del código poco claras.

 

tomado de: A Handbook of Agile Software Craftsmanship (Robert C. Martin)

Tomado de: A Handbook of Agile Software Craftsmanship (Robert C. Martin)

Empezaré por nombrar algunos de los principios más sencillos de poner en práctica y más fáciles de empezar a implementar en nuestro código.

Los Comentarios en el código:

Los comentarios dentro del código son un tema que se podría pensar que no implica alguna gravedad, dado que estamos acostumbrados a pensar que los comentarios no son importantes si el código funciona bien. Lamentablemente esto no sucede así, podemos analizar problemas a raíz de malas prácticas en los comentarios como tener muchas líneas en nuestras clases las cuales no hacen nada y tampoco dicen nada. Siempre que se vaya a hacer uso de comentarios en el codigo se podria tratar de evaluar la necesidad, como sucede en estos casos:

 

 

 

 

  • Aspectos legales del código: imaginemos que tenemos un código donde se usa un parámetro que representa un valor definido por el gobierno como podría ser el índice del IVA (impuesto sobre el valor añadido), en este caso sería útil documentar con un comentario lo que significa este parámetro y sus implicaciones.
  • Advertir de consecuencias: muchas veces entender lo que hace un código no significa entender sus consecuencias, como por ejemplo un código que haga uso de un algoritmo de encripción que solo deberá  funcionar sobre ciertas caracteristicas, esto orientara a quien vaya a mantener dicho codigo, deberá tener en mente dicha advertencia y hacerla parte de sus test unitarios.

 

  • Resaltar la importancia de algo: esto será necesario cuando en nuestro codigo se determine que son partes “Delicadas” de código que hace necesario  el uso de comentarios muy explícitos que pongan en contexto alguna situación, como por ejemplo clases que poseen una alta sensibilidad a los cambios debido a que son core de la lógica del software.
  • Comentarios TODO (cambios por hacer):  este caso se presenta cuando el desarrollador encuentra en el codigo cosas que se deberían mejorar o cambiar, pero simplemente funciona como un recordatorio, lo cual se debería tratar de evitar al máximo, buscando tener siempre codigo de calidad.
  • El uso excesivo de comentarios en el código puede significar una mala capacidad de representar a través del buen codigo su logica, tambien puede  ser posible que los nombres de clases, métodos, funciones, variables, constantes, etc, no están dando la claridad suficiente a quien va a leer el código en el futuro, en este sentido es importante definir en el equipo de trabajo, algunas reglas de cómo se debería escribir este tipo de sentencias:
    Supongamos que tenemos el siguiente requerimiento:
    se requiere una función que pida la lista de personas mayores a 18 años y la muestre en pantalla. Para la función que se implementara se podría usar alguno de estos dos nombres:

    • RPersM18show(){}
    • ShowListOfPeopleGreaterThan18Years(){}

    En el primer caso a simple vista es más difícil entender cuál es el objetivo de la función, mientras que en la segunda opción da más información claridad e información acerca de la función, lo que evita tener que usar comentarios en el código.

    Algunas malas practicas:

    • Escribir comentarios incluyendo fragmentos de código para intentar explicarlo
    • Mantener comentarios en el código que es autogenerado.
    • Redactar comentarios que usen más de dos líneas, quiere decir que el código  no es muy claro.
    • Adornar el código con símbolos para llamar atención de algo en particular en el comentario, ejemplo:
      • //***********************************************************************
      • //**************************** Este es MI comentario *********************
      • //*************************** PAtAge = es la edad del paciente*************
      • //***********************************************************************
    • Mantener codigo comentado, no se deberia tener codigo escrito que no es usado.
    • Escribir comentarios en diferentes idiomas, se debería elegir el idioma más común para el equipo de trabajo y también pensando a futuro quien lo pueda tener que leer.
    • Volver el código el historial de comentarios de cada cambio que se hace con autores y fechas, para esto ya existen las herramientas de versionamiento del código.

    Como conclusión final, la mejor práctica es escribir la menor cantidad de comentarios posible y para estar seguro de que el código que escribimos es claro, nada mejor que una revisión de pares para que nos diga otra persona si lo que queríamos hacer y decir a través del código es claro y entendible.

Si tienes mas información para añadir a esta entrada no dudes en comentar.

 

 

Deja un comentario

Tema creado por Anders Norén