Adiós, código limpio (2020)

Despedida de la limpieza del código

• Un colega hizo check-in tarde en la noche del código que había escrito durante toda la semana.
• Implementó una función para ajustar el tamaño de las formas en el lienzo de un editor gráfico.
• El código funcionaba, pero era repetitivo.

A la mañana siguiente...

• El jefe pidió hablar en privado y solicitó revertir los cambios de código.
• Al principio fue impactante, pero al final se dio cuenta de que la decisión del jefe había sido correcta.

Etapa

• Obsesionarse con el "código limpio" y concentrarse en eliminar duplicación es una etapa por la que pasan muchos desarrolladores.
• Cuando uno no tiene confianza en su código, es tentador vincular la autoestima y el orgullo profesional a cosas que se pueden medir.
• Una vez que se aprende la abstracción, cada vez que se ve código repetido dan ganas de usarla.

La opinión de GN⁺

• Lo importante es que perseguir la "limpieza" del código no es el objetivo, sino una especie de mecanismo de defensa en el proceso de lidiar con sistemas complejos.
• El "código limpio" ayuda a los desarrolladores a servir como guía en territorio desconocido, pero no hay que obsesionarse solo con eso y también hay que saber soltarlo.
• Este artículo ofrece una perspectiva interesante que les recuerda a los desarrolladores la importancia de la colaboración y la practicidad al escribir y mantener código.

[GN⁺]

Comentarios de Hacker News

• "Clean Code" necesita un cambio de imagen de marca

  • El objetivo del código limpio es hacer que el código sea más simple y más fácil de mantener
  • El valor del software está en su capacidad de cambiar con el tiempo
  • Si el refactoring hizo que el mantenimiento fuera más difícil, entonces eso no es código limpio
  • No haber hablado del refactoring con el desarrollador original es un problema aparte del código limpio

• La duplicación de código a veces puede ser buena, pero no es prueba de que el código limpio sea malo

  • Si reemplazaste 10 líneas de cálculos matemáticos repetidos con una función, podría quedar más limpio
  • Hay que revisar el PR y rechazarlo si no cumple con el estándar
  • Ignorar la importancia del código limpio termina llevando a una base de código en la que nadie quiere trabajar
  • La lección es que hace falta mejor comunicación y más moderación

• Un colega escribe mucho código con copiar y pegar

  • El refactoring debe subirse para revisión
  • Que el jefe intervenga directamente y ordene revertirlo es una mala señal
  • La lección no es que copiar y pegar sea mejor que escribir una función

• Es muy probable que la versión de código limpio haya reemplazado código sucio

  • Hace falta una lección sobre cómo trabajar en equipo

• Se necesita revisión de pares al cambiar código

  • Hay que reconocer la falta de un buen proceso
  • El refactoring de código solo debe hacerse cuando sea necesario

• En el sector financiero, a menudo se trabaja con productos parecidos pero distintos

  • Es importante evitar la abstracción excesiva y mantener el código limpio

• Lenguajes como Haskell maximizan la abstracción a nivel del lenguaje

  • Aunque minimizan la abstracción por proyecto, el costo de aprendizaje es alto

• Mover los cálculos matemáticos repetidos a una función separada sí cuenta como código limpio

  • Refactorizar funciones de redimensionamiento que solo parecen formar una interfaz está mal

• Explicación sobre una mala abstracción

  • El problema es diseñar sin considerar lo suficiente el uso futuro

• Rob Pike dijo: "un poco de copia es mejor que un poco de dependencia"

  • El principio DRY a veces agrega abstracción, pero si la abstracción no es lo bastante ortogonal, más bien empeora el problema