Principio KISS - Keep It Simple, Stupid

Principio KISS

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.

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.

Recuerda: Mantenlo simple.

Únete a mi lista de correo.
Te avisaré de nuevo material que te ayude a ser un mejor desarrollador o arquitecto.

Educador, desarrollador y arquitecto de software. Ha enseñado distintas tecnologías a profesionales en varias partes del mundo. Ingeniero y geek apasionado por el trabajo remoto.

Tips para estimar mejor tus proyectos de desarrollo

La estimación es quizá una de las áreas más difíciles en la ingeniería de software. Cambios en los requerimientos, falta de conocimiento de las tecnologías a utilizar, y expectativas fijadas por las necesidades del negocio, hacen que dar tiempos para un proyecto a veces parezca un acto de magia en vez de una labor de ingenieria. Continue reading “Tips para estimar mejor tus proyectos de desarrollo”

Educador, desarrollador y arquitecto de software. Ha enseñado distintas tecnologías a profesionales en varias partes del mundo. Ingeniero y geek apasionado por el trabajo remoto.

3 buenos hábitos que todo programador debería tener

En este vídeo, vamos a hablar de tres buenos hábitos que todo programador debería tener. Debajo del video te dejo su respectiva transcripción.

Link al vídeo de YouTube | Suscríbete a mi canal

1. Bajar cambios del repositorio al comienzo del día

El primer buen hábito es que cada vez que empieza el día, obtengas los últimos cambios del repositorio. Puede que durante la noche alguno de tus compañeros haya subido cambios adicionales.

Lo que puede ocurrir cuando no obtienes la última versión de código, es que puedes estar trabajando con una versión desactualizada y, en el momento en que quieras subir los cambios, o quieras hacer un merge de lo que hay en el repositorio, te puedan salir muchos conflictos. Sobre todo si múltiples programadores están trabajando en módulos comunes.

2. Subir todos los cambios al final de día

El hábito número dos, es que todos los días hagas commit o check-in de tu código.

La principal razón es que algo te pueda pasar. Podría ser que te enfermes, o tengas algún otro inconveniente que que te impida ir a trabajar.

Y el hecho de que el código se haya quedado en tu máquina, puede llevar a que otros miembros del equipo de desarrollo se bloqueen, sencillamente, porque tu código no está ahí.

3. Ejecutar pruebas unitarias antes de subir cambios

La tercera recomendación es que, siempre antes de subir el código, ejecutes las pruebas unitarias.

Si trabajas en un equipo de desarrollo relativamente maduro, va a haber un servidor de integración continua. Este puede llegar a fallar, o el build puede romperse si subes cambios que no han sido verificados por las pruebas unitarias.

Obviamente por temas de tiempo y de afán, puede que quieras subir los cambios lo antes posible, pero dedícale unos minutos a las pruebas unitarias. De verdad que vale mucho la pena.

Un pequeño paréntesis, que podría ser el cuarto buen hábito:

Si no tienes pruebas unitarias, empieza a desarrollarlas.

Cierre

Si quieres conocer otras buenas prácticas, te invito a que conozcas los principios de diseño. Vas a aprender mucho acerca de cómo estructurar mejor tu código.

Tenemos un curso totalmente gratuito, por correo electrónico, donde te puedes suscribir.

Espero que te haya gustado.

Únete a mi lista de correo.
Te avisaré de nuevo material que te ayude a ser un mejor desarrollador o arquitecto.

Educador, desarrollador y arquitecto de software. Ha enseñado distintas tecnologías a profesionales en varias partes del mundo. Ingeniero y geek apasionado por el trabajo remoto.