Slides used in meetup presentation in Madrid on January 17º 2018 https://www.meetup.com/es-ES/Front-end-Developers-Madrid/events/246638299/

1. Clean Code, Patrones, buenas
prácticas, son aplicables en
Javascript?
Leonardo Micheloni
@leomicheloni

2. Agradecimientos
• Front end Developers Madrid
• Luis
• International Lab
• Asistentes

3. Presentación
• Leonardo Micheloni @leomicheloni
• Argentino
• MVP
• Tokiota

4. Agenda
• Intro: ¿por qué son importantes estos conceptos y cómo se relacionan?
• Patrones
• KISS
• DRY
• YAGNI
• Code Smells
• TDD
• SOLID
• Clean Code

5. ¿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
• Nuestro objetivo es el código autodocumentado

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

7. Patrones
• Son soluciones probadas a problemas comunes
• No son la mejor ni la peor solución
• No hay que aplicarlos siempre
• No somos mejores por aplicarlos
• Ante un escenario dado nos otorgan ventajas y desventajas
• Son un lenguaje común

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

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

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

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

12. SOLID
• Es un acrónimo de conceptos que ya existían
• Están ordenados por importancia
• Pensando para POO
• Para hacer el software mantenible, escalable, flexible, etc.

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

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

15. 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

16. TDD
• Test driven development
• Nos permite ir descubriendo el código
• Nos permite hacer refactor con una base de test
• Se basa en el ciclo, red, green, blue.
• Es útil para “documentar” el código
• Nos permite tener tests

17. Clean code
• Disminuir la carga cognitiva del código
• Evitar el código zombie
• Código autodocumentado
• Que indique su intención
• Evitar comentarios innecesarios
• Identación excesiva que aumente la complejidad ciclomática

18. Clean code
• Naming
• Condicionales
• Funciones
• Clases

19. Clean code: naming
• Los nombres deben tener sustantivos acompañando un verbo
• Deben ser claros en su intención
• Deben indicar responsabilidad única
• No deben tener prefijos o subfijos
• Deben tener simetría
• Las variables booleanas deben responder preguntas positivas
"D has a barrow in the market place
M is the singer in a band
D says to M "girl I like your face"
And M says this as she takes him by the hand"

20. Los nombres deben tener sustantivos acompañando un verbo
• Aumenta la carga cognitiva del código

21. Deben ser claros en su intención
• Aumenta la carga cognitiva del código

22. Deben indicar una única responsabilidad
• SOLID: S
• KISS

23. No deben tener prefijos o subfijos
• Aumenta la carga cognitiva del código

24. Deben ser simétricos
• Aumenta la carga cognitiva del código
• No deja clara la intención del código

25. Las variables booleanas deben responder preguntas positivas
• Aumenta la carga cognitiva del código
• No deja clara la intención del código

26. 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

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

28. 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

29. Comparar explícitamente
• KISS
• Aumenta la carga cognitiva del código

30. Preferir comparaciones positivas
• KISS
• Aumenta la carga cognitiva del código

31. No usar negaciones dobles
• KISS
• Aumenta la carga cognitiva del código

32. Asignar impícitamente
• KISS
• Aumenta la carga cognitiva del código

33. Evitar “magic numbers”
• DRY
• Aumenta la carga cognitiva del código

34. Evitar condicionales complejos
• DRY
• Aumenta la carga cognitiva del código

35. Clean Code: condicionales
• Smells
• Ser “antinegativo”
• Magic numbers
• Asignaciones de booleanos en condiciones
• Comentarios sobre una condición
• DRY
• Aumenta la carga cognitiva del código

36. 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

37. Clean Code: funciones
• Evitar Arrow Code
• Evitar funciones con demasiada responsabilidad
• Evitar funciones con efectos secundarios
• Evitar funciones con flag arguments

38. Evitar Arrow code
• Identiación excesiva
• Complejo de comprender
• Complejo de modificar
• SOLID: S
• KISS
• DRY

39. Evitar Arrow code
• SOLID: S
• KISS
• DRY

40. 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

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

42. • SOLID: S
• KISS
• DRY

43. Evitar flag arguments
• SOLID: S
• KISS
• DRY

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

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

46. Clean code: clases
• Sus métodos deberán tener alta cohesión
• Permite reutilizar código
• Permiten clarificar parámetros

47. Sus métodos deberán tener alta cohesión

48. Sus métodos deberán tener alta cohesión

49. Clean Code: clases
• Permiten reutilizar código
• Si detectamos que una clase tiene patrones repetitivos
• Si extraemos comportamiento de otra clase y perdemos cohesión

50. Clarificar parámetros

51. Clean Code: clases
• Smells
• Retornar siempre tipos nativos => primite obsession
• Métodos que no comparte miembros de la clase => baja cohesión
• Clases “Util”, “Global”
• Una clase cambia con mucha frecuencia => demasiada responsabilidad
• Utiliza mucho otra clase => feature envy

52. Mantenimiento
• Refactoring
• 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

53. Code
Review
Refactoring
Clean Code
SOLID
DRY
Pair
programming
Smells
Patrones
TDD

54. 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