59
Lagash Systems Mariano Sánchez – Software Architect [email protected] @marianosz http://weblogs.asp.net/ marianos

Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

Embed Size (px)

DESCRIPTION

Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor Mariano Sanchez .NET Conf UY 2014 http://netconf.uy

Citation preview

Page 1: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

Lagash SystemsMariano Sánchez – Software

[email protected]

@marianoszhttp://weblogs.asp.net/marianos

Page 2: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

Code Smells & Refactoring

Page 3: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 4: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 5: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

Code Smells - Clasificación

Page 6: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 7: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 8: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

Bloaters

Page 9: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 10: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 11: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 12: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

OO Abusers

Page 13: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 14: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 15: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 16: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

Change Preventers

Page 17: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 18: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 19: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

Code Smells – Change Preventers Magic Number

Valores que aparecen de la nada y se usan para realizar operaciones.

Page 20: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

Dispensables

Page 21: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 22: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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!

Page 23: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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?

Page 24: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

Couplers

Page 25: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 26: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 27: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 28: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

Extras

Page 29: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 30: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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.

Page 31: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

Refactoring

Page 32: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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

Page 33: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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

Page 34: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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

Page 35: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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

Page 36: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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)

Page 37: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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

Page 38: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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"; } }}

Page 39: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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"; }}

Page 40: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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

Page 41: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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();

Page 42: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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; }

Page 43: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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(); }

Page 44: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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; }}

Page 45: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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; }

Page 46: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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; }

Page 47: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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()); } }

Page 48: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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); }}

Page 49: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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); } }

Page 50: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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();

Page 51: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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;}

Page 52: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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]; }

Page 53: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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();

};

Page 54: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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;}

Page 55: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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;}

Page 56: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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();}

Page 57: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

Preguntas?

Page 58: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

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

Page 59: Code Smells y Refactoring o haciendo que nuestro codigo huela (y se vea) mejor by Mariano Sanchez

Muchas Gracias

Mariano Sánchez – Software Architect

[email protected]@marianosz

http://weblogs.asp.net/marianos