Pensar en C++ (Volumen 1) - Grupo ARCO

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 543 — #581
✐
C.4. Sobre Análisis y Diseño
The Design & Evolution of C++ , por Bjarne Stroustrup (Addison-Wesley 1994).Aclaraciones
del inventor de C++ acerca de por qué tomó ciertas decisiones durante su
diseño. No es esencial, pero resulta interesante.
C.4. Sobre Análisis y Diseño
Extreme Programming Explained por Kent Beck (Addison-Wesley 2000).¡Adoro ese
libro! Si,sé que tengo tendencia a tomar posturas radicales, pero siempre había intuido
que podía haber un proceso de desarrollo de programas muy diferente, y mucho
mejor, y pienso que XP se acerca bastante a ello. El único libro que me impactó de
forma similar, fue PeopleWare (descrito a continuación), que trata de los entornos y la
interacción con la cultura de las empresas. Extreme Programming Explained habla de
programación, y echa abajo la mayoría de las cosas, incluso los recientes «hallazgos».
Llega al punto de decir que los dibujos están bien mientras que no se les dedique demasiado
tiempo y se esté dispuesto a tirarlos a la basura. (observen que ese libro
no lleva el «sello de certificación UML» en su portada). Comprendería que alguien
decidiese si quiere trabajar o no para una compañía, basándose sólo en el hecho que
usan XP. Es un libro pequeño, con capítulos cortos, fácil de leer, y que da mucho que
pensar. Uno empieza a imaginarse trabajando en esa atmósfera y vienen a la mente
visiones de un mundo nuevo.
UML Distilled por Martin Fowler (2ª edición, Addison-Wesley, 2000).Cuando se
descubre UML por primera vez, resulta intimidante porque hay tantos diagramas
y detalles. Según Fowler, la mayoría de esa parafernalia es innecesaria, así que se
queda sólo con lo esencial. Para la mayoría de los proyectos, sólo se necesitan unos
pocos instrumentos gráficos, y el objetivo de Fowler es llegar a un buen diseño en
lugar de preocuparse por todos los artefactos que permiten alcanzarlo. Es un libro
corto, muy legible; el primer libro que debería conseguir si necesita entender UML.
The Unified Software Development Process por Ivar Jacobsen, Grady Booch, y James
Rumbaugh (Addison-Wesley 1999). Estaba mentalizado para que no me gustase ese
libro. Parecía tener todos los ingredientes de un aburrido texto universitario. Me
quedé gratamente sorprendido - solo unos islotes dentro del libro contienen explicaciones
que dan la impresión que los conceptos no han quedado claros para los propios
autores. La mayoría del libro es no solamente claro, sino agradable. Y lo mejor
de todo, es que el proceso tiene realmente sentido. Esto no es Extreme Programming
(y no tiene su claridad acerca de los tests) pero también forma parte del mastodonte
UML - incluso si usted no consigue hacer adoptar XP, la mayoría de la gente se ha
subido al carro de "UML es bueno" (independientemente de su nivel de experiencia
real con él) así que podría conseguir que lo adopten. Pienso que ese libro debería ser
el buque insignia del UML, y es el que se debe de leer después del UML Distilled de
Fowler en cuanto se desee tener más nivel de detalle.
Antes de elegir método alguno, es útil enriquecer su perspectiva través de los
que no están intentando vender ninguno. Es fácil adoptar un método sin entender
realmente lo que se desea conseguir con él o lo que puede hacer por uno. otras personas
lo están usando, lo cual parece una buena razón. Sin embargo, los humanos
tienen un extraño perfil psicológico: si quieren creer que algo va a solucionar sus
problemas, lo van a probar. (Eso se llama experimentación, que es una cosa buena)
Pero si eso no les resuelve nada, redoblarán sus esfuerzos y empezarán a anunciar
por todo lo alto su fabuloso descubrimiento. (Eso es negación de la realidad, que no
es bueno) La idea parece consistir en que si usted consigue meter a más gente en
el mismo barco, no se sentirá solo, incluso si no va a ninguna parte (o se hunde).
No estoy insinuando que todas las metodologías no llevan a ningún lado, pero hay
543
✐
✐
✐
✐