Lagash Systems Mariano Sánchez – Software Architect

Presentación del tema: "Lagash Systems Mariano Sánchez – Software Architect"— Transcripción de la presentación:

1 Lagash Systems Mariano Sánchez – Software Architect
@marianosz

2 Code Smells & Refactoring

3 Que son los Code Smells? Wikipedia: En Criollo:
Un “Code Smell” es un síntoma que encontramos en el código que posiblemente indica un problema más profundo. En Criollo: Son “warnings” que aparecen al revisar el código, que nos puede guiar para encontrar errores de diseño o implementación.

4 Y que hago cuando lo encuentro?
Refactoring: Es el proceso de mejorar la calidad del código fuente sin alterar su funcionalidad. Existe un catalogo de Code Smells, el cual plantea las opciones de Refactoring para eliminarlo. Pero… no hay una receta mágica, solo guías. Es fundamental el criterio del desarrollador. Para aplicar los Refactorings se deben crear los Test necesarios para asegurarnos que no vamos a romper nada, y luego realizar los cambios paso a paso.

5 Code Smells - Clasificación

6 Code Smells - Clasificación
The Bloaters: Agrupa smells que indican la existencia de algún aspecto que con el tiempo y el crecimiento pueden volver incontrolable el código. The Object Orientation Abusers: El común denominador de este tipo de smells es que representan casos donde la solución no explota completamente las posibilidades del diseño orientado a objetos.

7 Code Smells - Clasificación
The Change Preventers: Estos smells dificultan la posibilidad de realizar cambios en nuestro software o de simplemente seguir avanzando en el desarrollo. Violan la regla sugerida por Fowler y Beck, que dice que las clases y los posibles cambios deben tener una relación de uno a uno. The Dispensables: Estos Smells tienen en común la existencia de algún elemento innecesario que debería ser removido del código fuente. The Couplers: Son smells que alertan sobre problemas en el manejo del acoplamiento entre componentes, pudiendo ser este excesivo y o mal diseñado.

8 Bloaters

9 Code Smells - Bloaters Long Methods Large Class
Los métodos largos son mas difíciles de leer, de entender y sobre todo de depurar. Mantener los métodos con pocas líneas ayuda a poder evitar este problema. Si ya tenemos métodos largos podemos considerar separarlos en métodos mas pequeños. Large Class Similar a los métodos largos también son difíciles de leer, entender y depurar. Además las clases grandes muestran otros problemas, como por ejemplo que una única clase contiene demasiadas responsabilidades.

10 Code Smells - Bloaters Primitive Obsession Long Parameter List
No utilizar una set de variables de tipos primitivos como un substituto simple para una clase. Si el tipo de datos es lo suficientemente complejo, escribir una clase para que lo represente.  Long Parameter List Cuantos mas parámetros reciba un método mas complejo se vuelve de entender y utilizar. Para evitar esto podemos mantener la baja cantidad de parámetros que recibe un método o considerar crear una clase o estructura para pasar estos valores.

11 Code Smells - Bloaters Data Clumps
Si siempre vemos que la misma informacionviaja todo el tiempo junta, es muy probable que esos datos sueltos pertenezcan a una misma clase. Considerar integrarlos en la clase que corresponda.

12 OO Abusers

13 Code Smells – OO Abusers
Switch Statement Que podrían indicar una falta de utilización de mecanismos de herencia. Temporary Field Estar atentos a los objetos que contenga muchos campos opcionales o innecesarios. Si estamos usando un objeto como parámetro de un método asegurarnos que se use todo de el.

14 Code Smells – OO Abusers
Refused Bequest Si heredamos de una clase, pero no utilizamos ninguna funcionalidad, para que vamos a mantener esa herencia? Alternative Classes with Different Interfaces Si dos clases son similares en el interior, pero difieren en el exterior, es probable que se puedan modificar para compartir una interfaz común.

