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...

El cuadrante de la deuda técnica

BombaLa Deuda Técnica es una excelente metáfora (creada por Ward Cunningham) que nos ayuda a pensar sobre algunos problemas del desarrollo de software. Según la metáfora, hacer las cosas rápido y mal nos incrementa las deuda técnica, la cual es similar a la deuda financiera. Al igual que la deuda financiera, la deuda técnica tiene pago de intereses, que vienen en la forma del esfuerzo extra que será necesario hacer en el futuro por una elección rápida y mala de diseño. Podemos decidir seguir pagando el interés, o podemos pagar el capital al hacer un refactor del diseño hacia un diseño mejor. Aunque hay un costo de pagar este capital, nos ahorramos el pago de intereses en el futuro.

Leer más...

Cuantificando los beneficios de TDD

MedirSegún un estudio reciente, el uso de Test Driven Development (TDD) incrementa el tiempo de codificación en un 15-30%, y resulta en un 40-90% menos de defectos. El estudio se hizo en 4 equipos de desarrollo diferentes (1 de IBM y 3 de Microsoft). Esto confirma lo que cualquier practicante de TDD te puede decir: se gasta un poquito más de tiempo en escribir las pruebas, pero la calidad del código resultante es muy superior.

Leer más...

Cómo determinar el costo y tiempo de un proyecto

Diagrama de GanttDeterminar el costo y tiempo de un proyecto de software es uno de los temas más importantes en el desarrollo de software. Mi opinión seguramente va a ser polémica, y acá está: es imposible determinar cuál será el costo y el tiempo de un proyecto de desarrollo de software. Más aún, es muy mala idea intentar usar la planificación como si fuera un contrato con nuestro cliente.

Leer más...

Seguinos en Facebook.

Publicá tus artículos.

Publicar Convertite en redactor para Dos Ideas y compartí tus conocimientos a una comunidad que sigue creciendo!
Quiero publicar

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