Clean Code: YES, PLEASE!

8 consejos para conseguir hacer código de calidad

Si no es clean code, es una chapuza. Y esto es algo categórico. Podrá salvarnos entregas e incluso hacernos ganar dinero puntualmente, pero no deja de ser una chapuza.

You can read this article also in English.

Algo que como desarrollador vengo notando desde hace tiempo es que en general, tanto por parte de las empresas como por parte de los programadores, hay poca cultura de hacer código de calidad. De hecho, me atrevería a decir que en la mayoría de casos ni empresas ni clientes sabrían distinguir si un código es bueno o malo. Posiblemente porque siempre se ha seguido una estrategia cortoplazista centrada en añadir nuevas funcionalidades sin importar de qué manera. Y claro… si nadie lo reclama, es más fácil pasar de largo y no preocuparse por ello.

Sin entrar en el debate sobre quién tiene mayor parte de culpa, lo que sí es un hecho es que preocuparnos por la calidad de nuestro código nos beneficia a todos: empresas, programadores y clientes.

¿Por qué beneficia a la empresa?

• A la larga sale más barato: Recuerda que con un código de mala calidad, costará más dinero arreglar bug y añadir nuevas funcionalidades a medida que el proyecto crece.
• Previene la fuga de talento: Es un hecho que los buenos programadores no quieren trabajar en proyectos que son un desastre a nivel de código.
• Reduce la dependencia de los programadores: Evita que te eches a temblar si se va alguien con un gran conocimiento del proyecto ya que encontrar un sustituto siempre será mucho más fácil si el código es limpio y coherente.

Y es que detrás de cada “este proyecto sería mejor empezarlo de nuevo” hay una empresa perdiendo dinero.

¿Por qué beneficia al programador?

• Disminuye la frustración y el estrés, lo que se traduce en un aumento de la felicidad y satisfacción personal.
• Reduce el tiempo invertido en detectar la causa de los errores, ganando así tiempo para mantener el código limpio y asimilar conocimientos (digamos que el clean code se retroalimenta).
• Te ayuda a crecer como profesional, permitiendote incluso elegir donde quieres trabajar.

No olvides que un buen programador trabaja donde quiere, uno malo donde le dejan.

¿Por qué beneficia a los clientes?

• Aumenta el rendimiento y disminuye los errores, lo que se traduce en una mejor experiencia para los usuarios.
• Es más reusable y escalable, lo que permite que añadir nuevas funcionalidades o hacer cambios en las ya existentes sea más sencillo y por lo tanto más barato a largo plazo.
• Sobrevive mejor a las tendencias, si sale una nueva tecnología o un nuevo framework siempre te será más fácil migrar sobre una base sólida.

Cuando contratas un producto, asegúrate de que no te están engañando y lo que recibes cumple los estándares mínimos de calidad.

Conseguir hacer código más legible, escalable y reutilizable es algo por lo que vengo luchando desde hace tiempo y en Commite le damos mucha importancia, trabajando cada día para hacer del clean code nuestro mantra. ¿Cómo lo hacemos? Estos ocho consejos os ayudarán a haceros una idea:

— Todos a una

Lo primero es que tanto para la empresa como para los programadores el clean code sea un objetivo primordial, en otro caso es imposible. De nada vale que los programadores se lo curren mucho si la empresa presiona con las entregas y no pone las herramientas adecuadas. Lo mismo ocurre en la dirección opuesta: si la empresa ofrece formación y flexibilidad pero los programadores no ponen interés la batalla está perdida igualmente.

— Lee el libro sagrado

Toda doctrina tiene su libro sagrado y en este caso se llama clean code (está en español también). Todo programador que se precie debería leer y asimilar el libro, independientemente de la tecnología que use. Deja de picar código y empieza a programar.

— Control de versiones

Usa una herramienta de control de versiones. Dónde digo herramienta de control de versiones digo GIT, básicamente por los siguientes motivos; es software libre, es el estándar y hay muchas otras herramientas que trabajan sobre él que nos ayudarán a conseguir que nuestro código sea mejor.

