The art of readable code y como estoy reteniendo más de sobre lo que leo

Siempre me ha gustado leer mucho, tanto ficción como cosas para aprender ya sea generales o de trabajo. Sin embargo siempre he tenido problemas muy grandes para terminar los libros que empiezo y para retener el conocimiento de estos. Por esto estoy tratando de tomar notas y hacer resúmenes sobre lo que voy leyendo. Esta técnica es muy HP conocida, y ha sido explicada varias veces por Youtubers enfocados en temas de productividad como Frank Thomas, quien explica esta y otras técnicas en el siguiente video:

Algo interesante es que no solo he aplicado estas técnicas a libros, sino también a artículos, video de Youtube, en fin, cualquier tipo de contenido del que me gustaría retener más información. Toda esa información se empieza a acumular y ayuda a que sea más fácil empezar nuevas cosas a partir de ahí, como por ejemplo este post. Si les interesa luego les puedo contar cómo estoy tomando y compilando mis notas, pero de momento voy a enfocarme en el primer libro que voy a comentarles.

The art of readable code por Dustin Boswell, Trevor Foucher

Este libro lo compre como parte de un HumbleBundle de libros de O’Reilly, así que pague muy poco por él. Lo cual es bueno porque si bien no es un libro malo de ninguna forma, esperaba muchísimo más. La gran mayoría de principios y consejos que dicen son cosas que uno aprende ya en el trabajo, a las malas normalmente, o que ya se han dicho en otro libros. Eso sí, por su forma de explicar y de dar ejemplos, este libro debería ser leído por gente que apenas esta empezando a trabajar o a estudiar programación, de modo que salgan a la calle ya con buenas prácticas.

Uno de los principios que el libro hace mucho hincapié y que estoy 1000% de acuerdo, es dejar la híper-obsesión con micro-optimizaciones, cuyo costo por hacer el código más difícil de leer es muchísimo mayor que la que mejora en rendimiento. Reducir lineas de código por reducirlas no va a hacer necesariamente en rendimiento, pero va a complicar el trabajo de la próxima persona que tenga que cambiar algo ahí. Lo mismo aplica para otras practicas para como usar nombres abreviados o limitar el tamaños de linea de código.

Muchas de estas prácticas vienen de lenguajes como C o Foltran donde las restricciones de memoria eran muy fuertes, pero en los ambientes modernos no tienen sentido de ser. Tampoco la idea es poner nombres de 256 caracteres de largo, pero un par de palabras más en un nombre no van a afectar en nada al programa pero sí van a mejorar muchísimo la legibilidad, lo cual hará más fácil trabajar con este código en el futuro.

El libro cubre a más profundidad estos puntos y otros más, incluyendo ejemplos de código antes de los cambios y cómo queda después. También tiene ejemplos en múltiples lenguajes, así que es muy fácil entender los ejemplos y cuál es el cambio que están haciendo. Como les decía al inicio del review, no siento que sea libro malo, pero yo estaba esperando algo más avanzado.

La siguiente es una lista resumida de otros puntos que menciona el libro:

  • Los nombres son cómo pequeños comentarios que se ven en todo lado. Un nombre puede contener muchísima información acerca del propósito y uso del elemento (ej. duracion vrs. maximaduracionmilisegundos)
  • A propósito de comentarios, un comentario sin razón es más peligroso que si no hubiera comentario del todo. Es preferible poner nombres informativos y funciones claras y separas, y dejar los comentarios para las cosas que el código no puede explicar, como reglas de negocio o razones xq algún cambio
  • El código que hace cosas similares debe verse similar. Esto se puede lograr separando en métodos del mismo nivel, usando columnas o simplemente dejando lineas en blanco
  • Si bien los lenguajes permiten hacer cosas en una sola linea, a veces es mejor separar expresiones muy complicadas en varias lineas y/o variables para facilitar su lectura. Sin embargo tener demasiadas variables puede también ser contraproducente. Si la variable no es reutilizada o no este simplificando una expresión, posiblemente se puede quitar
  • La mente humano no tiene la misma capacidad de memoria que una computadora, así que los principios de DRY (Don’t repeat yourself) y SR (single responsibility) son esenciales para dividir funciones y clases en elementos más pequeños y sencillos, y por ende más entendibles
  • Una buena idea para ver si el código podría ser más entendible, es escribir la lista de pasos que el código debería hacer en lenguaje natural.
  • Si el código hace más cosas que la lista de pasos, posiblemente haya que dividirlo en funciones o simplificar el algoritmo
  • Las pruebas unitarias si bien no son parte del código que se entrega a clientes, necesitan el mismo cuidado. Primero porque las pruebas son un tipo de documentación sobre cómo el código debe ser usado y sus respuestas esperadas, y segundo por que si el código de las pruebas no es agradable, nadie va a querer agregar o modificar pruebas, por lo que van a quedarse desactualizadas
  • Finalmente, el mejor código es el que no se hace, a veces es mejor detenerse y entender realmente cúal es el problema y hacer solo lo necesario antes de sobrecomplicarse

Cuéntenme en los comentarios que les pareció el review, algún otro libro que les gustaría que yo les y comente, o si ya leyeron este mismo libro díganme si están de acuerdo con mi review.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.