Notas del curso Clean Code aplicado para desarrollos limpios y rentables del Clúster Tic de Galicia.

• Horas: 30
• Fecha Inicio: 11/09/2023
• Fecha Fin: 22/10/2023

Código empleado durante el curso: https://github.com/cleancodeTrIT/CleanCodeLab

• Desarrollar aplicaciones fáciles de mantener.
• Reducir la cantidad de errores y facilitar su detección.
• Distinguir y aplicar las buenas prácticas de programación.
• Adoptar la disciplina profesional de un artesano del software.

• 0. Introducción
  • 0.1. Hola Mundo
  • 0.2. Perdona, pero tu código huele
  • 0.3. Software que funciona
  • 0.4. El instructor
• 1. Estilo y nombrado
  • 1.0. Claridad con el menor esfuerzo
  • 1.1. Estilo y orden
    • Laboratorio: Estilo y orden
  • 1.2 Tamaños y límites
    • Laboratorio: Tamaños y límites
  • 1.3 Definiciones con sustantivos
    • Laboratorio: Definiciones con sustantivos
  • 1.4 Acciones con verbos
    • Laboratorio: Acciones con verbos
  • 1.5 Tarea propuesta Tema 1
    • Tarea Solución Tema 1
• 2. Instrucciones, bloques y funciones
  • 2.0. Organización de sentencias
  • 2.1. Declaración, asignación e invocación
    • Laboratorio: Declaración, asignación e invocación
  • 2.2. Estructuras repetitivas y condicionales
    • Laboratorio: Estructuras repetitivas y condicionales
  • 2.3. Funciones puras y métodos de clase
    • Laboratorio: Funciones puras y métodos de clase
  • 2.4. Tarea propuesta Tema 2
    • Tarea Solución Tema 2
• 3. Estructuras de datos
  • 3.0. Abstracciones de información
  • 3.1. Cohesión de primitivos
    • Laboratorio: Cohesión de primitivos
  • 3.2. Condiciones y algoritmos
    • Laboratorio: Condiciones y algoritmos
  • 3.3. Tarea propuesta Tema 3
    • Tarea Solución Tema 3
• 4. Objetos y lógica de negocio
  • 4.0. Abstracciones de lógica
  • 4.1. Cohesión de funciones
  • 4.2. Principios sólidos para finales flexibles
    • TLaboratorio: Srp
    • TLaboratorio: Ocp
    • TLaboratorio: Lsp
    • TLaboratorio: Isp
    • TLaboratorio: Dip
  • 4.3. Tarea propuesta Tema 4
    • Tarea Solución Tema 4
• 5. Artesanía del software
  • 5.0. De programador a artesano
  • 5.1. Hacer las cosas bien
  • 5.2. Disciplina y buenos hábitos

¿Cuándo debemos refactorizar?

• Antes de cada push
• Al finalizar el sprint
• Constantemente
• Los viernes

¿Los nombres de las funciones?

• No importan, lo importante son las variables.
• Deben empezar por un verbo (idealmente elegido de un diccionario).
• Deben ser lo más cortos posible.
• Deben ser lo más descriptivos posible e incluir tipos y visibilidad.

¿Cuándo debemos escribir tests?

• Antes de refactorizar
• Al finalizar el sprint
• Constantemente
• Los viernes

¿Importa el tamaño?

• No, nada.
• Sí, los caracteres por línea y las líneas por fichero.
• Sólo los caracteres por línea.
• Depende de tu agudeza visual y agilidad manual.

¿Las herramientas nos ayudan?

• Sí, mucho cuando las configuramos bien.
• Sí, pero no tanto.
• No, nada.
• El IDE ayuda, lo demás estorba

¿Los nombres de variables?

• Deben ser lo más descriptivos y significativos posible.
• Deben ser lo más cortos posible.
• Deben ser lo más descriptivos posible e incluir tipos y visibilidad.
• Deben estar en mayúsculas.

¿Hay reglas gramaticales además de las sintácticas?

• En métodos y flags empezar por Verbos, para lo demás por Sustantivos.
• Verbos y Sustantivos para métodos.
• Verbos para métodos, Sustantivos para lo demás.
• ¿Estás de broma?, Esto no es clase de Lengua.

Las estructuras repetitivas y condicionales…

• Se pueden anidar indefinidamente mientras los bloques de instrucciones sean cortos.
• No deben contener bloques muy largos ni anidarse mucho.
• Si el lenguaje lo permite deben sustituirse por ternarios.
• Mejor con que tengan condiciones complejas.

Los argumentos de las funciones…

• Cuantos más argumentos mejor.
• Mejor con argumentos primitivos.
• Mejor pocos y evitando primitivos.
• No influyen en la limpieza.

Las funciones…

• Deberían retornar siempre un valor
• Las funciones puras sólo pueden tener un efecto secundario.
• Cuanto más grande sean mis funciones menos funciones necesito; y eso es mejor.
• Una función debería hacer una sola cosa, hacerla bien, y hacerla sólo ella.

El modelo de datos

• Es dónde se expresa más claramente la lógica del negocio.
• Viene determinado por la base de datos.
• Es más sencillo tratar con tipos primitivos, las estructuras son de clever code.
• Es preferible la composición a la herencia.

Las estructuras condicionales y los datos

• No tienen nada que ver.
• Puedes sustituir condiciones por búsquedas en estructuras.
• Nunca debemos usar if ni switch, siempre es mejor factorías, abstracciones y herencias.
• El switch es mala cosa, mejor encadenar if y else if.

Las variables de tipo primitivo

• Son una mala práctica sólo si son argumentos de funciones.
• Son una buena práctica.
• Son una mala práctica, mejor encapsularlos en tipos compuestos.
• No influye en la claridad del código

Sobre las las clases para crear objetos

• Es dónde se expresa más claramente la lógica del negocio.
• La herencia es lo mejor de las clases.
• Deberían de tener la menor cohesión posible.
• Cuanto más grandes mejor, porque así hay menos.

Las clases:

• No deberían tener datos
• No deberían tener lógica
• Deberían tener lógica asociada con los datos.
• Deberían tener el mismo número de métodos que de propiedades.

Los principios SOLID

• Hay que aplicarlos todos siempre.
• Están desfasados.
• Usados convenientemente mejoran la flexibilidad del código.
• Sólo se aplican para proyectos dónde hay un departamento de arquitectura.

EL principio SOLID más importante es

• El de Responsabilidad única para fomentar la cohesión SRP
• El Open/Close para minimizar conflictos en git OCP
• El de Liskov para evitar la herencia múltiple LSP
• El de Segregación de interfaces para escribir menos código ISP

La artesanía del software…

• Promueve la mejora constante de nuestras habilidades.
• Genera satisfacción por el trabajo bien hecho, a veces con reconocimiento externo.
• Se consigue con la adquisición de buenos hábitos impulsados con disciplina.
• Todas las anteriores son ciertas.

¿Qué es el código artesanal?

• Código que se escribe con cuidado y atención a los detalles.
• Código fácil de modificar.
• Código fácil de testear.
• Todas las anteriores son ciertas.