15 Code Smells – OO Abusers
Conditional Complexity Tener cuidado al detectar o utilizar bloques condicionales muy largos, particularmente los que tienden a crecer con cada cambio que se introduce. Considerar una alternativa orientada a objetos como el uso de un patrón Decorator, Strategy, o State.

16 Change Preventers

17 Code Smells – Change Preventers
Divergent Change Si a través del tiempo, los cambios en una clase necesitan que se toquen muchas partes diferentes de esta, es probable que la clase contenga funcionalidad que no esta relacionada. Considerar isolar las distintas partes en clases diferentes. Shotgun Surgery Si un cambio en una clase requiere cambios en cascada en muchas otras clases, seguramente nos encontramos en una situación donde una funcionalidad esta mal distribuida.

18 Code Smells – Change Preventers
Parallel Inheritance Hierarchies Cada vez que se realiza una subclase de una clase, se tiene que hacer una sublclase de otra. Considerar unir la jerarquía en una sola clase. Combinatorial Explosion Aparece cuando existe mucho código que hace casi lo mismo, pero con pequeñas variaciones en la Data o el comportamiento. Generalmente esto es complicado de refactorizar y corregir. Se podría evitar utilizando generics o el patron Template Method.

19 Code Smells – Change Preventers
Magic Number Valores que aparecen de la nada y se usan para realizar operaciones.

20 Dispensables

21 Code Smells - Dispensables
Lazy Class Si una clase hace poco y nada, debería eliminarse o combinarse con otra clase. Data Class Evitar clases que solamente almacenen información. Las clases deberían contener información y métodos para operar sobre esta.

22 Code Smells - Dispensables
Duplicated code El código duplicado es la peor anti-practica en el desarrollo de software. Eliminar la duplicación siempre que sea posible y estar siempre atento a los casos más sutiles de casi duplicación. Don't Repeat Yourself! Dead Code Eliminar código que no se utilice. Para eso tenemos sistemas de control de código fuente!

23 Code Smells - Dispensables
Speculative Generality EL código que escribimos HOY tiene que ser para resolver los problemas que tenemos HOY. No nos preocupemos por el mañana. You (Probably) Aren't Gonna Need It. Comments Hay una línea muy fina entre los comentarios que iluminan y los que oscurecen. Son necesarios? Se puede refactorizar el código para no se necesiten?

24 Couplers

25 Code Smells - Couplers Feature Envy Inappropriate Intimacy
Métodos que realizan un uso extensivo de otra clase, probablemente deberían pertenecer a la otra clase. Deberíamos considerar mover estos métodos a la clase que corresponda. Inappropriate Intimacy Estar atentos a las clases que pasan mucho tiempo juntas o que interfacean de modos inapropiados. Las clases deberían conocer lo menos posible unas de otras.

26 Code Smells - Couplers Indecent Exposure Message Chains
Cuidado con las clases que exponen innecesariamente su interior. Refactorizar clases para minimizar su interfaz pública. Debe existir una razón de peso para que cada metodo, evento o propiedad que sea pública. Si no existe hay que ocultarlo. Message Chains Atentos a las secuencias de llamadas ,posiblemente entre clases, a métodos o variables temporales para obtener datos de rutina. Cualquier intermediario es una dependencia disfrazadas.

27 Code Smells - Couplers Middle Man Solution Sprawl
Si una clase está delegando todo su trabajo, ¿para qué existe? Elimiar todos los intermediarios. Atencion a las clases que son meramente wrappers sin agregar funcionalidades al framework o contexto. Solution Sprawl Si se necesitan cinco clases para hacer algo útil, es posible que aparezca este smell. Considerar la simplificación y la consolidación del diseño.

28 Extras

