Slides usados durante la charla "Javascript Kata: aplicando clean code y buenas prácticas en vivo" https://www.meetup.com/es-ES/Front-end-Developers-Madrid/events/250409421/

1. Clean Code en Javascript +
Live coding
Leonardo Micheloni
@leomicheloni

2. Agradecimientos
• Frontend Developers Madrid
• Luis y Vanessa
• eDreams
• Asistentes
@leomicheloni

3. Quién soy
• Leonardo Micheloni
• Programador +15 @leomicheloni
• Argentino
@leomicheloni

4. @leomicheloni

5. Agenda
• Conceptos
• KISS
• DRY
• YAGNI
• Code Smells
• SOLID
• Clean Code
• Refactor
• Live code!
@leomicheloni

6. ¿Por qué son importantes estos conceptos?
• Un framework / lenguaje / library no es más que una herramienta
• Se habla de ser bueno usando x pero no de ser buen programador
• Es cada vez más común mezclar tecnologías y herramientas
• Las aplicaciones evolucionan cada vez más rápido
• No siempre somos nosotros quienes comenzamos el código
@leomicheloni

7. @leomicheloni
https://coe.aceinfosolutions.com/

8. "Any fool can write code that a computer
can understand. Good programmers
write code that humans can understand."
Martin Fowler
@leomicheloni

9. DRY
• Don’t repeat yourself principle
• Es similar a la normalización de bases de datos
• Copy + Paste oriented programming
• Hay más líneas de código para mantener
@leomicheloni

10. KISS
• Keep it simple stupid
• Hay un momento en nuestra evolución que nos gusta ser complicados
• La simplicidad es belleza
@leomicheloni

11. YAGNI
• You ain’t gonna need it
• Voy a hacer tal cosa por las dudas
• No se extremistas
@leomicheloni

12. “La experiencia es eso que nos dice qué
tan bien merece la pena hacer las cosas
en función del contexto”
Yo
@leomicheloni

13. SOLID
• Single responsability principle
• Un objeto tiene que tener un único motivo para cambiar
• Open close principle
• Una entidad debe ser abierta para su extensión pero cerrada para modificación
• Liskov sustitution principle
• En una jerarquía un hijo B tiene que ser intercambiable por su clase base
• Interface segregation principle
• Una cliente no debe ser forzado a implementar métodos que no usará
• Dependency inversion principle
• Un cliente debe depender de abstracciones
@leomicheloni

14. Code Smells
• Olores de código
• Indican que el código tiene potenciales problemas
• Para ser mantenido
• Para escalar
• Para evolucionar
• Es propenso a errores
@leomicheloni

15. @leomicheloni

16. Clean code: naming
• Deben ser claros en su intención
• Deben indicar responsabilidad única
• No deben tener prefijos o subfijos
• Las variables booleanas deben responder preguntas positivas
@leomicheloni

17. Clean code: Naming
• Smells
• AND OR IF
• El código tiene “side effects”
• Tipos de datos en el nombre
• Booleanos que no responden una pregunta
• Variables o métodos que no son simétricos
• Funciones con efectos secundarios no descriptos por su nombre
• Aumenta la carga cognitiva del código
• No deja clara la intención del código
• SOLID: S
• KISS
@leomicheloni

18. Clean Code: Naming
• Soluciones
• Verbalizar con un amigo
• O con un pato de goma
• Refactorizar hasta que el nombre sea “limpio”
@leomicheloni

19. Clean Code: Condicionales
• Comparar explícitamente
• Preferir comparaciones de positivas
• Usar condicionales positivos (evitar la doble negación)
• Asignar implícitamente
• Evitar “magic numbers”
• Evitar condicionales complejos
@leomicheloni

20. Clean Code: condicionales
• Smells
• Ser “antinegativo”
• Magic numbers
• Asignaciones de booleanos en condiciones
• Comentarios sobre una condición
• Condiciones difícil de comprender
• DRY
• Aumenta la carga cognitiva del código
@leomicheloni

21. Clean Code: condicionales
• Soluciones
• Siempre usar booleanos que respondan preguntas positivas
• Poner magic numbers en variables
• Crear funciones si la condición es una regla de negocio
• Utilizar variables intermedias
@leomicheloni

22. Clean Code: funciones
• Evitar Arrow Code
• Evitar funciones con demasiada responsabilidad
• Evitar funciones con efectos secundarios
• Evitar muchos argumentos
• Evitar funciones con flag arguments
@leomicheloni

23. Arrow code
• Identiación excesiva
• Complejo de comprender
• Complejo de modificar
• SOLID: S
• KISS
• DRY
@leomicheloni

24. Funciones con efectos secundario
• El nombre no denota intención
• Hay miedo a cambiarlas
• Son peligrosas
• SOLID: S O
• KISS
• Aumentan la carga cognitiva del código
@leomicheloni

25. Funciones con mucha
responsabilidad
• Son difíciles de mantener
• Son difíciles de comprender
• Cambiar con mucha frecuencia
• SOLID: S
• KISS
• DRY
@leomicheloni

26. Clean code: funciones
• Smells
• Hay que hacer scroll para leerlas, vertical / horizontal
• Tienen demasiados parámetros
• Intención poco clara
• Cambian con mucha frecuencia
@leomicheloni

27. Clean Code: funciones
• Soluciones
• Guard clauses
• Fail fast
• Extract method
• Nuevas clases
• Rename
@leomicheloni

28. Clean Code: comentarios
• Pueden indicar que nuestro código no es claro
• Evitar comentarios obvios
• Evitar comentarios desactualizados
@leomicheloni

29. Clean Code: comentarios
• Smells
• Los comentarios son más grandes que el código
• El comentario dice lo mismo que el nombre de la función
• El comentario intenta explicar algo que el código debería
• El comentario indica miedo
@leomicheloni

30. Clean Code: soluciones
• Al escribir un comentario pensar por qué lo hacemos
• Cambiar la función / variable para que indique su intención
• Borrar comentarios en condiciones y extraer la condición
@leomicheloni

31. Refactor
• Cambiar el código sin modificar su comportamiento
• Hacerlo más legible
• Lo detectamos gracias a Code Smells, Patrones, DRY, etc.
• Aplicar algunos de los conceptos
• KISS
• DRY
• SOLID
• Baby steps
• El mejor refactor es el que quita código
@leomicheloni

32. @leomichelonihttp://itkidz.ie/wp-content/uploads/sites/15/2017/03/lets-code.png

33. Mind set
• Mirar el código
• No odiar
• Respect
• Baby steps
@leomicheloni

34. Mantenimiento
• Refactoring
• Baby steps
• No aceptar ventanas rotas
• Code reviews
• Pair programming
“Always leave the code you're editing a
little better than you found it.”
Robert C. Martin
@leomicheloni

35. Referencias
• https://app.pluralsight.com/library/courses/writing-clean-code-humans
• https://www.amazon.es/Test-Driven-Development-Addison-Wesley-Signature/dp/0321146530/
• https://www.amazon.es/Refactoring-Improving-Design-Existing-Technology/dp/0201485672/
• https://github.com/ryanmcdermott/clean-code-javascript
• https://www.amazon.es/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
• https://www.amazon.es/Code-Complete-Practical-Costruction-Professional/dp/0735619670/
• https://www.amazon.es/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/
• https://www.amazon.es/Head-First-Design-Patterns-Freeman/dp/0596007124/
• https://github.com/tcorral/Refactoring_Patterns
• https://www.youtube.com/watch?v=J18mLs-SRpI
@leomicheloni