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

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 18 — #56
✐
Capítulo 1. Introducción a los Objetos
interacción a través del ciclo completo, y eso requiere comportamientos arriesgados
(lo cual tiene sentido, porque está intentando hacer algo nuevo y los beneficios potenciales
son mayores). Puede parecer que el riesgo está compuesto por «prisas» en
una implementación preliminar, pero en cambio puede reducir el riesgo en un proyecto
comodín porque está descubriendo pronto si es viable un enfoque particular
para el problema. El desarrollo del producto es gestión de riesgos.
A menudo se propone que «construya uno desechable». Con la POO, todavía
debe andar parte de este camino, pero debido a que el código está encapsulado en
clases, durante la primera iteración inevitablemente producirá algunos diseños de
clases útiles y desarrollará algunas ideas válidas sobre el diseño del sistema que
no necesariamente son desechables. De esta manera, la primera pasada rápida al
problema no produce sólo información crítica para la siguiente iteración de análisis,
diseño, e implementación, sino que además crea el código base para esa iteración.
Es decir, si está buscando una metodología que contenga detalles tremendos y
sugiera muchos pasos y documentos, es aún más difícil saber cuándo parar. Tenga
presente lo que está intentando encontrar:
1. ¿Cuáles son los objetos (¿Cómo divide su proyecto en sus partes componentes)
2. ¿Cuáles son sus interfaces (¿Qué mensajes necesita enviar a otros objetos)
Si sólo cuenta con los objetos y sus interfaces, entonces puede escribir un programa.
Por varias razones podría necesitar más descripciones y documentos, pero no
puede hacerlo con menos.
El proceso se puede realizar en cinco fases, y una fase 0 que es simplemente el
compromiso inicial de usar algún tipo de estructura.
1.9.1. Fase 0: Hacer un plan
Primero debe decidir qué pasos va a dar en su proceso. Parece fácil (de hecho, todo
esto parece fácil) y sin embargo la gente a menudo no toma esta decisión antes de
ponerse a programar. Si su plan es «ponerse directamente a programar», de acuerdo
(a veces es adecuado cuando es un problema bien conocido). Al menos estará de
acuerdo en que eso es el plan.
También debe decidir en esta fase si necesita alguna estructura de proceso adicional,
pero no las nueve yardas completas. Bastante comprensible, algunos programadores
prefieren trabajar en «modo vacaciones» en cuyo caso no se impone ninguna
estructura en el proceso de desarrollo de su trabajo; «Se hará cuando se haga». Eso
puede resultar atractivo durante un tiempo, pero se ha descubierto que tener unos
pocos hitos a lo largo del camino ayuda a enfocar e impulsar sus esfuerzos en torno a
esos hitos en lugar de empezar a atascarse con el único objetivo de «finalizar el proyecto».
Además, divide el proyecto en piezas más pequeñas y hace que dé menos
miedo (y además los hitos ofrecen más oportunidades para celebraciones).
Cuando empecé a estudiar la estructura de la historia (por eso algún día escribiré
una novela) inicialmente me resistía a la idea de una estructura, sentía que cuando
escribía simplemente permitía que fluyera en la página. Pero más tarde me di
cuenta de que cuando escribo sobre computadoras la estructura es bastante clara,
pero no pienso mucho sobre ello. Pero aún así estructuro mi trabajo, aunque sólo
semi-inconscientemente en mi cabeza. Si aún piensa que su plan es sólo ponerse a
codificar, de algún modo, usted pasará por las posteriores fases mientras pregunta y
responde ciertas cuestiones.
18
✐
✐
✐
✐