29 Code Smells - Extras Type embedded in name Uncommunicative Name
Evite colocar los nombres de los tipos en las firmas de métodos o propiedades, no es sólo redundante, sino que ademas obliga a cambiar el nombre si se le cambia el tipo. Uncommunicative Name El nombre del método describe lo que hace el método? Puede otro desarrollador leer el nombre del método y entender lo que hace? Si no es así, cambiar el nombre o reescribir el método.

30 Code Smells - Extras Inconsistent Names Oddball Solution
Elegir una terminología normalizada y apegarse a ella para nombrar los métodos. Por ejemplo, si nuestra API tiene un Open(), debería tener Close(). Oddball Solution Sólo debe haber una manera de resolver el mismo problema. Si se encuentra mas de una solución, podría ser un caso de código duplicado o una mala interpretación del problema.

31 Refactoring

32 Refactoring Refactoring es:
La restructuración del código en una serie de pequeños pasos, preservando la funcionalidad, con el objetivo de hacerlo mas fácil de entender y modificar Pero no es una simple reestructuración arbitraria del código El código debe seguir funcionando Solo realizando pequeños pasos (no es un major re-write) Unit tests, necesarios para asegurarnos que siga funcionando Finalmente el Código resultante es Menos acoplado Más cohesivo Más comprensible

33 Refactoring Existen una lista de técnicas de refactoring conocidas
Catalogo de Refactorings Es importante que estemos familiarizados el catalogo antes de inventar nuestros propios refactorings

34 Hacer Refactoring Deberíamos hacer refactoring:
En cualquier momento que detectemos que hay una mejor forma de hacer las cosas. (por ejemplo detecciòn de Code Smell) “Mejor” significa hacer código mas fácil de entender y modificar en el futuro Cuanto el entorno puede soportar Refactoring Cuando lo podemos hacer sin romper el código Unit tests => Esenciales para esto No deberíamos hacer refactoring: Código estable que no necesita cambiar Código realizado por otra persona A menos que la otra persona este de acuerdo

35 Proceso de Refactoring
Hacer un pequeño cambio Un único Refactoring Correr todos los tests para asegurarnos que todo sigue funcionando Si todo funciona puedo continuar con el siguiente Refactoring Si no, solucionar el problema o deshacer el cambio para asegurarnos que tengamos un sistema funcionando

36 Code Smells Si apesta, cambialo!! Ejempos:
Apesta = Codigo que hace que el diseño se vuelva dificil de entender o cambiar Ejempos: Duplicate code Long methods Big classes Big switch statements Long navigations (Ej., a.b().c().d()) Lots of checking for null objects Data clumps (Ej: clase Contacto con fields para direccion, telefono, , etc.) - similar a tablas no normalizadas en un diseño relacional) Data classes (Clases con principalmente fields/properties y pocoso o nulos metodos) Un-encapsulated fields (public member variables)

37 Ejemplo 1: Switch statements
Los Switch statements son muy raros en el código orientado a objetos bien diseñado Entonces, un switch es fácilmente detectable como un “smell” Obviamente no todos los Switch son malos Existen varios refactorings diseñados para este caso El más simple es la creación de subclases

