Pensar en C++ (Volumen 1) - Grupo ARCO
Pensar en C++ (Volumen 1) - Grupo ARCO
Pensar en C++ (Volumen 1) - Grupo ARCO
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
✐<br />
✐<br />
✐<br />
“Volum<strong>en</strong>1” — 2012/1/12 — 13:52 — page 27 — #65<br />
✐<br />
1.10. Programación Extrema<br />
sus requisitos, y <strong>en</strong>tonces descubre que no era realm<strong>en</strong>te lo que buscaba. Cuando ve<br />
el sistema <strong>en</strong> funcionami<strong>en</strong>to, descubre que realm<strong>en</strong>te quería resolver era problema<br />
difer<strong>en</strong>te. Si pi<strong>en</strong>sa que este tipo de evolución le va a ocurrir, <strong>en</strong>tonces debe construir<br />
su primera versión lo más rápidam<strong>en</strong>te posible para que pueda darse cu<strong>en</strong>ta de si es<br />
eso lo que quiere.<br />
Quizás lo más importante a recordar es que por defecto -por definición, realm<strong>en</strong>tesi<br />
modifica una clase <strong>en</strong>tonces su superclase -y subclases- seguirán funcionando. Necesita<br />
perder el miedo a los cambios (especialm<strong>en</strong>te si ti<strong>en</strong>e un conjunto predefinido<br />
de pruebas unitarias para verificar la validez de sus cambios). La modificación no<br />
romperá necesariam<strong>en</strong>te el programa, y ningún cambio <strong>en</strong> el resultado estará limitado<br />
a las subclases y/o colaboradores específicos de la clase que cambie.<br />
1.9.7. Los planes val<strong>en</strong> la p<strong>en</strong>a<br />
Por supuesto, no construiría una casa sin un montón de planos cuidadosam<strong>en</strong>te<br />
dibujados. Si construye un piso o una casa para el perro, sus planos no serán<br />
muy elaborados pero probablem<strong>en</strong>te empezará con algún tipo de esbozo para guiarle<br />
<strong>en</strong> su camino. El desarrollo de software ha llegado a extremos. Durante mucho<br />
tiempo, la g<strong>en</strong>te t<strong>en</strong>ía poca estructura <strong>en</strong> sus desarrollos, pero <strong>en</strong>tonces grandes proyectos<br />
empezaron a fracasar. Como resultado, se acabó utilizando metodologías que<br />
t<strong>en</strong>ían una cantidad abrumadora de estructura y detalle, se int<strong>en</strong>tó principalm<strong>en</strong>te<br />
para esos grandes proyectos. Estas metodologías eran muy complicadas de usar -<br />
la s<strong>en</strong>sación era que se estaba perdi<strong>en</strong>do todo el tiempo escribi<strong>en</strong>do docum<strong>en</strong>tos y<br />
no programando (a m<strong>en</strong>udo era así). Espero haberle mostrado aquí suger<strong>en</strong>cias a<br />
medio camino - una escala proporcional. Usar una propuesta que se ajusta a sus necesidades<br />
(y a su personalidad). No importa lo pequeño que desee hacerlo, cualquier<br />
tipo de plan supondrá una gran mejora <strong>en</strong> su proyecto respecto a no planear nada.<br />
Recuerde que, según la mayoría de las estimaciones, alrededor del 50% de proyectos<br />
fracasan (¡algunas estimaciones superan el 70%!).<br />
Seguir un plan - preferiblem<strong>en</strong>te uno simple y breve - y esbozar la estructura del<br />
diseño antes de empezar a codificar, descubrirá qué cosas ca<strong>en</strong> juntas más fácilm<strong>en</strong>te<br />
que si se lanza a programar, y también alcanzará un mayor grado de satisfacción.<br />
Mi experi<strong>en</strong>cia me dice que llegar a una solución elegante es profundam<strong>en</strong>te satisfactorio<br />
<strong>en</strong> un nivel completam<strong>en</strong>te difer<strong>en</strong>te; parece más arte que tecnología. Y la<br />
elegancia siempre vale la p<strong>en</strong>a; no es una búsqueda frívola. No sólo le permite t<strong>en</strong>er<br />
un programa fácil de construir y depurar, también es más fácil de compr<strong>en</strong>der y<br />
mant<strong>en</strong>er, y ahí es donde recae su valor económico.<br />
1.10. Programación Extrema<br />
He estudiado técnicas de análisis y diseño, por activa y por pasiva, desde mis<br />
estudios universitarios. El concepto de Programación Extrema (XP) es el más radical<br />
y <strong>en</strong>cantador que he visto nunca. Puede <strong>en</strong>contrar una crónica sobre el tema<br />
<strong>en</strong> Extreme Programming Explained de K<strong>en</strong>t Beck (Addison-Wesley 2000) y <strong>en</strong> la web<br />
www.xprogramming.com<br />
XP es una filosofía sobre el trabajo de programación y también un conjunto de<br />
directrices para hacerlo. Alguna de estas directrices se reflejan <strong>en</strong> otras metodologías<br />
reci<strong>en</strong>tes, pero las dos contribuciones más importantes y destacables, <strong>en</strong> mi opinión,<br />
son «escribir primero las pruebas» y la «programación <strong>en</strong> parejas». Aunque defi<strong>en</strong>de<br />
con fuerza el proceso completo, B<strong>en</strong>k señala que si adopta únicam<strong>en</strong>te estas dos<br />
27<br />
✐<br />
✐<br />
✐<br />
✐