Clean code y SOLID
•
3 recomendaciones•701 vistas
¡Por fin compila! No obstante, ¿otro programador sería capaz de entender tu código sin susurrar un solo WTF? ¿Es lo suficientemente claro como para que otro compañero no necesite días para entender lo que hace tu sistema?
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Clean code y SOLID
Similar a Clean code y SOLID (10)
Clean code y SOLID
- 5. ESCRIBIENDO CÓDIGO PARA HUMANOS LEGIBLE SOSTENIBLE REUTILIZABLE VERIFICABLE
- 6. ESCRIBIENDO CÓDIGO PARA HUMANOS RÍGIDO FRÁGIL POCO/NADA REUTILIZABLE OPACO
- 7. ESCRIBIENDO CÓDIGO PARA HUMANOS ¿POR QUÉ ESCRIBIMOS “MAL” CÓDIGO? ▸ Rapidez ▸ Falta de motivación/experiencia ▸ Posponerlo para algún refactor
- 8. ESCRIBIENDO CÓDIGO PARA HUMANOS CLEAN CODE ▸ Robert C. Martin [2008] ▸ “Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees
- 9. “INDEED, THE RATIO OF TIME SPENT READING VERSUS WRITING IS WELL OVER 10 TO 1. WE ARE CONSTANTLY READING OLD CODE AS PART OF THE EFFORT TO WRITE NEW CODE. ...[THEREFORE,] MAKING IT EASY TO READ MAKES IT EASIER TO WRITE.” Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship CLEAN CODE
- 10. CLEAN CODE GENERAL ▸ Convenciones estándar ▸ Código lo más simple posible ▸ “Regla del Boy Scout”
- 12. CLEAN CODE NOMBRES ▸ Descriptivos y claros
- 13. CLEAN CODE NOMBRES ▸ Descriptivos y claros
- 15. CLEAN CODE NOMBRES ▸ Pronunciables y fáciles de buscar
- 17. CLEAN CODE FUNCIONES ▸ Pequeñas ▸ Una única tarea ▸ Pocos argumentos ▸ Evitar efectos secundarios ▸ Evitar flags como argumento ▸ DRY: Don’t Repeat Yourself
- 20. CLEAN CODE COMENTARIOS ▸ “Don’t comment bad code - rewrite it” ▸ Explicación mediante el código ▸ Evitar la redundancia ▸ TO DO y advertencias
- 23. CLEAN CODE GESTIÓN DE ERRORES
- 24. CLEAN CODE GESTIÓN DE ERRORES ▸ Evitar el uso de códigos de error ▸ Usar excepciones ▸ Cada vez que se devuelve Null muere un gatito ▸ … y cuando se pasa Null como parámetro también
- 25. CLEAN CODE GESTIÓN DE ERRORES
- 26. CLEAN CODE GESTIÓN DE ERRORES
- 28. CLEAN CODE TESTS UNITARIOS ▸ Un único assert por test ▸ F.I.R.S.T ▸ Fast ▸ Independent ▸ Repeatable ▸ Self-Validating ▸ Timely
- 30. ¿Y AHORA QUÉ?
- 34. ESCRIBIENDO CÓDIGO PARA HUMANOS SOLID ▸ Fácil de mantener ▸ Fácil de extender ▸ Robusto
- 36. SOLID SOLID ▸ Single Responsibility Principle (SRP) ▸ Open Closed Principle (OCP) ▸ Liskov Substitution Principle (LSP) ▸ Interface Segregation Principle (ISP) ▸ Dependency Inversion Principle (DIP)
- 37. SOLID SINGLE RESPONSIBILITY PRINCIPLE (SRP) “A class should have only one reason to change”
- 38. SOLID SINGLE RESPONSIBILITY PRINCIPLE (SRP)
- 39. SOLID SINGLE RESPONSIBILITY PRINCIPLE (SRP)
- 40. SOLID SINGLE RESPONSIBILITY PRINCIPLE (SRP) ▸ Reducción del acoplamiento ▸ Sencillez en el mantenimiento
- 41. SOLID OPEN CLOSED PRINCIPLE (OCP) “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”
- 42. SOLID OPEN CLOSED PRINCIPLE (OCP)
- 43. SOLID OPEN CLOSED PRINCIPLE (OCP)
- 44. SOLID OPEN CLOSED PRINCIPLE (OCP) ▸ Robustez ▸ Reusabilidad y sencillez a la hora de añadir nuevas features
- 45. SOLID LISKOV SUBSTITUTION PRINCIPLE (LSP) “Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.”
- 46. SOLID LISKOV SUBSTITUTION PRINCIPLE (LSP)
- 47. SOLID LISKOV SUBSTITUTION PRINCIPLE (LSP)
- 48. SOLID LISKOV SUBSTITUTION PRINCIPLE (LSP)
- 49. SOLID LISKOV SUBSTITUTION PRINCIPLE (LSP) ▸ Reusabilidad ▸ Claridad en la jerarquía de clases
- 50. SOLID INTERFACE SEGREGATION PRINCIPLE (ISP) “Many client-specific interfaces are better than one general-purpose interface”
- 51. SOLID INTERFACE SEGREGATION PRINCIPLE (ISP)
- 52. SOLID INTERFACE SEGREGATION PRINCIPLE (ISP)
- 53. SOLID INTERFACE SEGREGATION PRINCIPLE (ISP)
- 54. SOLID INTERFACE SEGREGATION PRINCIPLE (ISP) ▸ Desacoplamiento ▸ Sencillez en refactor
- 55. SOLID DEPENDENCY INVERSION PRINCIPLE (DIP) “High-level modules should not depend on low-level modules. Both should depend on abstractions.” “Abstractions should not depend on details. Details should depend on abstractions”
- 56. SOLID DEPENDENCY INVERSION PRINCIPLE (DIP)
- 57. SOLID DEPENDENCY INVERSION PRINCIPLE (DIP)
- 58. SOLID DEPENDENCY INVERSION PRINCIPLE (DIP) ▸ Reducción del acoplamiento ▸ Reusabilidad ▸ Permite realizar test más completos
- 60. SOLID CUIDADO CON LA SOBRE-INGENIERÍA INTENTA SER PRAGMÁTICO APLICA EL SENTIDO COMÚN
- 62. ESCRIBIENDO CÓDIGO PARA HUMANOS REFERENCIAS ▸ SOLID: The Definitive Guide - Arthur Antunes ▸ Clean Code - Robert C. Martin ▸ Principios de DOO - Robert C. Martin ▸ https://android.jlelse.eu/solid-principles-the-definitive-guide-75e30a284dea#.oofluhq1k ▸ http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod ▸ https://www.amazon.es/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882