clean code: amortizando la deuda técnica
TRANSCRIPT
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
EJEMPLOS DE DEUDA TÉCNICA
CONSECUENCIAS
Código duplicadoCódigo sucioCódigo espaguetiEscasez/inexistencia de pruebasEscasez/inexistencia de documentaciónProyectos favelas
CAUSAS
Código heredado
Prisas
Presión de fechas de entrega
Desconocimiento
Carencia de obligación/rutina
Sebastian Castillo @secaro89
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
INVERSIÓN
Hacer código
...más limpio
...con test
...con documentación
...me costará másFALSO!
DEUDA TÉCNICA
APLAZAR COSTES
DEUDA + INTERESES
Sebastian Castillo @secaro89
“El mayor coste de un proyecto de software es su mantenimiento a largo plazo”
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
La regla de Boy Scout
“Dejar el campamento más limpio de lo que se ha encontrado”
Sebastian Castillo @secaro89
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
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 SoftwareSebastian Castillo @secaro89
DESARROLLOS
Sebastian Castillo @secaro89
ANALIZAR IMPLEMENTAR TEST ¿MEJORABLE?
REFACTORIZAR
DESACOPLAR
REDUCIR TAMAÑO
RENOMBRAR
ELIMINAR DUPLICADOS
MEJORAR EXPRESIVIDAD
REUTILIZAR
CALIDAD
NOMENCLATURA
1 - Usar nombres que revelen las intenciones
for(String st: list){
(...)}
for(String numeroCuenta: cuentasUsuario){
(...)}
Sebastian Castillo @secaro89
NOMENCLATURA
2 - Usar sustantivos para clases, verbos para métodos
CustomerInfo.javaCustomerData.javaAccountProcessor.javaAccountManager.java
obtenerCuenta(...)listarAccounts(...)filtrarCuentas(...)
Customer.java Account.java
setAccount(...);getAccount();isValidAccount(...)
Sebastian Castillo @secaro89
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); }
FUNCIONES
2 - Single Responsability
Sebastian Castillo @secaro89
public GestionUsuariosForm generarInforme(...){ final RespuestaEmpresaType empresaRespuesta = informacionEmpresa.consultarEmpresaBasica(...); (...) exportarFichero(empresaRespuesta, …);}
public GestionUsuariosForm generarInforme(RespuestaEmpresaType empresa, ...){ (...) exportarFichero(empresaRespuesta, …);}
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);
FUNCIONES
4 - Evitar flags como argumentos
Sebastian Castillo @secaro89
public List<UsuarioGestionDTO> listarUsuarios (..., Boolean isCompass);
public List<UsuarioGestionDTO> listarUsuarios (...);
public List<UsuarioGestionDTO> listarUsuariosCompass (...);
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{ (...)}
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();}
COMENTARIOS
1 - (Intentar) Eliminar comentarios
Sebastian Castillo @secaro89
Funciones pequeñasNombre descriptivoJavadoc (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.
CLASES
1 - Tamaño reducido & Single Responsability2 - Cohesión
Sebastian Castillo @secaro89
public class DatosUsuario {
String codEmpresa; public getCodEmpresa() { return codEmpresa; }
public formatearTelefono(String tlf) { }}
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