El concepto de "terminado terminado"

todo-con-tarea-terminada¿No estaría bueno si, una vez que termináramos una historia, nunca tuviéramos que volver a agarrarla? Esta es la idea detrás del "terminado terminado". Una historia no es un desparramo de código sin integrar, sin probar. La historia debe estar lista para ser desplegada.

Leer más...

¡Dejen de reportar errores! (y escriban pruebas automatizadas)

bugLos sistemas de gestión de errores (o "bug trackers") son cuellos de botella, y perpetúan el continuo idea y vuelta entre testers y desarrolladores, además de requerir de mucha documentación para mantenerlos.

Alberto Gutierrez comparte una interesante reflexión sobre cómo crear el mejor sistema de gestión de errores: ¡dejar de reportar errores y empezar a escribir pruebas automatizadas!

Leer más...

¿Qué es el código testeable?

codigo malicioso¿Qué es el código "testeable"? ¿Cómo saber si mi código es testable o no? En los equipos ágiles se habla mucho sobre asegurarse de construir código testable, pero ¿qué significa exactamente? John Boal nos ayuda a definir este concepto con más precisión.

Leer más...

La ley y el principio de Shalloway

DuplicadoDando vueltas por ahí me encuentro con un divertido post en el blog de Alan Shalloway, en donde el autor desvaría brevemente sobre el problema de la redundancia en el código, llegando así a dos simpáticos postulados, nombrados en su propio honor. Veamos...

Leer más...

Micro-optimización: luchando la batalla equivocada por las razones equivocadas

PerformanceLa micro-optimización es una de las malas prácticas que pueden encontrarse en cualquier proyecto. La micro-optimización es una respuesta errónea a problemas potenciales o reales en un proyecto, aparece cuando el equipo falla en identificar la causa raíz y se enfoca en solucionar las consecuencias. Esto suele ocurrir por:

  1. Urgencia: No hay tiempo suficiente para analizar el problema.
  2. Experiencia: siempre se sigue la estrategia para parchear las consecuencias.
  3. Miedo: A veces las personas conocen la causa raíz, pero tienen miedo a mencionarlo.

Leer más...

¿Refactorizar o reescribir?

Máquina de escribirEl objetivo de refactorizar y reescribir es "limpiar" el sistema mediante la mejora de la legibilidad, estructura y la claridad del código. Un código limpio es más fácil de mantener y mejorar. Sin embargo, en muchas ocasiones los equipos pasan en cierto tiempo decidiendo entre los dos enfoques. 

Michael Dubakov sugiere las siguientes razones por las qué el código se deteriora con el tiempo: 

  • Más y más funcionalidades. Esto conduce a una mayor complejidad. 
  • Atajos e improvisaciones para apoyar cosas como "Necesitamos esta pantalla de búsqueda en agosto. ¡Y punto final!" 
  • Rotatividad. Los nuevos desarrolladores no saben todas las decisiones y las ideas clave detrás de la arquitectura. Inevitablemente, el conocimiento se pierde en la transición. 
  • Crecimiento del equipo. Más gente, menos comunicación. Menos comunicación, mas decisiones. 

Leer más...

Hay que deshacerse de la arquitectura del software

EdificioMe encanta escribir títulos llamativos, especialmente cuando, como este, tienen un significado importante que no es evidente al principio. Una de las definiciones de arquitectura de Ralph Johnson es "La arquitectura trata sobre las decisiones que deseamos se tomen bien al principio del proyecto". ¿Por qué las personas sienten que necesitan hacer algunas cosas desde el principio del proyecto? Por supuesto, la respuesta es porque perciben que algunas cosas son difíciles de cambiar. Entonces podríamos terminar definiendo a la arquitectura como "las cosas que las personas perciben como algo difícil de cambiar".

Leer más...

¿Quién necesita un arquitecto? (por Martin Fowler)

utiles de dibujoHace un tiempo me crucé con mi colega Dave Rice, y él estaba bastante enojado. Mi breve pregunta ocasionó una respuesta violenta: "No deberíamos entrevistar a nadie que dice ser 'arquitecto' en su currículum". Al principio me puso incómodo, porque usualmente presentamos a Dave como nuestro arquitecto líder...

Leer más...

No tener pruebas unitarias automatizadas es irracional

RobotHace unos meses que no participo con notas en el sitio, esto se debe primero al nacimiento de Nico, mi tercer hijo y luego a una inminente y complicada decisión y mudanza al fin. Recién esta semana estoy volviendo a tener la cabeza despejada, y aunque el reader explota y por raro que parezca, no encuentro la nota que me guste mucho, eso debe ser que ahora me fui al extremo de no pensar en nada....

Bueno, les dejo aquí algo que me agrado y es un buen aspecto desde donde ver las pruebas unitarias automatizadas y explicarselas a los gerentes en términos monetarios.

Leer más...

Las 7 características del código simple

DesarrolloAlberto Gutierrez nos comparte su punto de vista sobre lo que es la característica fundamental del Buen Código: la simpleza. El código simple es fácil de leer y fácil para cambiar. Y como es simple, es menos propenso a errores (mientras más complejo sea el algortimo que creamos, más probable que nos equivoquemos).

Como dicen: "No hay problemas dificiles, sólo soluciones difíciles". Así que cuando nos pongamos a escribir código tengamos presente los siguientes 7 consejos.

Leer más...

Consejos para el desarrollo ágil de software

Asterisco¿Qué es lo importante al momento de encarar un desarrollo ágil de software? Keith Swenson nos deja una compilación de 26 consejos que recolectó durante los años, sobre diversos temas. 

Leer más...

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw