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.

Algo de microservicios, DDD e inteligencia artificial

Debo confesarlo.

Desde hacia varios años, no asistía a una conferencia tecnológica grande. Había olvidado la energía tan bacana que se siente al estar rodeado de tantas personas apasionadas por la tecnología. Continue reading “Algo de microservicios, DDD e inteligencia artificial”

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.

motivar equipo de desarrollo

Cómo motivar a tu equipo de desarrollo

Uno de los retos que enfrentan los líderes de equipos de desarrolladores, es lograr mantenerlos motivados. Situaciones como la ejecución de tareas repetitivas y la falta de aprender algo nuevo, hacen que las personas se desmotiven. Y eventualmente, llevan a que busquen otras alternativas laborales.

En el siguiente vídeo, vamos a hablar de cómo mantener motivado a un equipo de desarrollo. Debajo del vídeo te dejo la transcripción.

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

Vamos a hablar de cuatro recomendaciones, muy puntuales, que van a ayudar a que tu equipo se mantenga motivado. Son motivaciones que van mucho más allá del dinero.

Entonces, vamos con la primera:

1. Hazles sentir que su trabajo es importante

Hazle sentir a tu equipo de trabajo que lo que está haciendo es importante. Es decir, muéstrales cómo lo que tiene que desarrollar, está mejorando la vida de los clientes y los usuarios.

En general muéstrales que su trabajo va mucho más allá de tomar un requerimiento, convertirlo en código y entregarlo. Enséñales porqué lo que están haciendo es importante.

Muéstrale a tu equipo de desarrollo, que su trabajo va más allá de tomar un requerimiento y convertirlo en código. Enséñale porqué lo que están haciendo es importante. Click To Tweet

Es muy valioso para las personas, poder sentir que no solamente están ahí para producir código. Sino que están ahí porque aportan algo significativo.

2. Dales oportunidades de que sigan aprendiendo

No hay nada más frustrante para un desarrollador, que sentir que está totalmente estancado en su trabajo a nivel de conocimiento. Que lleva años y años trabajando en las mismas tecnologías y lenguajes. De alguna forma sienten un estancamiento profesional.

Entonces dales oportunidades para que sigan aprendiendo.

Compra suscripciones a cursos en línea. Deja que ellos en sus ratos libres, incluso en el tiempo laboral, puedan entrar y revisar esos contenidos.

Deja que hagan parte de la comunidad. Que puedan asistir a charlas, a meetups, a eventos donde ellos puedan crecer su conocimiento.

En general, busca maneras de que sigan aprendiendo y no se queden estancados.

3. Escucha sus propuestas

La tercer recomendación para mantener motivado a tu equipo, es que escuches sus propuestas. Pero de verdad escúchalas.

En algunas empresas, el equipo de desarrollo trabaja muy de la mano con el cliente. A veces incluso más cerca del cliente que lo que un gerente o una persona de ventas lo pueda estar.

Los desarrolladores escuchan constantemente las necesidades del cliente y por ende, son una muy buena fuente de ideas para mejorar el producto. Entonces si algún día tu equipo de desarrollo te propone alguna nueva idea de cómo monetizar un producto o crear algún nuevo servicio, escúchalos.

Escúchalos porque probablemente viene de un lugar de mucho conocimiento del cliente. No quiere decir que todas sus ideas vayan a funcionar. Pero el solo hecho de que los escuches de manera sincera, va significar muchísimo para ellos.

4. Dales libertad a la hora de implementar

Y mi cuarto y último consejo, para que tengas un equipo de desarrollo motivado, es que les des libertad a la hora de implementar.

Si existe un arquitecto dentro del equipo, deja que defina los estándares, las buenas prácticas y las tecnologías. A partir de esas estructuras, deja que tu equipo de desarrollo trabaje.

Es muy frustrante cuando en ciertos equipos, existen jefes que vigilan el trabajo de las personas casi que al detalle de métodos y lineas de código. Todo lo están cuestionando.

Esto es una práctica que desmoraliza mucho a los equipos de desarrollo.

La recomendación es que le des la confianza para que ellos trabajen. Luego establece los mecanismos para verificar el trabajo que tu equipo hace.

Existen herramientas que te verifican:

  • Las buenas prácticas en el código.
  • El cumplimiento de los estándares.

Implementa esas herramientas y dale confianza a tu equipo.

No te vuelvas, lo que llaman en otros contextos, un micromanager. Es una persona que supervisa demasiado a las demás.

Cierre

Estos son algunos tips que te van a ayudar a mantener un equipo de desarrollo motivado.

Si observas, nunca hemos hablado de dinero, bonificaciones o salario. Obviamente esa parte es importante. Si sobre eso no hay un consenso, va a ser difícil que tengas un equipo que te dure mucho tiempo.

Pero una vez tienes un equipo trabajando, existen muchas cosas (alguno esos ejemplos los acabamos de ver), que van a ayudarte a que tu equipo esté bien, esté contento, esté enfocado en el trabajo.

Cuéntame, ¿se te ocurre alguna otra idea para motivar a un equipo 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.