CEO de Ketoque en desarrollo virtual

¿Qué es código de baja calidad? Sin ningún orden en particular:

_Difícil de entender

_Alta complejidad

_Usar malas prácticas dentro del dominio del lenguaje de programación

_Comentarios innecesarios

_Inseguro

_Carente de tests de unidad

_Ausencia de revisión por pares

¿Cómo evitarlo?

Haciéndolo fácil de entender: la idea es reducir la carga cognitiva, la cantidad de cosas que hay que memorizar para entender el código. Por ejemplo, una buena práctica es usar nombres de variables o funciones explícitos como "generar_nombre_aleatorio()" en vez de "gna()" o "gen_nom_aleat()". Cuando veamos esa función más adelante, estará claro de qué trata, en vez de tratar de recordar qué rábanos era "gna"

Buscar que el algoritmo tenga una complejidad baja: en este caso me refiero a la notación O mayúscula (Big O notation). Un algoritmo O(n2)

se vuelve rápidamente inmanejable cuando los datos de entrada aumentan. Si se puede reemplazar por un algoritmo menos complejo como O(nlogn)

Usar buenas prácticas dentro del dominio del lenguaje de programación: esto depende del lenguaje. Por ejemplo, C permite solicitar zonas de memoria, pero este no controla que se estén accediendo más allá de los límites. Otro ejemplo: Python no tiene múltiples threads en paralelo. Lo que tiene es un proceso simple donde los threads trabajan en concurrencia. Si el computador tiene 8 procesadores y se crean 8 hilos, los 8 van a correr en un procesador solamente, dejando 7 sin utilizar. En Java, se pueden atajar las excepciones cuando ocurren, pero si no se las deja subir sin una buena razón, un problema puede quedar latente y sin ser descubierto hasta que sea demasiado tarde. Para cada lenguaje y situación, hay algo específico por hacer.

Inseguro: no tiene prácticas mínimas de seguridad, como por ejemplo:

llave_cifrado = "G73PkmQX"

Esta llave estaría guardada con el código fuente. Otro ejemplo:

sql_query = "select * from clientes where nombre=" + nombre_cliente

En este caso, el código está expuesto a inyección de SQL.

Escribir buenos tests de unidad: esta parte tiene un poco de debate. Tanto la ausencia como el exceso de tests de unidad solo perjudican a los programadores. La ausencia quita seguridad de saber que no estamos rompiendo el programa con efectos colaterales. El exceso hace que tengamos que hacer doble trabajo para mantener el código y los tests constantemente. Buenos tests verifican que el programa no rompa sus contratos.

Revisar por pares: la revisión de código por otros desarrolladores de tu mismo equipo evita que se te pase algo inadvertido. Si conocen el proyecto en el que estás trabajando, pueden hacer indicaciones que ayuden a mejorar la calidad del mismo. Si no lo conocen, aún así podrían ver algún problema o mala práctica.