El diseño es una cosa hermosa. Una presentación detallada y sistemática y una revisión del contexto del problema, pone a la luz errores y oportunidades de mejora, algunas veces de forma sorprendentemente dramática. Las especificaciones son importantes porque proporcionan un patrón de construcción.
Es importante tomarse un tiempo para pensar en la arquitectura, a nivel superior vislumbrando las interacciones entre los componentes y a bajo nivel vislumbrando el comportamiento interno de cada uno de ellos.
Desafortunadamente, es demasiado fácil verse envuelto en el proceso de diseño, cautivado por la arquitectura en su forma abstracta. De hecho las especificaciones solas, no tienen valor.
El objetivo final de un proyecto software es el sistema de producción. Un arquitecto software nunca ha de perder la vista en ese objetivo, recordando que el diseño es simplemente un medio para el final, no el final en sí mismo. El arquitecto de un rascacielos que ignora las leyes físicas por hacer más bonito su edificio, lamentará pronto ese hecho. Perder la vista, del objetivo final del código, se puede traducir en graves problemas, para cualquier proyecto.
Valore a los miembros del equipo que trabajan implementando su visión. Escúchelos. Cuando tengan problemas con el diseño, puede que tengan razón y que el diseño sea erróneo, o al menos sea poco claro. Es su trabajo, para estos casos, modificar el diseño para cubrir las limitaciones del mundo real, trabajando codo a codo con los miembros del equipo, para ver lo que funciona y lo que no.
Ningún diseño es perfecto al inicio, todos los diseños necesitan ser modificados durante su implementación.
Si usted también es desarrollador del proyecto, valore el tiempo que invierte escribiendo código, y no crea a nadie que le diga que eso es una distracción para su trabajo como arquitecto. Después de todo, su visión de alto y bajo nivel, puede verse mejorada por el tiempo que dedique a estar en las entrañas de la bestia que está trayendo a la vida.
Autor Allison Randal
Versión original en : One line of working code is worth 500 of specification
De hecho todo diseño original, acaba modificado al final de un proyecto; el hecho de tener la responsabilidad del diseño y la implementación, no nos hace poseedores de la razón absoluta; cualquier miembro del equipo (o nosotros mientras reflexionamos) puede detectar fallos en el diseño en cualesquiera de las fases, en las que se encuentre el producto, y esta capacitado para hacer observaciones y sugerir mejoras; después de todo lo hacen por el bien del proyecto.
Es nuestra responsabilidad, evaluar la situación actual y determinar, - si se aplica - cuando y como hacerlo (por ejemplo en la siguiente iteración o versión del producto); si se puede, claro esta!
Emmerson.
- FIN -
No comments:
Post a Comment