Clean code: Amortizando la deuda técnica

CLEAN CODEAmortizando la deuda técnica

Sebastian Castillo @secaro89

¿Quién ha dicho alguna vez: este código es una p*** mierda?


¿Quién ha dicho alguna vez: esto hay que tirarlo y hacerlo desde cero?


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.


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


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.


INVERSIÓN

Hacer código

...más limpio

...con test

...con documentación

...me costará másFALSO!

DEUDA TÉCNICA

APLAZAR COSTES

DEUDA + INTERESES


“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


La regla de Boy Scout

“Dejar el campamento más limpio de lo que se ha encontrado”


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


La teoría está muy bien pero…

¿qué hacemos?


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


ANALIZAR IMPLEMENTAR TEST ¿MEJORABLE?

REFACTORIZAR

DESACOPLAR

REDUCIR TAMAÑO

RENOMBRAR

ELIMINAR DUPLICADOS

MEJORAR EXPRESIVIDAD

REUTILIZAR

CALIDAD

CALIDAD - SONAR


CALIDAD - PMD


CALIDAD - FORMATTER


NOMENCLATURA

1 - Usar nombres que revelen las intenciones

for(String st: list){

(...)}

for(String numeroCuenta: cuentasUsuario){

(...)}


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(...)


FUNCIONES

1 - Tamaño reducido

public Account getAccount(String id){ (...) [600 líneas]}


public Account getAccount(String id){ validarAccountId(id); return invocarTx(id); }

FUNCIONES

2 - Single Responsability


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


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


public List<UsuarioGestionDTO> listarUsuarios (..., Boolean isCompass);

public List<UsuarioGestionDTO> listarUsuarios (...);

public List<UsuarioGestionDTO> listarUsuariosCompass (...);

FUNCIONES

5 - Mejor excepciones que devolver códigos de error


public int comprobarClaveUsuario(...){ int error = 0; (...) return error;}

public void comprobarClaveUsuario(...) throws MyException{ (...)}

FUNCIONES

6 - No devolver null; no pasar null


public List<DatosUsuario> getDatosUsuario(String id, …, null){

(...) return null;}

public List<DatosUsuario> getDatosUsuario(String id, …){

(...) return Collections.emptyList();}

COMENTARIOS

1 - (Intentar) Eliminar comentarios


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


public class DatosUsuario {

String codEmpresa; public getCodEmpresa() { return codEmpresa; }

public formatearTelefono(String tlf) { }}

Spring AOP

Programación Orientada a Aspectos


@RooJavaBean@RooToString Spring Roo@RooSerializable

@HttpClient@HttpInvoker Arquitectura Spring@Transaccion

@GETMock@PUTMock KYGU@UPDATEMock

● Separar intenciones

● Reduce el acoplamiento

● Código más limpio

GRACIAS!!

Clean code: Amortizando la deuda técnica

Software

Transcript of Clean code: Amortizando la deuda técnica