— Sigue una guía de estilo de código

Si tuviéramos que escribir un libro entre varias personas, no se nos ocurriría ir escribiendo cada uno con distinta tipografía, tamaño de letra o interlineado en el mismo documento, ¿cierto?. Entonces ¿por qué lo hacemos cuando escribimos código? Antes de empezar cualquier proyecto deberíamos tener una guía de estilo de código para cada tecnología que se use. No hace falta elegir una nueva cada vez, ni siquiera que lo hagamos nosotros mismos. Basta con buscar en Internet “guía de estilos {{ tecnología deseada }}” y asegurarse que todo el mundo sigue la misma. Un código más uniforme permitirá a todo el mundo adaptarse mejor al proyecto y tener que pensar menos para interpretarlo.

Aconsejable que se integre en el IDE para que nos avise cuando la estamos incumpliendo o incluso corrija los errores por nosotros. Estamos en el siglo XXI, empecemos a actuar como tal delegando en las máquinas las tareas repetitivas.

— Planifica

Usa una metodología ágil, pero no como excusa para no planificar. El proyecto debería tener una hoja de ruta que todo el equipo debería conocer. No hace falta que sea ultra detallada, basta con una aproximación. Ir a la deriva no es positivo para ningún proyecto.

Usa SCRUM y los “benditos” sprints, o un simple tablero KANBAN, lo que mejor se adapte a tu proyecto. Personalmente como programador prefiero este último, se trabaja más relajado y creo que favorece a que se consiga mejor calidad de código. Los sprints meten demasiada presión al equipo y a veces son contraproducentes, aunque entiendo que para quien gestiona el proyecto son una buena herramienta.

— Revisa el código

Tatúate la siguiente afirmación:

Nadie debería añadir código al proyecto sin que lo revise al menos otro miembro del equipo.

Si lo estás haciendo, cosa de la que estoy casi seguro, difícilmente estarás haciendo clean code. Toda empresa debería tener una figura senior en {{ inserte tecnología o framework }} que revise lo que se añade al proyecto para evitar que la gente siga antipatterns.

Algunas de las ventajas de la revisión de código son que permite detectar errores, transmitir conocimiento entre los miembros del equipo y ayudar a que todo el mundo esté al tanto de los cambios que se realizan. Ésta es la única manera de conseguir clean code cuando hay más de una persona trabajando en el proyecto.

— Divide y vencerás

Divide el trabajo en tareas de una duración máxima de 4 horas, las tareas muy grandes dan sensación de que no se avanza y desmotivan al equipo. Sin contar que, como hemos acordado antes, alguien tendrá que revisar ese código. Si las tareas hacen demasiadas cosas, es imposible hacer una buena revisión.

(Aviso para los managers: Intentad añadir una descripción concisa sobre lo que debe hacer y un TO-DO list con los requisitos que se tienen que satisfacer).

(Aviso para los programadores: Antes de poneros a hacer nada, aseguraos de que entendéis bien lo que tenéis que hacer. De otra manera es complicado que vuestra solución sea óptima).

— Controla la deuda técnica

Es inevitable acumular deuda técnica en un proyecto, pero ésta debería ser controlada. Para ello cuando estés introduciendo algo que sabes que se podría hacer mejor, crea inmediatamente una tarea explicando cómo se podría mejorar (aprovecha que lo tienes fresco).

Por si acaso alguien no lo sobreentiende, en algún punto hay que invertir tiempo en reducir deuda técnica. Lo ideal sería reservar X tiempo a la semana, o bien parar una semana en algún momento para resolver este propósito.

Considero que estas son las bases para conseguir hacer código de mayor calidad, si nos falla alguna pata, difícilmente lo lograremos.

Para los que luchan en su día a día por este objetivo, espero vuestros comentarios sobre lo que mejor os funciona. Para los que no, espero, por lo menos, haber despertado vuestra curiosidad sobre el tema.

¡Happy coding!