Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Clean code: Amortizando la deuda técnica

289 views

Published on

¿Qué es la deuda técnica? Como amortizarla y pequeños casos prácticos

Published in: Software
  • Be the first to comment

Clean code: Amortizando la deuda técnica

  1. 1. CLEAN CODE Amortizando la deuda técnica Sebastian Castillo @secaro89
  2. 2. ¿Quién ha dicho alguna vez: este código es una p*** mierda? Sebastian Castillo @secaro89
  3. 3. ¿Quién ha dicho alguna vez: esto hay que tirarlo y hacerlo desde cero? Sebastian Castillo @secaro89
  4. 4. DEUDA TÉCNICA, ¿QUÉ ES? La deuda técnica hace referencia a las consecuencias de un desarrollo pobre. Es la deuda que asumimos cuando descuidamos la calidad de nuestros desarrollos. Sebastian Castillo @secaro89
  5. 5. EJEMPLOS DE DEUDA TÉCNICA CONSECUENCIAS Código duplicado Código sucio Código espagueti Escasez/inexistencia de pruebas Escasez/inexistencia de documentación Proyectos favelas CAUSAS Código heredado Prisas Presión de fechas de entrega Desconocimiento Carencia de obligación/rutina Sebastian Castillo @secaro89
  6. 6. INTERÉS DE LA DEUDA TÉCNICA Sobreesfuerzos del equipo para el mantenimiento y la evolución del proyecto. Mala imagen. Malestar y estrés del equipo. Sebastian Castillo @secaro89
  7. 7. INVERSIÓN Hacer código ...más limpio ...con test ...con documentación ...me costará más FALSO! DEUDA TÉCNICA APLAZAR COSTES DEUDA + INTERESES Sebastian Castillo @secaro89 “El mayor coste de un proyecto de software es su mantenimiento a largo plazo”
  8. 8. OBJETIVO ELIMINAR LA DEUDA TÉCNICA (AMORTIZACIÓN TOTAL) UTOPÍA REDUCIR LA DEUDA TÉCNICA (AMORTIZACIÓN PARCIAL) REGLA DEL BOY SCOUT Sebastian Castillo @secaro89
  9. 9. La regla de Boy Scout “Dejar el campamento más limpio de lo que se ha encontrado” Sebastian Castillo @secaro89
  10. 10. VENTAJAS Seremos mejores profesionales. Desarrollaremos mejor código: más limpio y más fiable. Seremos más rápidos. Gracias a la mantenibilidad del proyecto y la facilidad para entender y reutilizar parte del código desarrollaremos más rápido. Seremos más ágiles. Fallaremos menos y solucionaremos más rápido. Seremos más felices. Viviremos más tranquilos ante entregas y evolutivos Sebastian Castillo @secaro89
  11. 11. La teoría está muy bien pero… ¿qué hacemos? Sebastian Castillo @secaro89
  12. 12. PASOS PREVIOS 1. Concienciar y motivar el equipo 2. Establecer herramientas a nuestra rutina. 3. Medir. ¿Cuán mal estamos? 4. Añadir requisitos de calidad al DoD (definition of done): a. Cobertura de test b. Ejecución de test c. Calidad de Software Sebastian Castillo @secaro89
  13. 13. DESARROLLOS Sebastian Castillo @secaro89 ANALIZAR IMPLEMENTAR TEST ¿MEJORABLE? REFACTORIZAR DESACOPLAR REDUCIR TAMAÑO RENOMBRAR ELIMINAR DUPLICADOS MEJORAR EXPRESIVIDAD REUTILIZAR CALIDAD
  14. 14. CALIDAD - SONAR Sebastian Castillo @secaro89
  15. 15. CALIDAD - SONAR Sebastian Castillo @secaro89
  16. 16. CALIDAD - PMD Sebastian Castillo @secaro89
  17. 17. CALIDAD - FORMATTER Sebastian Castillo @secaro89
  18. 18. Sebastian Castillo @secaro89
  19. 19. NOMENCLATURA 1 - Usar nombres que revelen las intenciones for(String st: list) { (...) } for(String numeroCuenta: cuentasUsuario) { (...) } Sebastian Castillo @secaro89
  20. 20. NOMENCLATURA 2 - Usar sustantivos para clases, verbos para métodos CustomerInfo.java CustomerData.java AccountProcessor.java AccountManager.java obtenerCuenta(...) listarAccounts(...) filtrarCuentas(...) Customer.java Account.java setAccount(...); getAccount(); isValidAccount(...) Sebastian Castillo @secaro89
  21. 21. FUNCIONES 1 - Tamaño reducido public Account getAccount(String id) { (...) [600 líneas] } Sebastian Castillo @secaro89 public Account getAccount(String id) { validarAccountId(id); return invocarTx(id); }
  22. 22. FUNCIONES 2 - Single Responsability Sebastian Castillo @secaro89 public GestionUsuariosForm generarInforme(...) { final RespuestaEmpresaType empresaRespuesta = informacionEmpresa.consultarEmpresaBasica(...); (...) exportarFichero(empresaRespuesta, …); } public GestionUsuariosForm generarInforme(RespuestaEmpresaType empresa, ...) { (...) exportarFichero(empresaRespuesta, …); }
  23. 23. FUNCIONES 3 - Número máximo de argumentos Sebastian Castillo @secaro89 public List<EmpresaRelacionadaDTO> listarRelProdEmpresaDTO (Integer canal, String referencia, Integer bancoInt, Integer bancoPr, Integer producto, Integer subProducto, Integer canalRel, String referenciaRel, Integer bancoIntRel, Integer bancoPrRel, Integer productoRel, Integer subProductoRel, String codUsuarioAdmin); public List<EmpresaRelacionadaDTO> listarRelProdEmpresaDTO (DatosEmpresa datosEmpresa, DatosEmpresa datosEmpresaRel, String codUsuarioAdmin);
  24. 24. FUNCIONES 4 - Evitar flags como argumentos Sebastian Castillo @secaro89 public List<UsuarioGestionDTO> listarUsuarios (..., Boolean isCompass); public List<UsuarioGestionDTO> listarUsuarios (...); public List<UsuarioGestionDTO> listarUsuariosCompass (...);
  25. 25. FUNCIONES 5 - Mejor excepciones que devolver códigos de error Sebastian Castillo @secaro89 public int comprobarClaveUsuario(...){ int error = 0; (...) return error; } public void comprobarClaveUsuario(...) throws MyException{ (...) }
  26. 26. FUNCIONES 6 - No devolver null; no pasar null Sebastian Castillo @secaro89 public List<DatosUsuario> getDatosUsuario(String id, …, null){ (...) return null; } public List<DatosUsuario> getDatosUsuario(String id, …){ (...) return Collections.emptyList(); }
  27. 27. COMENTARIOS 1 - (Intentar) Eliminar comentarios Sebastian Castillo @secaro89 Funciones pequeñas Nombre descriptivo Javadoc (public) Comentarios no deberían aportar Casos en que los comentarios pueden resultar útiles: ● Explicar código que, por su formato, no son suficientemente claros (p.e exp. regulares) ● Advertir consecuencias de la ejecución de un método. (p.e Un test que persiste datos) ● Comentarios TODO, muy útiles para documentar deuda técnica.
  28. 28. CLASES 1 - Tamaño reducido & Single Responsability 2 - Cohesión Sebastian Castillo @secaro89 public class DatosUsuario { String codEmpresa; public getCodEmpresa() { return codEmpresa; } public formatearTelefono(String tlf) { } }
  29. 29. Spring AOP Programación Orientada a Aspectos Sebastian Castillo @secaro89 @RooJavaBean @RooToString Spring Roo @RooSerializable @HttpClient @HttpInvoker Arquitectura Spring @Transaccion @GETMock @PUTMock KYGU @UPDATEMock ● Separar intenciones ● Reduce el acoplamiento ● Código más limpio
  30. 30. GRACIAS!!

×