Comments on: Red-Green-Refactor http://blog.lmcavalle.com/2006/12/03/red-green-refactor/ Bit by bit... Tue, 06 Jan 2009 12:41:30 +0000 http://wordpress.org/?v=2.0.5 by: Software que funcione sobre documentación exhaustiva at Putting it together http://blog.lmcavalle.com/2006/12/03/red-green-refactor/#comment-298 Wed, 04 Jul 2007 22:57:40 +0000 http://blog.lmcavalle.com/2006/12/03/red-green-refactor/#comment-298 [...] El único entregable preciso, actualizado e, incluso, capaz de autoverificarse del que disponemos es el código fuente. En este sentido, el desafio ágil es el siguiente: ¿sería posible escribir un código lo suficientemente claro y sencillo (lo suficientemente bonito) como para minimizar la documentación necesaria para entenderlo? Porque, si necesitamos documentación para entender el código que escribimos o escriben otros, ¿no será que el problema lo tenemos con el código, que no es tan mantenible como debería? [...] [...] El único entregable preciso, actualizado e, incluso, capaz de autoverificarse del que disponemos es el código fuente. En este sentido, el desafio ágil es el siguiente: ¿sería posible escribir un código lo suficientemente claro y sencillo (lo suficientemente bonito) como para minimizar la documentación necesaria para entenderlo? Porque, si necesitamos documentación para entender el código que escribimos o escriben otros, ¿no será que el problema lo tenemos con el código, que no es tan mantenible como debería? [...]

]]> by: programame.net http://blog.lmcavalle.com/2006/12/03/red-green-refactor/#comment-24 Wed, 17 Jan 2007 21:34:02 +0000 http://blog.lmcavalle.com/2006/12/03/red-green-refactor/#comment-24 Red-Green-Refactor, desarrollo orientado a los tests... Escribe un test sencillo que compruebe una parte de la funcionalidad que quieres implementar. Asegurate de ejecutar el test y de que este falle (rojo) según lo esperado Escribe el mínimo código en tu aplicación con el que consigas pasar el test (ve... Red-Green-Refactor, desarrollo orientado a los tests…

Escribe un test sencillo que compruebe una parte de la funcionalidad que quieres implementar. Asegurate de ejecutar el test y de que este falle (rojo) según lo esperado Escribe el mínimo código en tu aplicación con el que consigas pasar el test (ve…

]]> by: De cómo el código bonito atrae código bonito at Putting it together http://blog.lmcavalle.com/2006/12/03/red-green-refactor/#comment-6 Sun, 17 Dec 2006 22:33:19 +0000 http://blog.lmcavalle.com/2006/12/03/red-green-refactor/#comment-6 [...] Uno de las características de las metodologías ágiles, en particular de la Programación Extrema, es intentar resolver los problemas clásicos del desarrollo de SW teniendo en cuenta la psicología del desarrollador, pieza fundamental en todo lo ágil (Individuos sobre procesos). Todo gira en torno a la motivación y la actitud del desarrollador ante su trabajo. En este sentido está claro que documentar no es la tarea más agradable para un programador, y sí se supone que lo es escribir código (Software que funciona sobre documentación exhaustiva). Hay otros ejemplos, como la observación de que cuando un desarrollador tiene que probar el código después de haberlo implementado él mismo, tiende a ser poco riguroso, hay una inclinación natural a no querer tener que volver atrás a corregir lo que ya se ha hecho. El simple hecho de escribir los tests antes que el código (TDD), según los agilistas, le da la vuelta a la situación. [...] [...] Uno de las características de las metodologías ágiles, en particular de la Programación Extrema, es intentar resolver los problemas clásicos del desarrollo de SW teniendo en cuenta la psicología del desarrollador, pieza fundamental en todo lo ágil (Individuos sobre procesos). Todo gira en torno a la motivación y la actitud del desarrollador ante su trabajo. En este sentido está claro que documentar no es la tarea más agradable para un programador, y sí se supone que lo es escribir código (Software que funciona sobre documentación exhaustiva). Hay otros ejemplos, como la observación de que cuando un desarrollador tiene que probar el código después de haberlo implementado él mismo, tiende a ser poco riguroso, hay una inclinación natural a no querer tener que volver atrás a corregir lo que ya se ha hecho. El simple hecho de escribir los tests antes que el código (TDD), según los agilistas, le da la vuelta a la situación. [...]

]]>