-
Cambio y decadencia veo en todas partes ...
H. F. Lyte, "Abide With Me"
Como un programa que ev oluciona, será necesario replantear las decisiones anteriores y rehacer porciones de código. Este proceso es perfectamente natural. El código tiene que evolucionar, no es algo estático.
Por desgracia, la metáfora más común para el desarrollo de software es la construcción de edificios (Bertrand Meyer utiliza el término "Contrucción de Software ").
Pero la construcción utilizando como metáfora de orientación implica estos pasos:
1. 1. Un arquitecto elabora los planos.
2. 2. Constructores (albañiles) que se encargan de excavar los cimientos, construir la estructura y aplicar los toques finales.
3. 3. La satisfacción de los inquilino sde vivir felices siempre, llamando a la construcción de mantenimiento para solucionar cualquier problema.
Bueno, el software no funciona de esa manera. En lugar de la construcción, el software es más como la jardinería (es más ecológico que el concreto).
Siembras muchas plantas en un jardín de acuerdo con un plan inicial y condiciones.
Algunos prosperan, otros están destinados a terminar como abono.
Se puede mover las plantaciones de uno respecto al otro para aprovechar la interacción de la luz y la sombra, el viento y la lluvia.
Se puede mantener y separar las plantas podando, como también organizando los colores que se pueden obtener para tenerlo más agradable estéticamente.
Usted tira las malas hierbas y fertiliza las plantaciones que están en necesidad de algunas ayudas extras.
Usted supervisa constantemente la salud del jardín, y hace los ajustes (a la tierra, las plantas, al diseño) como sea necesario.
La metáfora de la jardinería es mucho más cercano a las realidades de desarrollo de software. Tal vez una cierta rutina se ha vuelto demasiado grande, o está tratando de lograr demasiado, tiene que ser dividido en dos. Las cosas que no funcionan como la necesidad prevista tienen que ser eliminados o podadas.
De reescritura, reelaboración, y re-arquitectura de código se conocen colectivamente como refactorización.
Fuente : The Pragmatic Programmer, From Journeyman to Master
Comentarios