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.