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.