Manuel Zapata
Uno de los principios más recomendados a la hora de diseñar y desarrollar software es el principio KISS. Por esta razón, grabé un vídeo sobre el tema en la serie Programador Senior de mi canal de YouTube.
Si prefieres leer, debajo del video te dejo su respectiva transcripción.
Link al vídeo de YouTube | Suscríbete a mi canal
Cuando hablamos de KISS, no nos referimos a la banda de rock:
Estamos hablando de un principio que significa: Keep It Simple, Stupid. O en otras palabras: Mantenlo simple, estúpido. La palabra estúpido sobra pero así se definió el principio.
La idea principal de este es que cuando se tiene un sistema, normalmente este funciona mucho mejor si se diseña y desarrolla de manera simple.
Bueno, tú me estarás diciendo: “Obvio, ¿quién quiere escribir código que sea complejo y difícil de entender?”
En la práctica, ocurre mucho ese tipo de situaciones, donde se termina escribiendo cosas que a la final solo uno entiende. O peor aún, que en unos años cuando se revisa el código que se escribió antes, ya ni siquiera uno mismo lo entiende.
En esto, Martin Fowler tiene una frase muy interesante:
“Cualquiera puede escribir código que una máquina pueda entender. Pero solamente un buen programador es capaz de escribir código que otras personas también entiendan”
A continuación, te voy a contar algunos tips para que puedas cumplir con este principio y tu código sea mucho más simple y fácil de entender.
Mantén los métodos y las clases pequeños
El primer tip que tengo para darte es que mantengas las clases y los métodos pequeños. Entre más líneas de código tengan, es más probable que sea complejo y difícil de entender.
Imagínate una clase que tenga 5,000 lineas de código. Imagínate cuántos métodos puede haber ahí y qué tanta funcionalidad contienen. Seguramente no es una clase que sea muy fácil de entender.
La idea aquí es que los trates de mantener de un tamaño pequeño, de un número de líneas de código razonable para que se mantenga esa simplicidad.
Usa nombres claros para las variables
El segundo tip es que tengas cuidado con los nombres de las variables.
Nombrar las variables como a1, b2, miVariable, miNumeroEntero, realmente no ayudan en nada porque no te están diciendo absolutamente nada de lo que están haciendo.
La idea es que esas variables tengan nombres significativos que representen algo para el algoritmo que estás desarrollando.
No reutilices variables
La tercer recomendación es que no reutilices variables.
Supón que tienes un método en donde hay un ancho y un alto, ambos son números de tipo Double y creas una variable que se llama “a”. Primero la utilizas para el ancho y más abajo la reutilizas para el alto.
Lo que está ocurriendo es que estás tomando una variable y le estás dando dos significados diferentes. Para quién lea ese código, le va ser difícil comprenderlo, porque dependiendo del momento en que esté revisando el algoritmo, así mismo la variable va a significar una cosa u otra.
La recomendación aquí es simple; crea dos variables, una para el ancho y otra para el alto. Suena muy obvio pero no siempre se hace.
La única excepción a esta regla es cuando las variables las estés creando dentro de una estructura repetitiva como un while o un for, donde tiene más sentido esta idea de reutilizar variables.
Cuando yo daba clases en una universidad, le decía a mis estudiantes que no fueran tacaños con las variables. Algunos trataban de escribir código muy corto. Se ahorraban variables. Las reutilizaban varias veces y esto realmente no ayuda a que el código sea legible.
Es mejor gastarse unas variables de más, para que los pasos del algoritmo o de la función sean más claros. Esto evita que otra persona tenga que entrar a descifrar qué es lo que hace ese bloque de código.
Divide el problema en partes más pequeñas
La cuarta recomendación es que dividas el problema que estás resolviendo, en partes pequeñas. Adicional a eso, analiza el problema antes de entrar a resolverlo.
Si tienes que hacer algo, entras directamente a programar, e intentas resolver todo en la misma función o método. Lo que va a ocurrir es que estarás intentando resolver el problema mientras programas al mismo tiempo. Esto puede llevar a que termines haciendo una “enchilada” en el código.
Es decir, terminas mezclando cosas, cambiando, ajustando, y por ensayo y error vas a intentar llegar a la solución.
La recomendación es que te detengas a hacer el análisis. Si es un problema grande, intenta resolver problemas más chiquitos dentro de ese problema grande y de ahí salta a programar e implementar esa solución en cada una de las partes que encontraste.
No abuses de los comentarios
La quinta recomendación es que no abuses de los comentarios.
Si te das cuenta que tienes que documentar demasiado el código, para que alguien más pueda entender lo que está haciendo, significa que a lo mejor el código está muy complejo o es muy difícil de entender.
Analízalo. Si tienes que poner comentarios de 5 a 10 líneas, solo para explicar un par de líneas de código, significa que hiciste algo muy complejo o se te ocurrió una forma de resolverlo que a lo mejor no es la más práctica. Eso puede estar causando dificultad para entender el código.
Si te ves documentando demasiado, a lo mejor lo que estás haciendo se puede simplificar. Lo podrías reescribir de otra manera. De pronto es un problema de variables. Es posible que las variables se deban nombrar diferente para que el significado del programa sea mucho más claro.
Aquí lo que se busca en general es que el código que uno escriba, cuando alguien más lo revise, sea como estar leyendo el algoritmo en una hoja de papel.
Lo importante es que sea relativamente fácil ir siguiendo el flujo del código e ir entiendo lo que está haciendo. Esa es la idea que se está tratando de resaltar aquí.
Evita el código duplicado
La sexta recomendación es que evites el código duplicado.
Respecto a esto tengo un vídeo, donde hablo lo que significa copiar y pegar código.:
El código duplicado tampoco ayuda a la simplicidad, porque hay muchas partes en donde tienes que empezar a modificar la aplicación si ese bloque de código duplicado tiene que ser modificado.
Aplica los principios SOLID
Y mi séptima y última recomendación es que apliques los principios de diseño SOLID.
Los principios de diseño son muy buenas ideas para simplificar el código y organizarlo.
Este principio y muchos otros más, te ayudarán a formarte para ser un programador senior.
En caso de que no estés enterado, tengo un minicurso gratuito de principios de diseño:
Te invito a que te inscribas. Es totalmente gratis y vas a poder aprender cómo aplicar esos principios.
Eso era lo que tenía para comentarte.
