Acerca de esta serie

El objetivo de esta serie

perspectiva nueva a los conceptos tan
analizados frecuentemente pero a la vez
evasivos sobre la arquitectura y el diseo
de software. Mediante ejemplos
concretos, Neal Ford le brinda una base
slida en las prcticas giles de la
arquitectura evolutiva
emergente. Al postergar las decisiones
La arquitectura y el diseo de software generan mucho ruido, pero pocas nueces. Con el fin de analizar estos temas
desde una ptica nueva y alternativa, este artculo lanza la serie Arquitectura evolutiva y diseo emergente
arquitectura evolutiva y el diseo emergente son tcnicas giles para postergar las decisiones importantes hasta el
ltimo momento que la responsabilidad lo permita. En esta entrega introductoria Neal Ford, el autor de la serie, define
a la arquitectura y al diseo y luego identifica las distintas cuestiones relacionadas que surgirn a lo largo de esta
serie.
Neal Ford es software architect y Meme Wrangler en Thought Works, consultora de TI global. Tambin disea y desarrolla aplicaciones,
materiales instructivos, artculos para revistas, material de aprendizaje y presentaciones en video/DVD, y es autor o editor de libros que
abarcan una variedad de tecnologas, incluyendo el ms reciente The Productive Programmer [El programador productivo]
concentra en disear y construir aplicaciones de negocios de gran escala, y es un orador internacionalmente aclamado en las conferencias
para desarrolladores de todo el mundo. Consulte su Sitio Web.
05-04-2010
La arquitectura y el diseo en software durante mucho resistieron firmemente
cualquier definicin precisa porque el desarrollo de software como disciplina
todava no ha captado completamente todos sus vericuetos e implicancias,
pero para crear un discurso verbal razonable sobre estos temas, tenemos que
empezar por algn lugar. Los artculos de esta serie se ocupan de la
arquitectura evolutiva y del diseo emergente, por lo tanto tiene sentido
comenzar la serie con algunas definiciones, consideraciones y otros
conceptos bsicos.
Definicin de arquitectura
La arquitectura en software es uno de los conceptos sobre los que
ms se habla, sin embargo el que menos se comprende y con el
que luchan los desarrolladores. En conferencias, charlas y
reuniones de grupos informales de debate se le presta suma
atencin al tema de la arquitectura, pero seguimos teniendo apenas
unas vagas definiciones sobre ella. Cuando hablamos sobre
arquitectura, estamos refirindonos realmente a varios temas
developerWorks en espaol developerWorks en espaol Temas Tcnicos Temas Tcnicos tecnologia Java tecnologia Java Biblioteca tcnica Biblioteca tcnica
Arquitectura evolutiva y diseo emergente: Arquitectura evolutiva y diseo emergente:
Investigacin sobre arquitectura y diseo Investigacin sobre arquitectura y diseo
Descubriendo un diseo y una arquitectura ms fciles de mantener
Arquitectura evolutiva y diseo emergente: Investigacin sobre arquitect... http://www.ibm.com/developerworks/ssa/java/library/j-eaed1/
1 de 10 10/10/2014 12:35 p. m.
importantes sobre arquitectura y diseo
hasta el ltimo momento que la
responsabilidad lo permita, usted puede
evitar que la complejidad innecesaria
socave sus proyectos de software.
diferentes, pero relacionados entre s que generalmente se incluyen
en las categoras generales de arquitectura de aplicaciones y
arquitectura de negocios.
Arquitectura de aplicaciones
La arquitectura de aplicaciones describe las piezas de granularidad
gruesa que componen una aplicacin. En el mundo Java, por ejemplo, la arquitectura de aplicaciones
describe dos cosas: la combinacin de marcos usada para construir una aplicacin en particular a la
cual llamo la arquitectura a nivel marco y la separacin ms tradicional de cuestiones, a la que llamo
con el apodo applicationarchitecture (arquitectura de aplicacin). Es importante separar a la arquitectura
de marco para distinguir cuestiones, ya que la mayora de los que practican con lenguajes orientados a
objetos han descubierto que las clases individuales no funcionan bien como mecanismo de reutilizacin.
(Cundo fue la ltima vez que usted descarg una clase individual de Internet para usar en un
proyecto?). La unidad de reutilizacin en los lenguajes modernos orientados a objetos es la biblioteca o
el marco. Cuando usted inicia un proyecto nuevo en lenguajes de marco rico como el lenguaje Java, uno
de los primeros temas que concierne a la arquitectura es la arquitectura a nivel marco de la aplicacin.
Este estilo de reutilizacin prevalece de una manera tan arraiga en el mundo Java que comenc a decir
que deberamos dejar de referirnos a la programacin Java como un lenguaje orientado a objetos y
deberamos llamarlo lenguaje orientado a marcos. En muchos sentidos, la arquitectura a nivel marcos
representa una arquitectura fsica, descripta por bloques de construccin especficos.
El otro aspecto interesante de la arquitectura de aplicaciones describe cmo se ensamblan las piezas
lgicas de la aplicacin. Este es el reino de los patrones de diseo y de otras descripciones
estructurales, y por lo tanto tiende a ser ms abstracto y lgico que fsico. Por ejemplo, podemos decir
que una aplicacin Web adhiere a un patrn Modelo Vista Presentador sin especificar qu marco se usa
para lograr la configuracin lgica. Esta configuracin lgica es la que probablemente ms adorne las
pizarras de su espacio de trabajo cuando usted comienza a trabajar en partes nuevas de la aplicacin.
Arquitectura de negocios
La arquitectura de negocios se ocupa en s misma de la forma en que la empresa, en su totalidad, (que
generalmente significa las aplicaciones que se ejecutan internamente en una gran organizacin)
consume las aplicaciones. Una metfora til muy comn para indicar la relacin existente entre la
empresa y la arquitectura de aplicaciones compara a la empresa con la planificacin de una ciudad y a la
aplicacin con la arquitectura de edificaciones. Los planificadores de una ciudad deben pensar en
obtener agua, electricidad, cloacas y otros servicios que le permitan funcionar a la ciudad. No pueden
tener un edificio que consuma ms que su cuota de suministro de agua. La arquitectura de negocios
Arquitectura evolutiva y diseo emergente: Investigacin sobre arquitect... http://www.ibm.com/developerworks/ssa/java/library/j-eaed1/
2 de 10 10/10/2014 12:35 p. m.
considera las mismas clases de cosas para las aplicaciones: no podemos permitir que una aplicacin
consuma todo el ancho de banda de la red, y si los servicios de infraestructura colapsan, el desage
(virtual) hace la copia de seguridad.
La arquitectura de negocios ha captado mucha atencin en los ltimos aos debido a la Arquitectura
orientada a servicios (SOA). SOA es un tema profundo en todo su derecho, por lo tanto las entregas
futuras de esta serie lo abordarn como un caso especial, tiene aspectos de inters propios ya que
desdibuja la lnea que separa a la arquitectura de negocios y la arquitectura de aplicaciones al
determinar caractersticas de la construccin de aplicaciones.
Los prrafos anteriores ofrecen definiciones superficiales de estos conceptos importantes, pero sirven
como puntapi inicial para otras definiciones ms interesantes y ms especficas de la arquitectura,
incluyendo algunas definiciones obtenidas de otros.
Definiciones existentes
Mucha gente inteligente ha intentado definir a la arquitectura de software, as que les permitir que
nutran el pensamiento. En su clsico white paper "Who Needs an Architect?" [Quin necesita un
arquitecto?] (ver Recursos), Martin Fowler comenta varias definiciones, cita la primera de ellas de una
publicacin que apareci en una lista de distribucin sobre Programacin extrema:
"El proceso RUP, que se desprende de la definicin de IEEE, define a la arquitectura como 'el concepto de
ms alto nivel de un sistema en su entorno. La arquitectura de un sistema de software (en un
determinado punto en el tiempo) es su organizacin o estructura de componentes significativos que
interactan a travs de interfaces, estos componentes estn integrados sucesivamente por interfaces y
componentes ms pequeos.'"
Esta definicin se ajusta muy bien al mbito de la arquitectura de aplicaciones como describ
anteriormente. Aunque vaga, capta la esencia de la responsabilidad de la arquitectura: el concepto de
ms alto nivel.
Fowler luego cita a Ralph Johnson, quien objet la definicin anterior en una respuesta enviada a esa
lista de distribucin:
"Una definicin mejor sera: 'En la mayora de los proyectos de software exitosos, los expertos
desarrolladores que trabajan en el proyecto comparten una interpretacin del diseo del sistema de
diseo. Esta interpretacin compartida se llama "arquitectura." Esta interpretacin incluye cmo se
divide el sistema en componentes y cmo interactan los componentes a travs de las interfaces.'"
Johnson destaca algo muy importante, que el desarrollo de software se basa en la comunicacin ms
que en la tecnologa, y que la arquitectura realmente representa el conocimiento compartido sobre el
sistema, nada especficamente referido a lenguajes, marcos y otros temas tecnolgicos efmeros.
En el documento anteriormente mencionado, Fowler mismo brinda una de mis definiciones de
Arquitectura evolutiva y diseo emergente: Investigacin sobre arquitect... http://www.ibm.com/developerworks/ssa/java/library/j-eaed1/
3 de 10 10/10/2014 12:35 p. m.
arquitectura favoritas:
"La arquitectura se refiere a cosas importantes, cualesquiera que stas sean."
Esta definicin es apropiadamente difusa, pero tan descriptiva al mismo tiempo. Muchos de los
argumentos sobre arquitectura y diseo giran en torno a una interpretacin errnea de qu es
importante. Lo que es importante para los analistas de negocios difiere de lo que es importante para un
arquitecto de negocios. Esta definicin apunta muy bien a que debemos definir nuestros trminos
de nuestro entornoantes de intentar definir otras cosas.
La definicin de Fowler tambin destaca otro aspecto importante sobre la definicin de algo con tantos
matices como la arquitectura. "Cosas importantes" no slo vara entre las personas y los grupos; sino
que esas diferencias en realidad pueden ser mutuamente excluyentes. Por ejemplo, virtualmente todas
las arquitecturas SOA compensan recprocamente la flexibilidad y la velocidad. El viejo sistema
cliente/servidor que usted est usando ahora casi seguro es ms rpido que la versin basada en Web,
portlet-motor, basada en servicio que lo reemplaza. A menos que la aplicacin nueva haya sido escrita
por desarrolladores muy malos, las capas extra que brindan la flexibilidad implican un aumento en el
tiempo de respuesta a los usuarios, hacindola ms lenta para ellos. Quizs sea el arquitecto el que
deba decirle a los usuarios: "Ah, dicho sea de paso, esta nueva arquitectura SOA que estamos
instalando ser mejor para nosotros, pero su trabajo ahora ser ms lento. Disculpas." Tal vez sta sea
la razn por la cual se les paga ms a los arquitectos que a los desarrolladores.
Con lo cual queda mi definicin favorita de arquitectura:
"Cosas que son difciles de cambiar posteriormente."
Esta definicin se ajusta mejor a la idea de arquitectura evolutiva. Una de las ideas principales que
yacen detrs de la arquitectura evolutiva es la posibilidad de postergar definiciones todo lo que se
pueda, lo que permite reemplazar por alternativas superiores, segn lo demuestra la experiencia
reciente. Muchos de los bloques de construccin de este estilo de arquitectura aparecen a lo largo de
esta serie de artculos y motivaron la creacin de los mismos.
Antes de pasar a otro tema, sera una negligencia de mi parte no referirme al nombre del puesto
arquitecto. Enoja mucho a los sectores de recursos humanos que nosotros, como industria, tengamos
ttulos tan pobremente definidos. Muchas organizaciones desean ascender a sus mejores
desarrolladoresaquellos que toman decisiones importantes sobre las cosas que son difciles de
cambiar posteriormentepero no existe un buen trmino en la industria adems de "arquitecto".
Tampoco existe una descripcin comn del puesto, por lo tanto cada empresa define qu significa este
rol. Algunos de los arquitectos se parecen al Arquitecto que aparece al final de la pelcula Matrix II (que
Fowler categoriza como Architectus Reloadus). Estos arquitectos escribieron un cdigo por ltima vez
Arquitectura evolutiva y diseo emergente: Investigacin sobre arquitect... http://www.ibm.com/developerworks/ssa/java/library/j-eaed1/
4 de 10 10/10/2014 12:35 p. m.
hace una dcada y ahora estn tomando las decisiones importantes para su empresa. La nica
herramienta de desarrollo de software que usan es Visio.
La otra alternativa que existe para definir el rol de arquitecto es el que Fowler llama Architectus Oryzus
(llevan ese nombre por David Rice, uno de mis colegas). Estos arquitectos aportan activamente cdigo
al proyecto, a la par de otros desarrolladores que se ocupan de las partes ms difciles. Sus
responsabilidades tambin incluyen interactuar con otras partes interesadas del proyecto para
asegurarse de que todos hablen el mismo idioma, usen las mismas definiciones y comprendan las partes
del sistema que necesitan comprender. Obviamente este rol activo es esencial para alcanzar las metas
de la arquitectura evolutiva, y por lo tanto aparecer reiteradas veces en esta serie.
Definicin de diseo
La mayora de los desarrolladores ya tienen una idea muy clara del diseo, por lo tanto no dedicar
mucho tiempo a definirlo. Representa los elementos bsicos que demuestran cmo se ensamblan las
diferentes piezas que integran el software, incluye el terreno bien conocido como patrones de diseo,
refactorizacin, marcos y otras cuestiones que ataen diariamente a los desarrolladores. El diseo a
grandes rasgos entra en un espectro que abarca desde BDUF (Diseo completo desde el principio) y
Cowboy Hacking, como se muestra en la Figura 1:
Figura 1. Especto que abarca el diseo
El extremo izquierdo del aspecto que se muestra en la Figura 1 sugiere que usted puede anticipar todas
las cientos de miles de cuestiones que emergen cuando desarrolla software y trata de limitar sus
respuestas a las mismas. Usted leer mucho ms sobre este tema en las siguientes entregas. Que no
dedique mucho tiempo a definir el diseo no significa que no dedique mucho tiempo a hablar sobre l. La
mayor parte de esta serie cubre diferentes aspectos sobre la forma en que puede emerger el diseo
cuando usted desarrolla en lugar de considerarlo algo fijo e inalterable antes de escribir su primera lnea
de cdigo.
Temas esenciales sobre arquitectura y diseo
Arquitectura evolutiva y diseo emergente: Investigacin sobre arquitect... http://www.ibm.com/developerworks/ssa/java/library/j-eaed1/
5 de 10 10/10/2014 12:35 p. m.
Evolutivo contra
Observe que esta serie se llama
arquitectura Evolutiva
emergente. Por qu hacemos esta
distincin entre evolutivo
La arquitectura emergente, como me
sealaba uno de mis colegas, no es una
idea tan apasionante. Si aceptamos la
premisa de que la arquitectura se refiere
a cosas que son difciles de cambiar
posteriormente, se dificulta entonces la
idea de que una arquitectura pueda
emerger. La arquitectura se preocupa de
los elementos de infraestructura que
deben existir antes de que usted inicie la
aplicacin. Sin embargo, slo porque
usted no puede dejar que la arquitectura
emerja, no significa que sta no pueda
evolucionar. Si usted cre una
arquitectura flexible y se ocup de crear
una decisin que no sea irreversible,
puede permitirle que evolucione en el
tiempo a medida que surjan nuevos
temas a considerar.
Habiendo definido a la arquitectura y al diseo, ahora quiero
profundizar en las pocas reas que abarcan los asuntos de inters.
Todos estos temas se relacionan con la arquitectura y el diseo a
un nivel fundamental, por lo tanto referirme a ellas desde el
principio me permite volver luego a ellas posteriormente en esta
serie. Primero, hablar sobre deuda tcnica, luego sobre
complejidad y por ltimo sobre la tan mentada calidad de genrico.
Capital e intereses
Todo desarrollador es consciente del concepto de deuda tcnica,
mediante el cual uno realiza compromisos en su diseo en pos de
alguna fuerza externa, por ejemplo la presin de un cronograma. La
deuda tcnica se parece a la deuda de una tarjeta de crdito, al
momento uno no tiene suficientes fondos, por lo tanto los pide
prestados contra un pago futuro. De igual manera, su proyecto no
tiene suficiente tiempo para hacer algo correcto, entonces usted
obtiene una solucin justo a tiempo y espera usar algn tiempo
futuro para volver a ella y modernizarla. Lamentablemente, muchos
gerentes parecen no comprender qu significa la deuda tcnica,
ofreciendo resistencia cuando se trata de volver al trabajo que
efectuaron en el pasado.
Construir software no es como cavar una zanja, si usted asume compromisos cuando hace una zanja,
slo logra un ancho irregular o una profundidad desigual. La zanja defectuosa de hoy no le impide cavar
una zanja buena maana, pero el software que construye hoy es la base para lo que construir maana.
Los compromisos que se hacen ahora por conveniencia hacen que se cree entropa en su software. En
el libro The Pragmatic Programmer [El programador pragmtico], Andy Hunt y Dave Thomas hablan
sobre la entropa en el software y por qu tiene un efecto tan perjudicial (ver Recursos). La entropa es
una medicin de la complejidad, y si usted agrega complejidad ahora debido a una solucin justo a
tiempo para un problema, usted debe pagar algn precio por ello para el resto de vida que le queda al
proyecto.
Supongamos que usted desea agregar nuevas caractersticas a un proyecto existente que hace tiempo
que se est ejecutando. Estas caractersticas nuevas tienen una cierta complejidad inherente a ellas. Sin
embargo, si usted ya tiene una deuda tcnica, debe trabajar en funcin de esas partes comprometidas
del sistema para agregar caractersticas nuevas. Por ende, el costo de los agregados se asemeja a la
Arquitectura evolutiva y diseo emergente: Investigacin sobre arquitect... http://www.ibm.com/developerworks/ssa/java/library/j-eaed1/
6 de 10 10/10/2014 12:35 p. m.
metfora financiera. La Figura 2 muestra la diferencia entre el esfuerzo requerido para agregar una
caracterstica nueva en un sistema diseado de manera limpia (por ejemplo, uno con poca o ninguna
deuda tcnica), contra un sistema tpico que contiene un montn de deuda tcnica.
Figura 2. Deuda tcnica e intereses
Podemos pensar en la complejidad inherente como el capital, y en el esfuerzo extra impuesto por los
atajos previos para ahorrar tiempo como los intereses. La complejidad en s misma es un tema
interesante.
Complejidad esencial contra complejidad accidental
Los problemas que resolvemos en software tienen una complejidad intrnseca, a la que llamo
complejidad esencial. La complejidad que surge de los compromisos que hacemos que generan deuda
tcnica es diferente, consta de todos los medios externos por los cuales el software se torna complejo y
no debera existir en un mundo perfecto. Llamo a esto complejidad accidental. Defino y hablo en
profundidad sobre estos trminos en mi libro The Productive Programmer (ver Recursos
generalmente no son sumamente concretos, existen en un espectro de temas, como el diseo. Algunos
ejemplos ayudarn a clarificar la distincin.
Uno de mis colegas trabaj en un sistema de sueldos para una empresa agremiada. Una de las
concesiones que el sindicato aseguraba para algunos de sus miembros era un da libre extra al
comienzo de la temporada de caza. (Seguramente habrn tenido muy buenos negociadores.) Los
empleados en cuestin trabajaban slo en una de las fbricas, pero computar el da libre extra era una
parte legtima del sistema de sueldos de toda la empresa. Este cambio agregaba un montn de
complejidad al software, pero era una complejidad esencial porque formaba parte del problema de la
empresa que haba que resolver.
Otro ejemplo un poco ms alejando en el espectro emerge todo el tiempo: seguridad a nivel campo en
los formularios de entrada. Mucha gente de negocios piensa que quiere un control de granularidad fina
de cada una de las caractersticas de seguridad del campo. En realidad, casi siempre odian esto cuando
Arquitectura evolutiva y diseo emergente: Investigacin sobre arquitect... http://www.ibm.com/developerworks/ssa/java/library/j-eaed1/
7 de 10 10/10/2014 12:35 p. m.
se implementa porque crea una carga de gran magnitud en los usuarios que deben definir y mantener
todos los metadatos. La gente de negocios en uno de nuestros proyectos realmente quera esta
caracterstica, as que implementamos parte de la misma en una de las pantallas para ellos. Cuando
vieron en primera instancia cunto esfuerzo se requera para que funcionara esa caracterstica,
decidieron que como el nico acceso a la aplicacin era desde una oficina cerrada con llave, podan
seguir con ms seguridad de granularidad fina. Este es un ejemplo claro de una decisin de diseo que
emergi cuando el negocio vio la realidad de lo que pensaban que queran.
En el extremo ms apartado del aspecto hacia la complejidad accidental hay meros ejercicios de
fontanera como las primeras dos versiones de la tecnologa Enterprise JavaBeans (EJB) y herramientas
como BizTalk. Unos pocos proyectos necesitan los gastos generales extra generados por estas
herramientas, pero no hacen nada ms que agregar complejidad a la mayora de los proyectos que las
usan.
Tres cosas tienen a propagar la complejidad accidental. Ya he hablado sobre la primera: las alteraciones
de cdigo justo a tiempo debido al cronograma a cumplir u otras presiones externas. La segunda es la
duplicacin, aquello a lo que los Programadores pragmticos llaman violaciones al principio DRY (No te
repitas). La duplicacin es la fuerza individual que ms perjudica al desarrollo de software porque se las
ingenia para propagarse a muchos lugares sin que los desarrolladores se den cuenta de ello. El ejemplo
obvio es el cdigo copy-and-paste (copiar y pegar), pero abundan los ejemplos ms sofisticados. Por
ejemplo, casi todos los proyectos que usan una herramienta de mapeo relacional de objetos (como
Hibernate o iBatis) tienen montones de duplicaciones. Su esquema de base de datos, el archivo de
mapeo XML, y los objetos POJO de respaldo tienen informacin levemente diferente, pero que se
superpone. Es posible arreglar esto mediante la creacin de una fuente cannica para esa informacin y
la generacin de otras partes. La duplicacin afecta a los proyectos porque se resiste a los intentos de
realizar cambios estructurales o refactorizar en pos de un cdigo mejor. Si usted sabe que necesita
cambiar algo en tres lugares diferentes, evitar hacerlo an cuando esto mejorara el cdigo a largo
plazo.
El tercer facilitador de la complejidad accidental es la irreversibilidad. Cualquier decisin que usted
adopte que no pueda revertirse eventualmente conducir a cierto nivel de complejidad accidental. La
irreversibilidad afecta tanto a la arquitectura como al diseo, aunque sus efectos son ms comunes y
ms perjudiciales a nivel arquitectura. Trate de evitar decisiones que sean imposibles o engorrosas de
revertir. Uno de los mantras que escuch usar a un colega es esperar hasta el ltimo momento que la
responsabilidad lo permita. Esto no significa que usted deba postergar decisiones por mucho tiempo,
pero s por un perodo lo suficientemente prolongado. En qu ltimo momento que la responsabilidad lo
Arquitectura evolutiva y diseo emergente: Investigacin sobre arquitect... http://www.ibm.com/developerworks/ssa/java/library/j-eaed1/
8 de 10 10/10/2014 12:35 p. m.
permita usted puede tomar una decisin sobre una cuestin de arquitectura? Cuanto ms pueda evitar la
decisin, mayores posibilidades dejar abiertas para usted. Pregntese a si mismo: "Necesito tomar
esta decisin ahora?" y "Qu puedo hacer para poder diferir esta decisin?" Se sorprender de las
cosas que puede diferir si tan solo aplica cierta ingenuidad a su proceso de toma de decisiones.
La distincin que hice anteriormente entre arquitectura a nivel marco y arquitectura de aplicaciones se
relaciona con el principio del ltimo momento que la responsabilidad lo permita. La arquitectura de
aplicaciones tiene a ser una arquitectura lgica. Por ejemplo, supongamos que usted quiere separar las
cuestiones del patrn Modelo Vista Presentador. A menudo, usted salta a una implementacin fsica de
la arquitectura lgica eligiendo un marco que cumpla con algunos o todos los requisitos. Vea si puede
diferir esa decisin porque una vez que ha efectuado la implementacin fsica, sta limita las otras
clases de decisiones que usted debe considerar. Postergar la decisin de marco todo lo que pueda, le
ofrece mejores opciones que estn menos contaminadas por la realidad.
La mentada calidad de genrico
El ltimo de los temas que preocupan a la arquitectura y al diseo es una expresin que invent y a la
cual llamo la mentada calidad de genrico. Parece que tenemos una enfermedad en el mundo Java:
soluciones con sobrecarga de ingeniera que intentan hacerlas lo ms genricas posible. La motivacin
para esto es clara: si construimos en muchas capas para ampliacin, ms fcilmente podremos construir
sobre ellas posteriormente. Sin embargo, esta es una trampa peligrosa porque la cualidad de genrico
agrega entropa, usted daa su capacidad de hacer evolucionar el diseo de maneras interesantes en la
etapa inicial del proyecto. Agregar demasiada flexibilidad hace que cada cambio al cdigo base sea ms
complejo.
Por supuesto que usted puede ignorar la extensibilidad. El movimiento gil tiene una frase maravillosa
que resumen el proceso de decisin para la implementacin de caractersticas: YAGNI (No lo vas a
necesitar). Este es el mantra para evitar sobrecargar de ingeniera a las caractersticas simples. Slo
implemente exactamente lo que necesita ahora, y si necesita ms cosas ms adelante, puede
agregarlas llegado el momento. He visto algunos proyectos Java tan recargados de compromisos en
arquitectura y diseo, en la cima de la calidad de genrico y extensibilidad, que los proyectos fracasaron.
Por supuesto esto es irnico porque planificar para que el proyecto viva todo lo posible es lo que trunc
su vida. Aprender a transitar la delgada lnea que separa a la extensibilidad de la sobrecarga de
ingeniera no es fcil, y es un tema al que volver a menudo.
Mapa de ruta
Este artculo contiene un montn de conceptos pero ningn cdigo fuente, hecho que lo distingue de
Arquitectura evolutiva y diseo emergente: Investigacin sobre arquitect... http://www.ibm.com/developerworks/ssa/java/library/j-eaed1/
9 de 10 10/10/2014 12:35 p. m.
Recursos
Aprender
"Who Needs an Architect?" (Martin Fowler, IEEE Software, septiembre de
2003): Lea el clsico white paper de Fowler.
The Productive Programmer (Neal Ford, O'Reilly Media, 2008)): El ltimo libro
de Neal Ford se explaya sobre varios temas incluidos en este artculo.
The Pragmatic Programmer (Andy Hunt y Dave Thomas, The Pragmatic
Bookshelf, 2001): Este libro incluye un debate sobre el efecto de la entropa
en el software.
Essential XP: Emergent Design [XP esencial: Diseo emergente] (Ron
Jeffries): debate Web sobre consideraciones del diseo emergente en el
mundo de la programacin extrema.
"Emergent Optimization in Test Driven Design" [Optimizacin emergente en el
Diseo impulsado por pruebas] (Michael Feathers): Cmo ayudan las
pruebas a evitar la optimizacin prematura.
Navegue en la librera de tecnologa para ver los libros que se encuentran
disponibles sobre stos y otros temas tcnicos.
developerWorks Java technology zone (Zona de tecnologa developerWorks
Java): encuentre cientos de artculos sobre cada uno de los aspectos que
hacen a la programacin Java.
Comentar
Consulte los blogs developerWorks y participe en la comunidad
developerWorks community.
IBM PureSystems
La nueva familia de sistemas
expertos integrados de IBM est
aqu.
La carrera ha comenzado!
Obtenga WAS para
desarrolladores sin costo.
Descarga gratuita:
Rational Team Concert for Power
Systems Software Standard
Edition
todos los otros artculos que siguen en esta serie. Uno de los problemas inherentes a la descripcin de
temas complejos como la arquitectura y el diseo es la determinacin del contexto que tiene que darse
para asegurarnos que todos estemos hablando de lo mismo. He presentado el contexto para desarrollar
el resto de las partes que integran esta serie, en donde profundizar en reas especficas relacionadas
con la arquitectura evolutiva y el diseo emergente. Cada artculo se abocar en profundidad a un
aspecto ilustrativo particular de uno o ambos de estos conceptos, con muchos detalles y cdigo fuente.
Prximamente: hablar sobre diseo emergente a travs de un desarrollo impulsado por pruebas, al que
le cambi y ahora llamo diseo impulsado por pruebas.
Arquitectura evolutiva y diseo emergente: Investigacin sobre arquitect... http://www.ibm.com/developerworks/ssa/java/library/j-eaed1/
10 de 10 10/10/2014 12:35 p. m.