38 Ejemplo 1, continuado class Animal { final int MAMMAL = 0, BIRD = 1, REPTILE = 2; int myKind; // set in constructor String getSkin() { switch (myKind) { case MAMMAL: return "hair"; case BIRD: return "feathers"; case REPTILE: return "scales"; default: return “skin"; } } }

39 Ejemplo 1, mejorado class Animal { String getSkin() { return “skin"; } } class Mammal extends Animal { String getSkin() { return "hair"; } } class Bird extends Animal { String getSkin() { return "feathers"; } } class Reptile extends Animal { String getSkin() { return "scales"; } }

40 Porque es una mejora? Agregar un nuevo tipo de animal, como por ejemplo Amphibian, no requiere revisar y recompilar el código existente. Mammals, birds y reptiles pueden diferir en otras formas, y ya los tenemos separados, por lo tanto no vamos a necesitar mas switchs para futuras funcionalidades. Eliminamos todos los flags que se usaban para poder diferenciar los animales. Ahora estamos usando Objetos de la manera en que están pensados para ser usados

41 2. Encapsulate Field Miembros no encapsuladaos es un no-no en diseño OO. Usar properties (get y set ) para proveer el acceso publico a miembros privados (encapsulados) public class Course { private List students; public List getStudents() return students; } public void setStudents(List s) students = s; public class Course { public List students; } int classSize = course.students.size(); int classSize = course.getStudents().size();

42 3. Extract Class Separar una clase en dos, dividiendo las responsabilidades según corresponda. public class Customer { private String name; private Phone workPhone; } public class Phone private String areaCode; private String number; public class Customer { private String name; private String workPhoneAreaCode; private String workPhoneNumber; }

43 4. Extract Interface Extraer una interface de una clase, ayudando a reducir el acoplamiento y permitiendo realizar un manejo generico de clases de distinto tipo pero con la misma interfaz. public class Customer implements SerXML { private String name; public String getName(){ return name; } public void setName(String string) { name = string; } public String toXML() { return "<Customer><Name>" + name + "</Name></Customer>"; } public class Customer { private String name; public String getName(){ return name; } public void setName(String string) { name = string; } public String toXML() { return "<Customer><Name>" + name + "</Name></Customer>"; } public interface SerXml { public abstract String toXML(); }

44 5. Extract Method Hay momentos donde tenemos métodos que hacen demasiadas cosas. Cuanto mas código tenemos en un único método, mas difícil es de entenderlo bien. Además esto significa que la lógica embebida en un método no puede ser reutilizado. Extract Method es el refactoring mas usado para reducir la duplicación de código public class Customer { void int foo() … score = ComputeScore(a,b,c,xfactor); } int ComputeScore(int a, int b, int c, int x) return (a*b+c)*x; public class Customer { void int foo() … // Compute score score = a*b+c; score *= xfactor; }

45 6. Extract Subclass Cuando una clase tiene features (atributos y métodos) que solo se van a utilizar en algunas instancias especializadas, podemos crear una clase para esa especialización. Esto hace que la clase sea menos especializada, y en el caso de necesitar esa especialización la puede obtener por mecanismos de herencia. public class Person { protected String name; } public class Employee extends Person private String jobTitle; public class Person { private String name; private String jobTitle; }

46 7. Extract Super Class Cuando encontramos dos o mas clases que comparten features comunes, considerar abstraer esos features en una súper clase, ayudando a mejorar el diseño y eliminar código duplicado public abstract class Person { protected String name; } public class Employee extends Person private String jobTitle; public class Student extends Person private Course course; public class Employee { private String name; private String jobTitle; } public class Student private Course course;

47 8. Form Template Method - Antes
Cuando existen métodos en subclases que realizan los mismos pasos, pero hacen diferentes cosas en cada paso, crear métodos para los pasos y mantenerlos en la clase base, implementándolos en las subclases public class Company extends Party { private String name; private String companyType; private Date incorporated; public void PrintNameAndDetails() System.out.println("Name: " + name + " " + companyType); System.out.println("Incorporated: " + incorporated.toString()); } public abstract class Party { } public class Person extends Party { private String firstName; private String lastName; private Date dob; private String nationality; public void printNameAndDetails() System.out.println("Name: " + firstName + " " + lastName); System.out.println("DOB: " + dob.toString() + ", Nationality: " + nationality); }

48 Form Template Method - Refactorizado
public abstract class Party public void PrintNameAndDetails() { printName(); printDetails(); } public abstract void printName(); public abstract void printDetails(); public class Person extends Party private String firstName; private String lastName; private Date dob; private String nationality; public void printDetails() System.out.println("DOB: " + dob.toString() + ", Nationality: " + nationality); public void printName() System.out.println("Name: " + firstName + " " + lastName); public class Company extends Party { private String name; private String companyType; private Date incorporated; public void printDetails() System.out.println("Incorporated: " + incorporated.toString()); } public void printName() System.out.println("Name: " + name + " " + companyType);

49 9. Move Method Si un método en una clase, usa o es usado por otra clase mas que en la que esta definida, moverlo a la otra clase, haciendo que el diseño sea mas cohesivo y menos acoplado public class Student { public boolean isTaking(Course course) return (course.getStudents().contains(this)); } public class Course private List students; public List getStudents() return students; public class Student { } public class Course private List students; public boolean isTaking(Student student) return students.contains(student);

50 10. Introduce Null Object Utilizar Null Object para mejorar el manejo de nulos public class User { Plan getPlan() return plan; } public class NullUser extends User return Plan.basic(); public class User { Plan getPlan() return plan; } if (user == null) plan = Plan.basic(); else plan = user.getPlan();

51 11. Replace Error Code with Exception
Si un método retorna un código de error especial para indicar un error, esto puede ser reemplazado con una Exception. void withdraw(int amount) throws BalanceException { if (amount > balance) throw new BalanceException(); } balance -= amount; int withdraw(int amount) { if (amount > balance) return -1; else { balance -= amount; return 0; }

52 12. Replace Exception with Test
Si estamos capturando una Exception que puede ser manejada con un if-statement, es preferible utilizarlo en lugar de la Exception. double getValueForPeriod (int periodNumber) { try return values[periodNumber]; } catch (ArrayIndexOutOfBoundsException e) return 0; double getValueForPeriod (int periodNumber) { if (periodNumber >= values.length) return 0; return values[periodNumber]; }

53 13. Nested Conditional with Guard
Si un método tiene un comportamiento condicional que no muestra claramente como esta tomando las decisiones y cual es el path que sigue una ejecución, usar Guard Clauses para mejorar el entendimiento del flujo. double getPayAmount() { double result; if (isDead) result = deadAmount(); else { if (isSeparated) result = separatedAmount(); if (isRetired) result = retiredAmount(); else result = normalPayAmount(); } return result; double getPayAmount() { if (isDead) return deadAmount(); if (isSeparated) return separatedAmount(); if (isRetired) return retiredAmount(); return normalPayAmount(); };

54 14. Replace Parameter with Explicit Method
Si un método realiza diferentes pasos dependiendo de los valores de los parámetros, refactorizar en diferentes métodos cada uno para el parámetro correspondiente. void setValue (String name, int value) { if (name.equals("height")) { height = value; return; } if (name.equals("width")) { width = value; Assert.shouldNeverReachHere(); void setHeight(int arg) { height = arg; } void setWidth (int arg) width = arg;

55 15. Replace Temp with Query
Si se utiliza una variable temporal para mantener el resultado de una expresión, se puede refactorizar extrayendo la expresión en un método y remplazando todas las referencias a esa variable con el nuevo método. double basePrice = quantity * itemPrice; if (basePrice > 1000) return basePrice * 0.95; else return basePrice * 0.98; if (basePrice() > 1000) return basePrice() * 0.95; else return basePrice() * 0.98; ... double basePrice() { return quantity * itemPrice; }

56 16. Rename Variable or Method
Uno de los mas simples y que mas se repiten, pero tambien de los mas útiles. Si el nombre de un metodo o variable no revela su proposito, cambiarlo para que si lo haga. public class Customer { public double getinvcdtlmt(); } public class Customer { public double getInvoiceCreditLimit(); }

57 Preguntas?

58 Recursos Refactoring. Improving the Design of Existing Code
Martin Fowler; Addison Wesley, 1999, ISBN Refactoring To Patterns Joshua Kerievsky; Addison Wesley, 2004, ISBN

59 Muchas Gracias Mariano Sánchez – Software Architect
4/7/ :02 AM Muchas Gracias Mariano Sánchez – Software Architect @marianosz © 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.