Refactoring

Aplicando la programaci�n a finanzas

Kohonen

La oportunidad que nos ofrece el ser programadores en otros ambitos, es el ser capaces de utilizar la poderosa herramienta que es la programaci�n. En finanzas y en concreto en bolsa existe una tendencia cada vez mas importante de informatizar las tomas de decisiones sobre comprar o vender acciones. Os invito a visitar el nuevo blog que he creado sobre Bolsa, http://www.especulacion.org�en el que trato de explicar los desarrollos que estoy realizando para encontrar sistemas autom�ticos que inviertan en bolsa. Si alguno tiene esta misma afici�n y quiere compartir este aprendizaje podemos ponernos el contacto en los foros del portal.

Libros imprescindibles para un programador

Kohonen

�En este profesi�n es imprescindible seguir formandose continuamente. La lectura de diferentes web o de articulos son una muy buena forma de poder hacerlo, aunque el problema que en mi opini�n tienen es que su formato no permite que se entre en demasiado detalle. Para cubrir este problema podemos encontrar libros realmente buenos que en mi opini�n son de imprescindible lectura para un buen programador. Si encima como si eres de esas raras personas a las que les gusta leer libros t�cnicos en tu tiempo libre, entonces probablemente te puedan dar algunas ideas la lista de libros que te propongo.

En principio este post voy a tratar de irlo actualizando con la lista de libros que voy leyendo y con vuestra sugerencias. Es una lista reducida de los mejores libros que he leido.

Una de las preguntas que recomiendo hacer en un entrevista cuando se contrata a un programador, es �Cual es �ltimo libro que has leido sobre temas t�cnicos?. En mi opini�n es muy acertada porque permite saber el interes que tiene una persona en seguir actualizado.

Os recomiendo que sigais los enlaces de las imagenes�si quereis comprar alguno, porque en Amazon estan a muy buen precio.

Refactoring: Improving the Design of Existing Code : Martin Fowler En mi opinion la biblia de la Refactorizaci�n. Deber�an estudiarse estas refactorizaciones en la facultad.

Pragmatic Programmer: Mi favorito. Un excelente y completo compendio de las buenas pr�cticas que debe seguir un programador.

Desarrollo Dirigido por Pruebas: Despues de este libro hay un antes y un despues en la forma de programar. Muy interesante la lectura del primer apartado, que con un ejemplo sencillo conseguira introducirnos en el mundo del desarrollo dirigido por pruebas.

Pensando en Java: Un libro excepcional para repasar Orientaci�n a Objetos para los amantes de Java. Por cierto este se puede descargar gratis desde la web, aunque yo creo que merece la pena tener el libro.

Eliminar Variable Temporal (Inline Temp)

Kohonen

�Tendemos a hacer optimizaci�n temprana? La verdad es que, no se si heredado de otras epocas donde el espacio era muy valioso, o porque realmente tenemos tendencia a preocuparnos mucho por la eficiencia, pero�creo que se suele generalmente hacer optimizaci�n temprana. Pero,��no es mas facil atacar el problema de la eficiencia una vez que hemos desarrollado nuestra aplicaci�n consiguiendo un buen dise�o orientado a objetos? �No es una mala pr�ctica guiar nuestro dise�o y nuestra codificaci�n en funci�n�de optimizaciones cuyo impacto todav�a desconocemos?

Descripci�n

* Situaci�n inicial:En un m�todo se asigna un valor a una variable temporal y se usa esta a lo largo del m�todo.

* Refactorizaci�n:�Sustituir la variable temporal por las llamadas al metodo.

* Situaci�n final: La variable temporal ha sido eliminada. Esta ha sido sustituida por invocaciones.

Ejemplo��

