refactoring

I've just done the LCD Digits kata in Clojure. In this kata you have to create an LCD string representation of an integer value using a 3x3 grid of space, underscore, and pipe characters for each digit. Each digit is shown below (using a dot instead of a space) ._. ... ._. ._. ... ._. ._. ._. ._. ._.|.| ..| ._| ._| |_| |_. |_. ..| |_| |_||_| ..| |_. ._| ..| ._| |_| ..| |_| ..|Example: 910._. ... ._.|_| ..| |.|..| ..| |_|These are the tests...

I've just dome the Happy Numbers kata in Clojure. It's a simple kata that can be a lot of fun. I used a mix of TDD and REPL-driven development to code it. These are the resulting tests in Midje: and this is the code: To document the process I commited the code after every passing test and every refactoring. I also commited the REPL history. You can find the commits step by step hereand the code in this repository in GitHub. I used memoize to avoid repeated computations. In the next days I will...

I've recently revisited the Java version of Conway's Game of Life that I did nearly a year ago, to refactor it using some of the ideas I used in my more recent Clojure version. This is the UML for the refactored design:I eliminated the LivingCells class that appeared in the previous design.I pushed a lot of code from the GameOfLife class into Generation to eliminate a bit of feature envy. This is GameOfLife's code now: and this is Generation's one: I also refactored the tests eliminating all the...

Álvaro and I have been pairing lately to do a subset of the Bank Account kata that Sandro Mancuso proposed as an exercise in his Crafting Code course. We had to write and make the following acceptance test pass using Outside-In TDD: Given a client makes a deposit of 1000.00 on 01/04/2014And a withdrawal of 100.00 on 02/04/2014And a deposit of 500.00 on 10/04/2014When she prints her bank statementThen she would seeDATE | AMOUNT | BALANCE10/04/2014 | 500.00 | 1400.0002/04/2014 | -100.00 | 900.000...

I've refactored the Numbers Spelling kata I recently did in Clojure to remove some duplication. Before refactoring it, I had to make the old spell-out-number-over-99 and spell-out-number-up-to-99 functions similar enough for the duplication pattern to emerge. Then I could use the same function for both cases and also made some other minor changes such as using when-not form and renaming several bindings and arguments. This is the refactored code: You can find the code in this repository in GitH...

These are the links mentioned in our last conversation about the 15th chapter: Talks: La economía del refactoring. Una visión desde la gestión económica del proyecto. by Xavi GostMIT 6.001 SICP, 1986 Lecture 3A by Harold Abelson Posts: Object Functional Patterns at C2 Wiki - por Garajeando

“Yo refactorizaria pero el Jefe/Manager/PO no me iba a dejar” Si me dieran un euro por cada vez que he oído esto no necesitaría preocuparme de ninguna economía. Desarrollando cierta sensibilidad y apoyándonos en algunas técnicas, podemos hacer refactor en cualquier proyecto por hediondo que este sea. Pero ¿Cómo conseguir el tiempo para hacerlo? ¿Por dónde empiezo? ¿Cómo evito el ‘Gran Refactoring que necesita una semana’?. Contaré algunas lecciones aprendidas haciendo rescate de proyectos e intentaré contestar a estas preguntas. En esta charla pretendo explorar el impacto de refactorizar en la economía de un proyecto de mantenimiento. Encontraremos buenas razones para incorporar esta práctica y las expresaremos en el lenguaje que entiende el management (desde el 3.0 al mas rancio). El dinero. Porque adquiriendo una perspectiva correcta todos los proyectos son tan divertidos como un ‘greenfield’. Porque no hace falta cambiar escalas de valores ni abrazar árboles para empezar a hacer las cosas bien. Autor: Xavi Gost

¿Nos hacen los tests ir más rápidos? Mucha gente se pensará dos veces la respuesta a esa pregunta, cuando debería ser un rotundo y claro “sí”. Programadores de todo tipo intentan introducir el testing entre sus prácticas, pero no consiguen sacarle el beneficio esperado. Se sienten engañados ante todas aquellas promesas de refactoring seguro, de velocidad, y, en definitiva, de un código mejor. En esta charla veremos cómo podemos hacer tests que realmente nos hagan ir más rápido y mejoren nuestro código. Analizaremos prácticas comunes y anti patrones típicos en el testing, y cómo solventarlos. Autor: José Armesto

El lunes, 22 de diciembre a las 19h, os invitamos en el espacio de GeeksHubs a la primera charla del curso Refactoring a Patrones con Xavi Gost. El evento será un Coding Dojo, una reunión abierta, de programadores, aprendices, interesados y curiosos,…. Abstenerse aquellos sin ganas de programar y divertirse haciéndolo. Xavi nos explicará la forma de proceder en el curso y podréis resolver las dudas sobre dicho curso. Luego haremos un Coding Dojo para ir entrando en materia. Más info del curso: http://geekshubsacademy.com/courses/refactoring-xavi-gost.html

I've just redone the Roman Numerals kata in Clojure following the advices about test-driving algorithms that Sandro Mancuso gave during his Crafted Code course: Grow an algorithm bit by bitDelay treating exceptions (in this case, because they are more complex)Intentionally cause duplicationFocus on simple structures first The resulting code to convert decimals up to 3999 to roman numerals is much simpler than the code I got the first time I did the kata. I think the reason is that the first time...