Clase 7
7.png
refactoring2.JPG

Objetivos

En la clase anterior vimos cómo el proceso de refactorización se puede aplicar antes de agregar funcionalidad a una solución existente. Ahora veremos cómo incorporar agregados aprovechando el refactor previo y cómo podemos separar la actividad en:
1) hacer adaptaciones y agregados para contemplar nuevos casos o bien modificar la conducta del sistema (Expansión)
2) mejorar el nuevo código conservando la nueva funcionalidad intacta pero mejorando internamente el código para que sea más fácil de leer y de mantener (Refactorización).

Entonces vuelven a aparecer los dos momentos:

Expansión

  • El momento en que agrego funcionalidad. Qué agrego primero.
  • Método MoSCoW (Must, Should, Could, Would)
  • Buenas prácticas: KISS (Keep it simple), DRY (Don't repeat yourself) - Once and only once, YAGNI (You aren't gonna need it), etc.

Para la fase de expansión vamos a trabajar el enunciado con los cambios pedidos al ejercicio del Manejo de Proyectos, y cada uno va a exponer varias alternativas posibles para resolver el problema (hay que pensar modificaciones en código y diseño):

Lucas : Tareas simples y compuestas : Necesitamos hacer que sea fácil que una tarea simple sea compuesta y viceversa
Horacio : Impuestos : Ahora, además del impuesto A y el B, se debe contemplar impuestos C y D
Paula : Recursos : contemplar recursos a una tarea
Artëm : Unidades de tiempo de una tarea

Yo (Fernando) expondré el agregado de hitos que es interesante en cuanto a posibilidades.

Refactorización

  • qué es: introducir mejoras en el código para que sea más entendible y fácil de modificar.
  • Separar los momentos en los que agrego funcionalidad vs. mejoro el código
  • Refactorizar vs. optimizar
  • Refactorización y testeo automatizado
  • Cuándo refactorizar: "bad smells"

Qué tengo que llevar impreso

Material complementario

Links

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License