code smells y refactoring o haciendo que nuestro codigo huela (y se vea) mejor by mariano sanchez
DESCRIPTION
Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor Mariano Sanchez .NET Conf UY 2014 http://netconf.uyTRANSCRIPT
Lagash SystemsMariano Sánchez – Software
@marianoszhttp://weblogs.asp.net/marianos
Code Smells & Refactoring
Que son los Code Smells? Wikipedia:
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.
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.
Code Smells - Clasificación
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.
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.
Bloaters
Code Smells - Bloaters Long Methods
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.
Code Smells - Bloaters Primitive Obsession
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.
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.
OO Abusers
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.
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.
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.
Change Preventers
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.
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.
Code Smells – Change Preventers Magic Number
Valores que aparecen de la nada y se usan para realizar operaciones.
Dispensables
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.
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!
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?
Couplers
Code Smells - Couplers Feature Envy
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.
Code Smells - Couplers Indecent Exposure
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.
Code Smells - Couplers Middle Man
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.
Extras
Code Smells - Extras Type embedded in 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.
Code Smells - Extras Inconsistent Names
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.
Refactoring
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
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
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
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
Code Smells Si apesta, cambialo!!
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, email, 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)
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
Ejemplo 1, continuadoclass 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"; } }}
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"; }}
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
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 { public List students;
}
int classSize = course.students.size();
public class Course { private List students; public List getStudents() { return students; } public void setStudents(List s) { students = s; }}int classSize = course.getStudents().size();
3. Extract Class Separar una clase en dos, dividiendo las responsabilidades según corresponda.
public class Customer{ private String name; private String workPhoneAreaCode; private String workPhoneNumber; }
public class Customer{ private String name; private Phone workPhone; }
public class Phone { private String areaCode; private String number; }
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 { 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 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 interface SerXml { public abstract String toXML(); }
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() { … // Compute score score = a*b+c; score *= xfactor; }}
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; }}
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 { private String name; private String jobTitle; }
public class Person { protected String name; }
public class Employee extends Person { private String jobTitle; }
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 class Employee { private String name; private String jobTitle; }
public class Student { private String name; private Course course; }
public abstract class Person { protected String name; }
public class Employee extends Person { private String jobTitle; }
public class Student extends Person { private Course course; }
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 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); } }
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()); } }
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); }}
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 acopladopublic 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); } }
10. Introduce Null Object Utilizar Null Object para mejorar el manejo de nulos
public class User { Plan getPlan() { return plan; } }
public class User{ Plan getPlan() { return plan; }}
public class NullUser extends User{ Plan getPlan() { return Plan.basic(); }}
if (user == null) plan = Plan.basic();else plan = user.getPlan();
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.
int withdraw(int amount) { if (amount > balance)
return -1; else {
balance -= amount;return 0;
}}
void withdraw(int amount) throws BalanceException{ if (amount > balance) { throw new BalanceException(); } balance -= amount;}
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]; }
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();else {
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();
};
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; return; } Assert.shouldNeverReachHere();}
void setHeight(int arg) { height = arg;}
void setWidth (int arg) { width = arg;}
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;
elsereturn basePrice() * 0.98;
...double basePrice() {
return quantity * itemPrice;}
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();}
Preguntas?
Recursos Refactoring. Improving the Design of Existing Code Martin Fowler; Addison Wesley, 1999, ISBN 0201485672
Refactoring To Patterns Joshua Kerievsky; Addison Wesley, 2004, ISBN 0321213351
http://www.soberit.hut.fi/mmantyla/BadCodeSmellsTaxonomy.htm
Muchas Gracias
Mariano Sánchez – Software Architect
[email protected]@marianosz
http://weblogs.asp.net/marianos