public void doPost(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {

    double interes = prestamo.calculaInteres();
    if (interes > o) ...

...

Despu�s de aplicar Eliminar Variable Temporal tendremos el siguiente c�digo:

public void doPost(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {

    if (prestamo.calculaInteres() > o) ...
...

}��

Url

��http://www.refactoring.com/catalog/inlineTemp.html

Comentarios

�� Con esta refactorizaci�n me costo estar de acuerdo. Quizas el ejemplo que pongo no refleja bien el problema que le veia. El problema que le veia a esta Refactorizacion era que estabamos eliminando la variable que almacenaba el resultado de una llamada a otro metodo�y que por este motivo tendriamos que hacer esa misma llamada en cualquiera de los sitios donde estuvieramos utilizando esa variable. ! Que perdida de eficiencia !

�� De lo que no era consciente es que�cuando programamos muchas veces no nos importa aplicar soluciones que har�n nuestro c�digo inmantenible con la excusa de ganar eficiencia. Parece que esta excusa es una de las mejores que nos podemos�poner para saltarnos�las reglas de una buena codificaci�n. La experiencia me dice que�mucho mas f�cil� y mas productivo mejorar la eficiencia de un c�digo bien desarrollado, que ir seg�n vamos desarrollando aplicando mejoras de performance�que no sabemos cual�el impacto que tendr�n en el global. Desde luego�por ese motivo no considero una buena razon la perdida de eficiencia para no entender esta refactorizacion.

��Una vez�soltado el discurso filos�fico, creo las variable temporales en muchos casos hacen nuestro�c�digo mas ilegible. Bien por la nomenclatura, bien por que las utilizamos para varias cosas. Son especialmente dolorosos los efectos colaterales que a veces ocasionan. En aquellos casos en los que el valor que tenemos en la variable temporal se obtenga de una llamada sencilla es muy recomendable hacer esta refactorizaci�n.

Principio de Segregacion de las Interfaces (Interface Segregation Principle ISP)

Kohonen

Uno de las partes mas importantes de un sistema es el conjunto de interfaces que definimos para exponer su funcionalidad. Nosotros mismo cuando trabajamos con otras librerias nos enfrentamos a diferentes interfaces dise�adas con mas o menos exito. Este dise�o puede hacer que sea muy costoso o complicado utilizar ciertas librerias que no han sido correctamente dise�ada.� Uno de los principios de dise�o de clases que aborda este problema es el Principio de Segregaci�n de Interfaces

Me encontrado con varias frases que definen este principio. La que mas me gusta es la siguiente

�� Los clientes no deber�an ser obligados a depender de interfaces que no utilizan

Tambien he encontrado otra frase que resume la misma idea

�� Muchas interfaces muy especializadas�son preferibles a una interfaz general en la que�se�agrupen todas las interfaces��

Lo que nos dice este principio es que es preferible crear muchas interfaces a tener una �nica interfaz.��Porque es mejor? Porque estamos haciendo un mejor dise�o orientado a objetos. Crear una �nica interfaz supone dar mucha responsabilidad a una clase que debiera separarse por la relaci�n que existe en sus funcionalidad. Uno de los sintomas mas comunes que nos encontraremos cuando estemos cometiendo este error ser� que no encontraremos facilmente un nombre para dicha clase. Tanta responsabilidad es dificil poder resumirla en una palabra, y al fina utilizaremos nombres por ejemplo Manager que encajar� muy bien de comodin.

Deberiamos evitar que nuestro c�digo tenga demasiado acoplamiento que haga que cada modificaci�n implique cambios en multitud de clases.

�No obstante, siendo sincero, cuando yo he desarrollado he tendido a realizar interfaces nada especializadas.�El problema que trataba de solucionar cuando creaba estas interfaces era el de abstraer al cliente de mi interfaz de las implementaci�n de mis interfaces. La clase general trataba de ser la �nica dependencia que se generar�a de cara a mis clientes extener, teniendo de alguna forma "controlado" que cambios en mi implementaci�n no afectar�an a nadie. No obstante el problema aparec�a cuando esta interfaz empezaba a crecer de una manera desorganizada, al ir a�adiendo los metodos que se iban desarrollando al extender la funcionalidad. La soluci�n a este problema pasa por definir dos capas. La que ser� la capa de interfaz, en la que se pueden desarrollar muchas interfaces especializadas y otra capa que ser� en la que se defina la implementaci�n.

� Podeis encontrar articulos sobre este principio en

�� http://www.objectmentor.com/resources/articles/isp.pdf

Portal de Agile-Spain renovado

Kohonen

Tras una temporada trabajando en la nueva versi�n del portal de www.agile-spain.com�, hemos sacado a la luz la nueva versi�n de portal. Hemos intentado poner a disposici�n de las personas que lo visiten herramienta que permitan que esta comunidad vaya creciendo y enriqueciendose con la colaboraci�n de todo el que lo desee. En ese sentido hay Foros de discusi�n, herramientas para aportar noticias, blogs personalizados, encuestas..

�Os invitamos a que lo conozcais y a que nos envies cualquier sugerencia para poder hacerlo cada d�a mas interesante para todos.

� Un saludo

Curso de Java Gratuito

Kohonen

Publico la informaci�n de este curso de Java porque me ha parecido muy interesante el temario (a parte de porque es gratuito). Adoptar las tecnolog�as que se tratan en�el curso en nuestro proyectos web, representar�n sin duda refactorizaciones que permitir�n que nuestro desarrollo crezca ordenadamente. No obstante, siempre estudiando que la complejidad que introducimos se ve recompensada en la estructura de nuestro c�digo (no solo en la satisfacci�n t�cnica personal de trabajar con la �ltima tecnolog�a)

Curso Java Gratuito

Agrupar Jerarquias (Collapse Hierarchy)

Kohonen

�Hemos conseguido�que�nuestro dise�o quede perfecto? �Hemos conseguido que nuestro dise�o�se adapte a los requisitos que teniamos?. A veces conseguimos lo primero a base de�hacer un sobre-dise�o�que no utilizaremos. Pero tampoco hay que castigarse,��en el fondo a todos nos gusta la complejidad. Lo�simple no vende nada, bueno miento, no vende nada sobre papel, porque en la realidad cuanto mas simple sea una soluci�n�menos coste de desarrollo tendremos y menos nos costar� extenderla.

Descripci�n

* Situaci�n inicial: Observamos que tenemos una subclase que pr�cticamente no a�ade nada a la superclase.

* Refactorizaci�n: Eliminar la subclase a�adiendo a�adiendo extendiendo la superclase con las peque�as diferencias.

* Situaci�n final: Evitamos tener clases en las que pr�cticamente no haya c�digo.

�

Ejemplo

Url

http://www.refactoring.com/catalog/collapseHierarchy.html

Comentarios�

�� Esta es la ultima refactorizaci�n del grupo de refactorizaciones para evitar la generalizaci�n especulativa.�En este caso estamos eliminando una herencia que no estaba justificada. Volver a ella no ser� dificil, si en nuestros requisitos cambian y nos conducen a hacerla de nuevo.

��Si trabajamos con control de Versiones no ser� dificil de recuperar versiones anteriores de nuestro c�digo. Esto nos evitar� el ir acumulando en nuestro proyecto codigo que no se utiliza�y que conforme pase el tiempo tendremos mucho mas dificil de eliminar. Esto ocurrir� porque no sabremos exactamente si lo estamos utilizando o no, y�averiguarlo nos llevar� un tiempo que no tenemos. Por ese motivo yo soy partidario de eliminar del proyecto todo aquello que no vaya a ser utilizado, en el mismo momento en el que lo detectamos, confiando en que nuestro control de versiones podr� volver a recuperla si en alg�n momento lo necesitamos. El efecto de ir dejando cosas sin eliminarlas, es el efecto "trastero",� si comenzamos a almacenar cosas que nunca utilizaremos luego ser� mucho mas complicado tener facilmente accesibles las que realmente si necesitamos utilizar mucho mas frecuentemente, haciendo que al final esta politica nos haga mucho mas dificil acceder a lo que realmente importa. En el caso del trastero supone que�al final no le sacaremos toda la utilidad que tiene (por ejemplo como despensa).

�� Utilizar la herencia donde no se necesita, es sin duda una forma de tener nuestro c�digo mucho mas divido de lo que nos hubiera hecho falta.

Dise�o abierto pero cerrado : (The Open Closed Principle)

Kohonen

Uno de los principios�que he encontrado en un libro de Robert C. Martin es el�Principio de Dise�o Abierto pero Cerrado (The Open Closed Principle). Este principio viene a decirnos que en nuestro dise�o nuestras entidades de software (Clases, Modulos, Funciones) deben�estar dispuestas a ser extendidas, pero debemos evitar modificarlas.
�

Este principio viene a decirnos que en nuestro dise�o nuestras entidades de software (Clases, Modulos, Funciones) deben�estar dispuestas a ser extendidas, pero debemos evitar modificarlas.

En otras palabras debemos de ser capaces de modificar el comportamiento de�nuestro software sin tener que modificar el codigo fuente�ya existente. Aunque pueda sonar contradictorio la clave para conseguir�que nuestro dise�o nos permite facilmente a�adir nuevos coportamientos esta en la abstracci�n. El dise�o orientado a objetos es una�potente herramienta que nos�permite�utilizar la abstracci�n para conseguir nuestro objetivo.

Utilizando los principio de la programaci�n orientada a objeto podemos crear abstracciones mas bien fijas y tendentes a no ser modificadas que agruparan aun grupo ilimitado de de comportamientos posibles. Estas abstracciones son las que conseguimos cuando en nuestro dise�o incluimos clases abstractas y los posible comportamientos ser�n el conjunto de clases derivadas de la clase abstracta. Con este dise�o seremos capaces de crear nuevas clases derivadas, a�adiendo nuevos comportamientos,� sin necesidad de modificar otras clases. Con este dise�o seremos capaces de a�adir nuevas subclases de forma sencilla sin necesidad de modificar el codigo ya existente (la clase abstracta y las subclases ya existentes), cumpliendo por tanto con el Principo de Dise�o Abierto pero Cerrado (OPC)

Uno de los malos olores que podemos detectar en nuestro c�digo si�estamos violando este principio ser� la presencia de if y switchs. Eso se deber� a que probablemente estemos�utilizando en nuestras clases atributos que indican el tipo de objeto ante el que nos encontramos y que�se utilizar�n para�modificar el comportamiento de ciertos metodos. Esto implicar� que en cada metodo de nuestra clases tendremos un if o un switch que decidir�n el comportamiento en funci�n de estos atributos. Para a�adir un nuevo comportamiento ser� necesario introducir en todos estos puntos la nueva opci�n�y el codigo asociado al nuevo comportamiento de esta opci�n. Estaremos violando el Princio de Dise�o Abierto pero Cerrado, porque estaremos modificando el c�digo ya existente y porque nuestra aplicaci�n ser� cada vez mas dificil de extender.

Un ejemplo de dise�o que viola el principio es que el podemos encontrar a la izquierda. Con la Refactorizacion sugerida��(SustituirCodigoDeTipoConSubclases http://www.refactoring.com/catalog/replaceTypeCodeWithSubclasses.html) obtenemos un dise�o que si que cumple este principio.

�

Podemos encontrar informaci�n sobre este principio en la siguiente direccion

http://www.objectmentor.com/resources/articles/ocp.pdf

�

�En que casos debemos comentar nuestro c�digo?

Kohonen

En este articulo podemos encontrar una interesante reflexi�n sobre que tipo de comentarios son realmente utiles en nuestro c�digo. No es una buena practica, como�dice Martin Fowler, utilizar los comentarios como desodorante para los malos oleres de nuestro c�digo

En este articulo podemos encontrar reflexiones en mi opini�n muy interesantes:

�* Si nuestro c�digo es de mala calidad, utilizar un comentario para facilitar su claridad no es la mejor forma de solucionar el problema.�Si encontramos malos olores en nuestro c�digo, utilizar los comentarios a modo desodorante es una mala elecci�n. Mejor es corregirlo

�* Tenemos que intentar que nuestro c�digo hable por si solo. Si tratamos de explicar lo que hace nuestro c�digo estaremos duplicando informaci�n que en cualquier momento puede diferir.

�* Una correcta nomenclatura y un dise�o simple�evitar�a la gran mayor�a de comentarios que solemos utilizar.

Aqui podeis encontrar el articulo, donde trata de explicar lo que el considera comentarios valiosos.

http://www.stickyminds.com/testing.asp?Function=edetail&ObjectType=ART&ObjectId=9041&tth=DYN&tt=siteemail&iDyn=3

Eliminar parametros (Remove Parameter)

Kohonen

�Tenemos metodos que utilizamos pasando siempre el mismo valor�en uno de sus parametros?. �Esta este valor documentado para que una persona que lo utilice sepa cual es el valor que debe de pasar? �Hemos definido ese parametro porque pensamos que lo utilizaremos en el futuro?. Creo que es momento de aplicar el "CARPE DIEM" y vivir el presente ;).

Descripci�n

* Situaci�n inicial: Un parametro no es utilizado en la clase o siempre se utiliza pasando el mismo valor.

* Refactorizaci�n: Eliminar el parametro del metodo.

* Situaci�n final: Si no se utilizaba no ser� necesario modificar la clase, si se utilizaba el mismo hay dos soluciones, instanciar ese valor dentro del metodo. Podemos tambi�n sobrecargar el metodo de forma que creemos una nuevo metodo sin este parametro que instancie el valor por defecto y llame al original con ese valor.

Ejemplo

Url

http://www.refactoring.com/catalog/removeParameter.html

Comentarios�

Esta es�un refactorizaci�n que pertenece al grupo de refactorizaciones que�atacan al problema de la generalizaci�n especulativa.�Este tipo de metodos es facil detectarlos cuando observamos que en todas las llamadas que hacemos siempre pasamos�el mismo parametro. Bien�pasando un valor que�es nulo, o bien pasando un valor por defecto que es�el que utilizarmos siempre.

Si tenemos esta situaci�n lo mejor ser� eliminar ese parametro hasta que realmente sea necesario. Si al final fuera necesario, no tenemos mas que recuperarlo de nuestro control de versiones ese c�digo y a�adirlo a nuestra clase. Generalmente en ese momento tendremos una necesidad real de pasar ese parametro y seamos capaces de encontrarle un nombre con mucho mas sentido que los que solemos generar cuando estamos especulando necesidades futuras.

�Cuando creamos un parametro de este tipo, estamos haciendo que nuestro c�digo se entienda un poco peor. Los metodos con una larga lista de parametros son siempre mas complicados de entender y de utilizar. Si a esto le sumamos que uno de los parametros esta pensando para una utilidad futura, eso implicar� que deberemos conocer el valor que debemos pasarle por defecto mientras tanto.�

�Enfrentarnos a los problemas cuando los tengamos es en general una mejor pol�tica que tratar de solucionar a priori todos nuestros futuros problema. Porque tratar de hacerlo har� nuestro presente mucho mas complicado.