]> http://www.agile-spain.com/agilev2/taxonomy/term/34/all Técnicas de desarrollo, orientación a objetos, orientación a aspectos, etc. es http://www.agile-spain.com/agilev2/eselcambiodeinterfazrefactorizar <p><cite>Escrito por Martin Fowler</cite><br /> <cite>Traducido por Carmen Vidal ( Paradigma Tecnológico) </cite></p> <p>¿Es el cambio de interfaz de parte del código una refactorización?</p> <p>La respuesta a esta pregunta es bastante simple - el cambio de un interfaz es una refactorización que genera un cambio en todas las llamadas. Un gran ejemplo de esto es <a href="http://www.refactoring.com/catalog/renameMethod.html">RenombradoDeMétodo</a>, que es una refactorización de cambio de interfaz presente en la mayoría de herramientas de refactorización.</p> <p>El cambio de todas las llamadas es una parte esencial de esta refactorización. Solamente el cambio de una declaración de interfaz romperá el sistema - y consecuentemente no es un comportamiento que conserve el cambio.</p> <p>Las refactorización de cambio de interfaz asumen que se puede conseguir el mantenimiento de todas las llamadas, y esto es porque se tiene que ser mucho más cuidadoso con los <a href="http://www.martinfowler.com/bliki/PublishedInterface.html">InterfacesPublicados</a>. Con un interfaz publicado, el interfaz sí mismo es la parte del comportamiento observable del sistema.</p> <p>Los lenguajes dinámicos pueden hacer estos cambios mucho más difíciles. La mecanografía estática realmente ayuda aquí a controlar exactamente qué interfaz es llamado en varios puntos. Las llamadas reflexivas también pueden ser más difíciles de encontrar, bien integrando nombres de método en cadenas o componiéndolas en tiempos de ejecución. Esto es otra área donde las pruebas son esenciales incluso en los entornos que tienen instrumentos de refactorización.</p> Desarrollo Wed, 19 Sep 2007 14:09:35 +0000 http://www.agile-spain.com/agilev2/antipatrones_de_gestion_de_excepciones <p>¿Debo capturar o relanzar esta excepción? Si la lanzo, ¿debo imprimir una traza de log también? ¿Qué implicaciones tiene lanzar una excepción dentro de una transacción? </p> <p>Si te has hecho preguntas similares a estas alguna vez te gustará el artículo <a href="http://today.java.net/pub/a/today/2006/04/06/exception-handling-antipatterns.html">Exception-Handling Antipatterns</a> publicado hace unos días en Java.net en el que se tratan los principales casos de tratamiento de excepciones.</p> Desarrollo Wed, 12 Apr 2006 20:18:00 +0000 http://www.agile-spain.com/agilev2/codigocomodocumentacion <p><cite>Escrito por Martin Fowler</cite><br /> <cite>Traducido por Rafael Vacas</cite><br /> <cite>Revisado por Jorge Ferrer</cite></p> <p>Uno de los elementos comunes de los métodos ágiles es que otorgan a la programación un papel central en el desarrollo de software – mucho más de lo que la ingeniería del software suele hacer. Para esto es necesario considerar el código como la principal documentación de un sistema software. </p> <p>Casi de inmediato siento la necesidad de refutar un malentendido muy común. Tal principio no quiere decir que el código sea la única documentación. Aunque a menudo se dice esto de la ProgramacionExtrema, nunca lo he oído decir a los líderes de éste movimiento. Generalmente, se necesita documentación adicional como complemento al código.</p> <p> La razón por la que el código es la fuente principal de documentación se debe a que es la única lo suficientemente detallada y precisa como para ocupar este rol - un punto explicado elocuentemente por Jack W. Reeves en su famoso ensayo <a ref.=” http://www.developerdotstar.com/mag/articles/reeves_design_main.html”>"¿Qué es Diseño?"</a>.</p> Desarrollo Personajes Mon, 28 Nov 2005 08:03:43 +0000 http://www.agile-spain.com/agilev2/basededatosenmemoria <p><cite>Escrito por Martin Fowler</cite><br /> <cite>Traducido por Carmen Vidal</cite><br /> <cite>Revisado por Jorge Ferrer</cite><br /> Una base de datos en memoria (también denominada base de datos embebida) es una base de datos que corre completamente en la memoria principal, sin utilizar el disco duro. Por lo general, es creada cuando un proceso comienza, se ejecuta embebida dentro del proceso, y es destruida cuando el proceso termina.</p> <p> A primera vista una idea tan bestia parece ridícula. Los dos objetivos principales de la mayor parte de bases de datos son persistir la información entre invocaciones del proceso y manejar el acceso concurrente a datos entre procesos. Las bases de datos en memoria no cumplen ninguno de estos objetivos – ¿ Cuál es su utilidad?</p> <p>El caso más común en el que las he usado recientemente es para pruebas. Cuando se desarrolla una aplicación empresarial, las pruebas que atacan a la base de datos pueden consumir mucho tiempo cuando se ejecutan las baterías de pruebas. En estos casos, emplear una base de datos en memoria puede tener un efecto de un orden de magnitud que reduce tiempos de construcción radicalmente. Ya que a la mayor parte de los ThoughtWorkers se les da un aviso si no han tenido una barra verde recientemente, esta arquitectura es un hecho diferenciador.</p> Desarrollo Personajes Mon, 28 Nov 2005 07:44:02 +0000 http://www.agile-spain.com/agilev2/como_escribir_codigo_inmantenible <p>Una de las prácticas común a las metodologías ágiles es escribir código fácilmente mantenible. Una gran frase al respecto es <i>Cualquier desarrollador puede escribir código que una máquina pueda entender, pero sólo los buenos desarrolladores saben escribir código que otro desarrollador sepa entender</i>.</p> <p>Pues bien, según Roedy Green esta teoría está equivocada. Si te has encontrado casos de nombres de variables de una sóla letra, métodos con nombres tan explicativos como doIt, handle, etc., uso de la notación húngara, comentarios camuflados o líneas de código que no hacen nada, entonces su desarrollador estaba siguiendo los <a href="http://thc.org/root/phun/unmaintain.html">consejos para escribir código inmantenible</a> que le asegurarán ser siempre imprescindible. Una lectura muy recomendable <tt>;)</tt></p> Desarrollo Mon, 21 Nov 2005 23:06:55 +0000 http://www.agile-spain.com/agilev2/como_medir_la_cohesion_y_el_acoplamiento <p>Es ampliamente conocido que las clases de un buen diseño orientado a objetos deben tener una alta cohesión y un bajo acoplamiento. Sin embargo ¿Cómo pueden medirse estos índices? Samudra Gupta nos presenta varias métricas con este objetivo en el artículo <a href="http://javaboutique.internet.com/tutorials/coupcoh/">Coupling and Cohesion: The Two Cornerstones of OO Programming</a>. Al final del artículo también hace una interesante introducción a la ley de Demeter.</p> <p>En el mundo de las metodologías ágiles las métricas juegan un papel menos importante que en las metodologías tradicionales. El motivo es el riesgo de tomarlas demasiado en serio e ignorar otros factores más subjetivos pero también válidos. Sin embargo, siguen considerando interesante conocerlas y suelen servir como un complemento útil para evaluar y mejorar diseños.</p> Desarrollo Sat, 12 Nov 2005 12:12:18 +0000