Descargar como PDF, PPTX
Subido porEdwin Cruz
Codigo Escalable WDT
Este documento discute la importancia de mantener un alto nivel de calidad en el código a través del refactoring. Se mencionan varias métricas y "code smells" que pueden indicar problemas en el diseño del código y se proponen soluciones como extraer clases, mover métodos y utilizar patrones de diseño para mejorar la legibilidad, mantenibilidad y capacidad de extensión del código. También enfatiza la necesidad de invertir tiempo y recursos en refactoring para prevenir problemas a futuro y mantener un código de alta calidad.
Codigo Escalable WDT
- 1. Empowering innovation throughcollaboration
- 2.
- 4. • CTO @MagmaLabs • Evangelista de OpenSource • Conferencista • Programador por mas de 15 años • Ha tirado producción • Trabajado en sitios de alto desempeño y equipos multidisciplinarios, para clientes tipo: Google, GE, GoPro. • @softr8 everywhere! ¿Quién soy?
- 5. Startups that prioritizefeature velocity over quality tend to survive. This is deeply offensive to many software developers. https://mailchi.mp/railsspeed/on-quality-and-performance-at-early-stage-startups
- 6. Que es calidadde código
- 7. – Todos losprogramadores en algún punto “Mi código es lo mejor del mundo”
- 8. • Facilmente extendible •Pruebas unitarias • Escrito para humanos, no para computadoras • Auto-descriptivo • Fácilmente transferible a otra persona • Sin mensajes ocultos Cualidades de un buen código
- 9. ¿Se puede medirla calidad cuantitativamente? Claro! Hay herramientas que te ayudan
- 10. • Incidentes enProducción • Tiempo de ideación a liberación • Código real necesario • Código ejecutado por las pruebas automatizadas Métricas para medir calidad del código
- 11. • Complejidad ciclomática •Cuantos caminos de ejecución se crean, mayor numero menor calidad • Complejidad esencial • Que tanto código se puede reescribir para eliminar multiples caminos de ejecución • Densidad ciclomática • Radio del numero total de lineas de código entre el numero de puntos de desiciones lógicas Métricas para medir calidad del código
- 12. • Numero declases, hasta 6 niveles de herencia • Número de métodos por clase, no más de 20 • Número de lineas de código por método, no más de 10 • Número de desiciones por método, no más de 2 • Responsabilidades por objeto, solo deben hacer una sola cosa • Formato de código Métricas para medir calidad del código
- 17. ¿Cómo podemos mantenerun proyecto en buena salud?
- 18.
- 19. Readable, maintainable andextendable code Goal
- 20.
- 21.
- 22.
- 23. –Martin Fowler “A codesmell is a surface indication that usually corresponds to deeper problem in the system.”
- 24. – Kent Beck “Acode smell is a hint that something has gone wrong somewhere in your code. Use the smell to track down the problem.”
- 25. • No necesariamenteson Bugs • El código tecnicamente está correcto • No previenen al código actual de hacer su función • Síntoma de que pudiera existir areas que generan preocupaciones Code Smell
- 26. “Code smells simplementeindican fallas en el diseño que pueden alentar el desarrollo y mantenimiento de software.”
- 27. • No legible •Duplicado • Complejo • Difícil de modificar Código Malo
- 28. • Facil de: •Leer • Entender • Modificar Código bueno
- 29. Code Smells máscomunes
- 30. • Una solaclase tratando de hacer demasiado • Muy general, no aplican el principio de responsabilidad única • Solución: • Extraer la clase en funcionalidades aisladas • Extraer a subclases con polimorfismo Large Class
- 31.
- 32. • Heredado deprogramación procedural, utiliza todos los que ocupes! • Con POO, se reduce la necesidad • Solución • Pasar objetos en vez de parámetros • El objeto pasado es quien tiene toda información • Quien lo recibe usa solo la información necesaria Long Parameter List
- 33.
- 34. • Una clasecambia en diferentes maneras por diferentes razones • ¿Pareciera dos objetos en una sola clase? • Todos los cambios parecen ir a una sola clase? • Solución: • Extraer a otra clase Divergent Change
- 35. • Objetos debenempaquetar solo información usada por si mismos • Objetos muy interesados en datos o métodos de una clase externa en específico • Solución: • Mover metodos • Regresar objetos en vez de primitivos Feature Envy
- 36. Feature Envy class Warehouse defsale_price(item) item.final_price * @vat end end class Item def final_price price - rebate end end
- 37. • Algunos datosparecen ‘siempre ir’ juntos • Ejemplos: • Propiedades en clases • Mismos parametros en diferentes funciones • Solución • Extraer datos comunes en objetos • Objetos en parametros • Enviar el objeto completo en vez de dus propiedades Data Clumps
- 38. Data Clumbs class Dummy attr_reader:x1, :y1 def initialize(x1, y1) @x1 = x1 @y1 = y1 end def x ; x1 * y1 end def y ; x1 / y1 end def z ; x1 - y1 end end
- 39. • Codigo muyparecido en multiples lugares • Externamente no se parece, pero internamente si • Solución: • Utility classes • Herencia Duplicated Code
- 40.
- 41. • No escódigo ‘orientado a objetos” • Se debería usar polimorfismo en su lugar • Solución: • Switches representan un ‘tipo’ de código • Cada ‘tipo’ debería corresponder a una clase • Factory Pattern Switch statements
- 43. • ¿Pareciera quela clase no tiene porque estar ahi? • Se planearon cambios a esa clase pero no se necesitaron • Se encoge cuando se hace refactor • No pareciera valer la pena • Solución • ¿Utility class? Lazy Class
- 44. • No siempreson mala señal • No se usen como desodorante! • Refactor este tipo de smell generalmente termina en removiendo el código • Revisar si el comentario es necesario, si no, removerlo • Solución: • Comentar usando formatos estándar de documentación en linea • Agregar un TODO con criterios cuando se removera Comments
- 45. • Algo andamal • No se parece en nada, totalmente fuera de contexto • Solución: • Utility Class Black Sheep
- 47. • Generalmente semezclan abstracciones y llamadas • Ejecución de código procedural y llamadas a funciones • Solución • Estandarizar llamadas a funciones o código procedural Mixed levels of abstraction
- 48. Mixed levels ofabstraction
- 49. • Una nuevaimplementación involucra muchas modificaciones en diferentes lugares • Firmas de funciones se necesitan ser actualizadas • Difícil saber que tanto se necesita modificar • Solución • Abstraer llamadas en objetos • Si no se encuentra un buen lugar para mover los objetos, a crearlos! Shotgun Surgery
- 50. • Como sunombre lo indica, se usan boleanos como parámetros • Solución, eliminarlos desde la llamada Boolean Parameter
- 51.
- 52. • Variables deuso global • Difícil encontrar donde se inicializa el valor • Solución • Config classes • Singletons Class Variable
- 53. • Misma condicionalusada en multiples lugares • Causa de una mala implementación de polimorfismo • Solución: • Abstracción • Mejor Polimorfismo Repeated Conditional
- 54. • Acarreándose dediseño original • No se actualizaron firmas de las funciones • Solución • Remover el parametro y todas sus llamadas • Usar una convención para denotar los parámetros no usados _noUsado Unused parameters
- 55. • Se crearonmetodos privados que ya no se utilizan • Generan carga cognitiva • Causa de clases grandes • Solución • Eliminarlos Unused Private Methods
- 56. • Una funciónutilitaria es aquella que no necesita almacenar estados para generar resultados • Solución • Crear métodos estáticos Utility Function
- 57. • Escribir código •Asegurar pruebas verdes • Pedir revision • Aceptar comentarios y mejorar el código • Escoger el área más grave • Aplicar refactor Que debemos hacer
- 58. ¿Como saber pordonde empezar?
- 59.
- 66. • Presupuesto • Sino se hace desde un inicio, esta pidiendo un préstamo pagando lo mínimo • Refactor es abonar pagos al préstamo y bajar la tasa de interés • No invertir en refactor es aceptar irse al buró de crédito Se necesita tiempo para mantener buen código
- 67. • Linters • CI •Pruebas Tomemos ventaja de más código
- 68.
- 71.