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

2. Felipe Talavera Armero
twitter || github => flype
hello@iamfelipe.com

3. Rails ya no es un
pubertario,
empieza su edad
"adulta"

5. Cada vez hay mas apps
escritas en rails :)

6. Son ya ~5 años
escribiendo código

7. Muchas generan
mucho (valor || €€) a
sus propietarios

8. La mayoría están
escritas con versiones
antiguas de rails

9. ¡Todas necesitan amor!

10. ¿Qué es el código legacy?

11. ¿Qué opinais vosotros?

12. “Code written > 3 months
or by someone else”
“Code dificult to change”

13. “Code you wrote when weren’t
as good as you are now”
by DHH

14. “Code without tests”
by Michael Feathers

15. “Acummulated technical debt”
by Ward Cunningham

16. ¿Qué es la deuda técnica?

17. Deuda Técnica
por 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.

19. Muchas maneras de incurrir en ella

20. metáfora que los
manager entienden,
¡los necesitamos en
este barco!

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

22. Frena el desarrollo
Aparecen mas bugs
Se retrasan los plazos
Crece la frustración

23. mejor pagarla poco a poco

24. Testing y refactorización
como modo de vida
(TAFT & RAFT)

26. básicamente:
Nuestro código tiene que ser :
mantenible
legible
entendible
osea:
facil de modificar

27. Si no pagamos...

29. consecuencia

31. 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...

32. Detectar olores
Ruby o Rails
sugieren problemas
futuros atajarlos a
tiempo ayuda

33. en ruby:
duplicación
métodos muy largos
muchos parámetros en métodos
case statements
acoplamiento
ley de demeter (LoD)
...

34. recordar chicos:
Ruby muy flexible, todo el
control está en manos del programador
"With great power comes great responsibility."

35. en rails:
No a la rails way
Violaciones del MVC
mucho código en controllares
poco código en los modelos
poco uso de plugins

36. Si todo lo anterior ha fallado

37. ¿Re-escribir o Refactorizar?

38. ¿ Has deseado tirar
todo y empezar de
nuevo ?

39. Reescribir a veces no
es buena idea.

40. En realidad pocas veces
es buena idea.
¿ Por qué ?

41. A veces no tenemos
todo el conocimiento
de la app.

42. El problema parace, más
sencillo desde fuera y
creemos que podemos
hacerlo mejor

43. Perderemos todo el
conocimiento adquirido
de los bugs solucionados

44. Decidimos re-escribir
¿Por donde empiezo?

45. Nuevo proyecto e ir
moviendo funcionalidad
Mejor con algo de testing, ¿no?
nivel funcional o de integración
De afuera hacia dentro, ¿cucumber?

46. Preparemonos para
la gran refactorización

47. necesitamos tener una
buena red de seguridad

48. Normalmente inviable
PARAR el desarrollo y
empezar a testear todo

49. vayamos despacito

51. no empezar a rescribir por reescribir
Limpia y testea solo el código
con el que te vayas cruzando
mientras añadas nuevas
funcionalidades

52. Saca métricas y apóyate
en ellas para ver por
dónde comenzar
metric_fu, flog, rcov, saikuru ...

53. y paciencia, poquito a
poquito se puede
conseguir mucho

54. plugins útiles
• Inherited_resources
• resources_controller
• partial_dependencies
• noisy_partials
• metric_fu

55. Bibliografía:

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