(Re)descubriendo la sencillez en nuestro código

Revisión de distintas reglas, prácticas y principios que nos pueden guiar en el diseño de código más sencillo, mejor diseñado y, por lo tanto, más mantenible. Pasando, entre otros, por las cuatro reglas de Kent Beck para el diseño sencillo, la identificación de ciertos code smell o ejemplos de aplicación de distintos principios S.O.L.I.D. en nuestro código

Transcript

1. REDESCUBRIENDO LA SENCILLEZ EN NUESTRO CÓDIGO Carlos Tirado So,ware Developer @CarlosTiradoG
3. DESARROLLADOR TRAS UNA SEMANA
4. DESARROLLADOR TRAS UN MES
5. DESARROLLADOR TRAS UN AÑO
6. DESARROLLADOR TRAS TRES AÑOS
7. DESARROLLADOR TRAS SEIS AÑOS
8. DESARROLLADOR TRAS DIEZ AÑOS
9. DISCLAIMER •  Orientación a Objetos •  El lenguaje condiciona •  Principios, guías… no reglas •  Subje:vidad EVERYWHERE •  Muchos acrónimos (y algo de inglés)
10. SIMPLICITY
11. “La simplicidad es la mayor sofis1cación” Leonardo da Vinci
12. “La belleza en el es1lo, la armonía, la gracia y el buen ritmo dependen de la simplicidad” Platón
13. MANIFIESTO ÁGIL PRINCIPIO Nº 10 “La simplicidad, o el arte de maximizar la can1dad de trabajo no realizado, es esencial.”
14. SIMPLICITY IS THE KEY PRINCIPIO XP Haz la cosa más simple que pueda funcionar ¿Qué es la simplicidad? La simplicidad es el camino más corto a una solución - Ward Cunningham
15. KISS PRINCIPIO DE DISEÑO Keep it simple, stupid
16. SENCILLO NO ES FÁCIL SENCILLO <-> COMPLEJO FÁCIL <-> DIFÍCIL
17. COMPLEJIDAD ACCIDENTAL - Tecnología - Desconocimiento de features - Op:mizaciones prematuras - Abstracciones incorrectas - Sobreingeniería - Centrarnos en el futuro
18. YAGNI PRINCIPIO XP Implementa siempre las cosas cuando realmente las necesites, no cuando prevés que lo vas a necesitar. - Ron Jeffries You Aren't Gonna Need It
19. 4 RULES OF SIMPLE DESIGN KENT BECK 1. Runs all the tests 2. Has no duplicated logic. Be wary of hidden duplica:on like parallel class hierarchies 3. States every inten:on important to the programmer 4. Has the fewest possible classes and methods
20. 4 RULES OF SIMPLE DESIGN MARTIN FOWLER 1. Passes the tests 2. Reveals inten:on 3. No duplica:on 4. Fewest elements
21. 4 RULES OF SIMPLE DESIGN MARTIN FOWLER
22. 4 RULES OF SIMPLE DESIGN JB RAINSBERGER 1. Passes the tests 2-3. Remove duplica:on 2-3. Improve names 4. Fewest elements
23. 4 RULES OF SIMPLE DESIGN JB RAINSBERGER
24. DRY (DON’T REPEAT YOURSELF) PRINCIPIO Every piece of knowledge must have a single, unambiguous, authorita1ve representa1on within a system. Andy Hunt y David Thomas - The Pragmatic Programmer
25. DRY (DON’T REPEAT YOURSELF) “duplica>on is far cheaper than the wrong abstrac>on” Sandi Metz - My RailsConf 2014 PRINCIPIO “prefer duplica>on over the wrong abstrac>on”
26. REUSABILIDAD Uwe Friedrichsen @ufried “Keep reusability for libraries, not for services”
27. REUSABILIDAD
28. SOLID Serie de principios de diseño en la programación orientada a objetos PRINCIPIOS DE DISEÑO Alta cohesión Bajo acoplamiento Single responsibility principle Open/closed principle Liskov subs;tu;on principle Interface segrega;on principle Dependency inversion principle S O L I D OOP for Dummies
30. SINGLE RESPONSABILITY PRINCIPLE (SRP) PRINCIPIO DE RESPONSABILIDAD ÚNICA SOLID Una clase o módulo debería tener una sola razón para cambiar
31. SINGLE RESPONSABILITY PRINCIPLE (SRP) PRINCIPIO DE RESPONSABILIDAD ÚNICA SOLID
32. OPEN/CLOSE PRINCIPLE (OCP) PRINCIPIO ABIERTO/CERRADO SOLID Abierto para su extensión, pero cerrado para su modificación
33. OPEN/CLOSE PRINCIPLE (OCP) PRINCIPIO ABIERTO/CERRADO SOLID h#p://blog.koalite.com/2011/10/openclosed-principle-method-template-strategy-y-otras-alterna<vas/
34. OPEN/CLOSE PRINCIPLE (OCP) PRINCIPIO ABIERTO/CERRADO SOLID h#p://blog.koalite.com/2011/10/openclosed-principle-method-template-strategy-y-otras-alterna<vas/
35. LISKOV SUBSTITUTION PRINCIPLE (LSP) PRINCIPIO DE SUSTITUCIÓN DE LISKOV SOLID Una clase derivada no debe modificar el comportamiento de la clase base
36. LISKOV SUBSTITUTION PRINCIPLE (LSP) PRINCIPIO DE SUSTITUCIÓN DE LISKOV SOLID
37. INTERFACE SEGREGATION PRINCIPLE (ISP) PRINCIPIO DE SEGREGACIÓN DE INTERFACES SOLID Los clientes no deben verse obligados a depender de interfaces que no u>lizan
38. INTERFACE SEGREGATION PRINCIPLE (ISP) PRINCIPIO DE SEGREGACIÓN DE INTERFACES SOLID h#p://blog.koalite.com/2015/04/principio-de-segregacion-de-interfaces-para-abuelas/
39. DEPENDENCY INVERSION PRINCIPLE (DIP) PRINCIPIO DE INVERSIÓN DE DEPENDENCIAS SOLID A. Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones. B. Las abstracciones no deben depender de detalles, son los detalles los que deben depender de abstracciones.
40. DEPENDENCY INVERSION PRINCIPLE (DIP) PRINCIPIO DE INVERSIÓN DE DEPENDENCIAS SOLID
41. LA LEY DE DEMETER PRINCIPIO No hables con extraños
42. LA LEY DE DEMETER PRINCIPIO h#p://blog.koalite.com/2014/06/ley-de-demeter-tell-dont-ask-y-god-object/
43. LA LEY DE DEMETER PRINCIPIO h#p://blog.koalite.com/2014/06/ley-de-demeter-tell-dont-ask-y-god-object/
44. LA LEY DE DEMETER + TELL DON’T ASK PRINCIPIO h#p://blog.koalite.com/2014/06/ley-de-demeter-tell-dont-ask-y-god-object/
45. NOMBRES •  Nombres descrip<vos •  Lenguaje ubicuo o de solución •  Que se puedan buscar -> la longitud está relacionada con el scope •  Clases nombres. Métodos verbos. •  No hace falta elegir bien los nombres a la primera -> REFACTORIZAR CLEAN CODE
46. FUNCIONES •  Funciones muy cortas •  Las funciones deben hacer sólo una cosa •  Stepdown •  Cuantos menos argumentos mejor •  SLA: Separar dis<ntos niveles de abstracción •  CQS: Separación de comandos y queries CLEAN CODE
47. COMENTARIOS •  Mejor un método que un comentario •  Explicar el por qué, no lo que hace •  No ser redundante •  No u<lizarlos como histórico de cambios •  Código comentado -> BORRARLO •  Los TODOs con cuidado (asociados a <cket) •  Para APIs, librerías, etc. CLEAN CODE
48. COMENTARIOS CLEAN CODE //TODO: generar este objeto con un factoria var trabajador = new Trabajador(id); // compruebo que el trabajador no es nulo if (trabajador != null) { //if (trabajador.FechaAlta >= DateTime.Now) // Carlos NUEVO 12/10/2017 // Comprobamos si el trabajador esta dado de alta // No es suficiente con la fecha, puede tener fecha de alta vigente pero estado suspendido if (trabajador.FechaAlta >= DateTime.Now && trabajador.Estado == TrabajadorEstado.Alta) { _servicioInscripcion.InscribirTrabajadorEnCurso(trabajador, curso); } }
49. COMENTARIOS CLEAN CODE //TODO: Ticket 13340 - generar este objeto con un factoria var trabajador = new Trabajador(id); if (trabajador != null) { if (trabajador.EstaDadoDeAlta) { _servicioInscripcion.InscribirTrabajadorEnCurso(trabajad or, curso); } }
50. OTROS CONSEJOS •  El mejor código es el que no existe •  Usa las convenciones (o por lo menos se consistente) •  Team rules •  Sigue la regla del boy scout •  El código de test como ciudadano de primera clase
51. LIBROS RECOMENDADOS
52. LIBROS RECOMENDADOS
53. REFERENCIAS •  The Rules Of Extreme Programming hcp://www.extremeprogramming.org/rules.html •  Simplicidad para desarrolladores – Eduardo Ferro hcps://www.youtube.com/watch?v=6FDxbCzh2sI •  Simple Made Easy – Rich Hickey hcps://www.infoq.com/presenta:ons/Simple-Made-Easy •  8 Lines of Code – Greg Young hcps://www.infoq.com/presenta:ons/8-lines-code-refactoring •  Yagni – Mar:n Fowler hcps://mar:nfowler.com/bliki/Yagni.html •  BeckDesignRules – Mar:n Fowler hcps://mar:nfowler.com/bliki/BeckDesignRules.html
54. REFERENCIAS •  Pulng An Age-Old Bacle To Rest – J.B. Rainsberger hcp://blog.thecodewhisperer.com/permalink/pulng-an-age-old-bacle-to-rest •  The Wrong Abstrac:on – Sandi Metz hcps://www.sandimetz.com/blog/2016/1/20/the-wrong-abstrac:on •  The Principles of OOD – Robert C. Mar:n hcp://butunclebob.com/Ar:cleS.UncleBob.PrinciplesOfOod •  Why Every Element of SOLID is Wrong – Dan North hcps://speakerdeck.com/tastapod/why-every-element-of-solid-is-wrong •  SOLID is OOP for dummies – Yegor Bugayenko hcp://www.yegor256.com/2017/03/28/solid.html •  Pure DI – Mark Seemann hcp://blog.ploeh.dk/2014/06/10/pure-di/