Sección perteneciente al curso Clean Code aplicado para desarrollos limpios y rentables

El código se puede hacer bien o mejor.

Ley de Eagleson:

“Cualquier código tuyo que no hayas mirado últimamente es como si lo hubiese escrito otro”.

Partiremos de la base de que el código está bien (funciona), pero queremos mejorarlo.

Principios de mejora:

• Mostrar intención y ocultar detalles:
• Evitar globalización y acoplamiento: si el código es muy dependiente de su entorno, será muy difícil extraerlo y llevarlo a otro sitio
• Separar responsabilidades: que cada responsabilidad esté bien definida y no haya que perder tiempo buscando por diferentes ficheros.
• Don't repeat yourself (DRY): el mismo código no debe estar en más de un sitio ya que al hacer un cambio, habrá que tocar en todos esos sitios.
• Keep It Simple, (not) Stupid (KISS): el código debe ser simple para que sea sencillo de mantener.

“Cualquiera puede escribir código para que lo entienda una máquina. Pero los programadores profesionales escriben código para que lo entiendan los humanos” – Martin Fowler

El código está vivo, es mantenible. El software es la parte cambiante de los sistemas informáticos, al contrario que el hardware que es más rígido. Tarde o temprano, el código se releerá y el objetivo es que sea fácil de leer.

Con la idea de ser para otras personas, podremos ponérselo más sencillo.

Criterios para evitar que el código huela:

• Estilo y nombrado
• Instrucciones y funciones
• Estructura de datos
• Objetos y lógica de negocio
• Artesanía del software

“El código limpio parece escrito por alguien a quien le importa” – Robert C. Martin.

“Codifica como si la persona que mantendrá tu código fuera un psicópata violento que sabe dónde vives” – Martin Golding.

Los cambios que hagamos para que el código sea mejor tiene que mantener la satisfacción del usuario. Para ayudarnos en esta labor, emplearemos unos tests que permitan saber que el software sigue funcionando sin fallos.

“Write tests. Not too many. Mostly integration” – Kent C. Dodds.

Cambiar por dentro sin cambiar por fuera es la clave del refactoring.

“¿Por qué temes cambiar su código? ¡Por miedo a que se rompa! ¿Por qué temes romperlo? Porque no tengo pruebas. Si funciona, y tienes pruebas, tócalo” – Robert C. Martin

“La verdad solo se encuentra en su lugar: el código” – Robert C. Martin