legacy

¡Mejor prevenir que curar!Lidiando con código legacy en rails

Felipe Talavera Armero

hello@iamfelipe.com

twitter || github => flype

Rails ya no es un pubertario,

empieza su edad "adulta"

Cada vez hay mas apps escritas en rails :)

Son ya ~5 años escribiendo código

Muchas generan mucho (valor || €€) a

sus propietarios

La mayoría están escritas con versiones

antiguas de rails

¡Todas necesitan amor! ¡Todas necesitan amor!

¿Qué es el código legacy?

¿Qué opinais vosotros?

“Code written > 3 months or by someone else”

“Code dificult to change”

“Code you wrote when weren’t as good as you are now”

by DHH

“Code without tests”by Michael Feathers

“Acummulated technical debt”by Ward Cunningham

¿Qué es la deuda técnica?

Deuda Técnicapor Ward Cunningham

Asumimos que cada vez que implementamos algo de manera “hacky” estamos incrementando una deuda técnica que como las fiscales pagaremos más cuanto

más tardemos en saldar.

Muchas maneras de incurrir en ella

metáfora que los manager entienden,

¡los necesitamos en este barco!

http://blog.hasmanythrough.com/2009/9/3/circle-of-death

Frena el desarrolloAparecen mas bugs

Se retrasan los plazos Crece la frustración

mejor pagarla poco a poco

Testing y refactorización como modo de vida

(TAFT & RAFT)

básicamente: Nuestro código tiene que ser :

mantenible legible

entendible

osea: facil de modificar

Si no pagamos...

consecuencia

Ventanas Rotas

"Consideren un edificio con una ventana rota. Si la ventana no se repara, los vándalos tenderán a romper unas cuantas

ventanas más. Finalmente, quizás hasta irrumpan en el edificio, y si está abandonado, es posible que sea ocupado

por ellos o que prendan fuegos adentro...

Detectar olores Ruby o Rails

sugieren problemas futuros atajarlos a

tiempo ayuda

en ruby:duplicación

métodos muy largosmuchos parámetros en métodos

case statementsacoplamiento

ley de demeter (LoD)...

recordar chicos:

Ruby muy flexible, todo el control está en manos del programador

"With great power comes great responsibility."

en rails:

No a la rails wayViolaciones del MVC

mucho código en controllarespoco código en los modelos

poco uso de plugins

Si todo lo anterior ha fallado

¿Re-escribir o Refactorizar?

¿ Has deseado tirar todo y empezar de

nuevo ?

Reescribir a veces no es buena idea.

En realidad pocas veces es buena idea.

¿ Por qué ?

A veces no tenemos todo el conocimiento

de la app.

El problema parace, más sencillo desde fuera y

creemos que podemos hacerlo mejor

Perderemos todo el conocimiento adquirido de los bugs solucionados

Decidimos re-escribir¿Por donde empiezo?

Nuevo proyecto e ir moviendo funcionalidad

Mejor con algo de testing, ¿no?

nivel funcional o de integración

De afuera hacia dentro, ¿cucumber?

Preparemonos para

la gran refactorización

necesitamos tener una buena red de seguridad

Normalmente inviable PARAR el desarrollo y empezar a testear todo

vayamos despacito

no empezar a rescribir por reescribir

Limpia y testea solo el código con el que te vayas cruzando

mientras añadas nuevas funcionalidades

Saca métricas y apóyate en ellas para ver por

dónde comenzar

metric_fu, flog, rcov, saikuru ...

y paciencia, poquito a poquito se puede conseguir mucho

plugins útiles

• Inherited_resources

• resources_controller

• partial_dependencies

• noisy_partials

• metric_fu

Bibliografía:

¡Mejor prevenir que currar...... de mas!