La arquitectura del software está sobrevalorada, el diseño simple se subestima

Le ofrecemos la traducción de la publicación de Gergel Oros, quien ocupa el cargo de Gerente de Ingeniería en Uber. En él, comparte su punto de vista sobre el diseño de sistemas a gran escala, basado en su propia experiencia práctica en Uber y Microsoft. Combinado con comentarios en Hacker News , que agregan contraargumentos de peso y complementan el punto de vista del autor, su artículo se ha convertido en una de las publicaciones más interesantes de la semana. El término "diseño de código" se utiliza en el artículo para compararlo con la "arquitectura" tradicional; aquí se puede encontrar más información al respecto.

Tengo suficiente experiencia en el diseño y creación de sistemas a gran escala. Participé en la reescritura del sistema de pago distribuido en Uber, diseñando y lanzando Skype en Xbox One, y lanzando los RIB disponibles públicamente, un marco de arquitectura móvil creado por Uber. Todos estos sistemas tenían un diseño cuidadosamente pensado, pasaron por varias iteraciones, y se celebraron muchas reuniones en la pizarra, y otras discusiones. Luego, el diseño creó un documento de diseño, que se distribuyó entre otros desarrolladores para recopilar comentarios adicionales, que continuó hasta que pasamos al desarrollo.

Todos estos sistemas eran a gran escala: cientos de desarrolladores los crearon, o los usaron en sus diseños, y hoy golpean los corazones de los sistemas que millones de personas usan todos los días. Además, estos proyectos no fueron creados desde cero. Se suponía que el sistema de pago reemplazaría a otros dos sistemas de pago existentes utilizados por docenas de otros sistemas y docenas de equipos, todo sin dañar el negocio. La reescritura de la aplicación Uber fue un proyecto en el que trabajaron varios cientos de ingenieros al mismo tiempo, e incluyó portar todas las funcionalidades existentes a la nueva arquitectura.

Permítanme comenzar con algo que puede sonar inesperado. Primero, nunca usamos herramientas de planificación de arquitectura de software estándar para trabajar en los diseños de estos sistemas. No utilizamos ni UML , ni el modelo 4 + 1 , ni ADR , ni C4 , ni los diagramas de dependencia . Dibujamos muchos diagramas, pero ninguno de ellos siguió reglas estrictas. Solo se necesitaban rectángulos y flechas viejos y buenos, y obtuvimos diagramas similares a este, que describe los flujos de información , u otro, que representa la estructura de la clase y la relación entre los componentes . Dos gráficos en el mismo documento de diseño a menudo tenían un estilo diferente, ya que a menudo los agregaban o editaban diferentes personas.

En segundo lugar, no teníamos arquitectos que fueran dueños del diseño. No había ni arquitecto de TI ni arquitecto de empresa . Esto es cierto: ni Uber ni Skype / Mircrosoft tienen una posición de tiempo completo para los arquitectos de software. Todavía se espera que los ingenieros de nivel superior, como aquellos en el puesto de Ingeniero de personal, escriban código regularmente. Todos nuestros proyectos tienen ingenieros experimentados; sin embargo, ni una sola persona posee arquitectura o diseño solo. Si bien los ingenieros experimentados fueron la fuerza impulsora detrás del proceso de diseño, otros desarrolladores participaron en la discusión, incluido incluso el "junio" verde; además, a menudo desafiaron las decisiones de los demás y presentaron opciones alternativas para la discusión.

En tercer lugar, casi nunca nos referimos a patrones arquitectónicos comunes y otras jergas generalmente aceptadas, que se utilizan en la literatura popular sobre arquitectura de software como el manual de Martin Fowler . No hubo referencias a microservicios, arquitectura sin servidor, límites de aplicaciones , arquitectura controlada por eventos, o cualquier otra cosa. Algunos de estos términos surgieron durante las sesiones de lluvia de ideas; sin embargo, no tuvimos necesidad de referirnos a ellos mismos en la documentación de diseño.

Diseño de software en empresas tecnológicas y startups

Entonces, ¿cómo lidiamos con todo? ¿Y por qué no seguimos enfoques comunes para la arquitectura de software?

Discutí este problema con otros ingenieros que trabajan en otras compañías de tecnología, tanto en tamaños FANG (Facebook, Amazon, Netflix, Google) como en pequeñas empresas. La mayoría de los equipos y proyectos, ya sean grandes o pequeños, combinaron un enfoque similar para el diseño y la implementación:

1. Comience con una tarea comercial. ¿Qué problema estamos tratando de resolver? ¿Qué producto estamos tratando de crear y por qué? ¿Cómo podemos medir su éxito?
2. Lluvia de ideas para el "enfoque" elegido. Reúnase con el equipo y encuentre una solución de trabajo en unas pocas sesiones. No se demore demasiado con esta fase. Comience desde el nivel superior y baje gradualmente hasta los niveles inferiores.
3. Dibuje su enfoque en la pizarra. Reúna al equipo y deje que uno de ustedes describa el enfoque al que se inclina el equipo. Debería poder explicar claramente la arquitectura de su sistema / aplicación con la ayuda de una placa, comenzando desde el nivel más alto y, si es necesario, bajando más y más. Si tiene dificultades con alguna explicación o no es lo suficientemente clara para sus colegas, entonces necesita resolver mejor los detalles de su decisión.
4. Arregle en forma de documentación simple con diagramas simples basados ​​en lo que explicó anteriormente con la pizarra. Mantenga la jerga al mínimo: desea que incluso los jóvenes entiendan lo que se dice. Use un lenguaje claro y fácil en su descripción . En Uber, utilizamos un documento similar a RFC basado en una plantilla simple.
5. Discutir compensaciones y alternativas . Un buen diseño de software y una buena arquitectura son la elección correcta para las compensaciones. En sí mismo, ninguna de las opciones de diseño es mala o buena: todo depende del contexto y los objetivos. ¿Su arquitectura está dividida en diferentes servicios? Mencione por qué decidió no hacer un gran servicio, para lo cual podría haber otras ventajas, como una implementación más simple y rápida. ¿Ha decidido expandir el módulo o servicio con una nueva funcionalidad? En cambio, evalúe la posibilidad de desarrollar un servicio o módulo separado, y cuáles son los pros y los contras de este enfoque.
6. Distribuya el documento de diseño dentro del equipo / organización y recopile comentarios. Anteriormente, en Uber, enviamos todos los documentos de diseño para el software a todos nuestros ingenieros , hasta el momento en que nuestro personal creció a 2,000 personas. Ahora que hemos crecido a tal escala, todavía estamos tratando de llegar a la mayor audiencia posible, pero al mismo tiempo hemos comenzado a asegurarnos de que el nivel de ruido de la información no exceda el límite permitido. Anime a otros a hacer preguntas y sugerir alternativas. Sea pragmático sobre los límites de tiempo para analizar los comentarios e incluirlos en el documento cuando sea necesario. Se pueden aplicar deseos específicos de forma inmediata y rápida, mientras que la retroalimentación detallada es mejor desmontar con una persona en persona.

¿Por qué nuestro enfoque es diferente de lo que se menciona generalmente en la literatura sobre arquitectura de software? De hecho, nuestro enfoque fundamentalmente no es tan diferente de lo que se describe en los manuales de arquitectura. Casi todos los manuales sugieren comenzar con una tarea comercial, así como describir soluciones y compensaciones; nosotros también lo hacemos. Lo que no estamos haciendo es no usar herramientas más sofisticadas por las que abogan muchos arquitectos y libros de arquitectura. Documentamos el diseño de la manera más simple posible, utilizando las herramientas más simples y obvias, como Google Docs u Office 365.

Creo que la principal diferencia en nuestro enfoque se debe a la cultura de ingeniería de diferentes compañías. Un alto grado de autonomía y una jerarquía minimizada es una característica común entre las empresas de tecnología moderna y las nuevas empresas; En el caso de las empresas más tradicionales, esto está lejos de ser siempre cierto. Esta es también la razón por la cual en estos lugares a menudo recurren al "diseño basado en el sentido común" en lugar del diseño basado en un proceso con reglas estrictas.

Sé que los bancos y las compañías automotrices, donde los desarrolladores se ven activamente desalentados de tomar decisiones arquitectónicas sin tener que ascender en la cadena, obtienen la aprobación de arquitectos de varios niveles más altos, que supervisan varios equipos. Esto hace que el proceso sea más lento y, con una gran cantidad de solicitudes, los arquitectos se sobrecargan. Por lo tanto, estos arquitectos crean documentos aún más formales, con la esperanza de que el sistema sea más comprensible, utilizando todas las herramientas que la literatura familiar le describe. Estos documentos están respaldados por un enfoque de arriba hacia abajo, ya que actúa de manera intimidante para los ingenieros; después de todo, no son arquitectos y no deben dudar ni disputar decisiones, porque ya se han documentado utilizando métodos formales en los que están poco versados. Por lo tanto, generalmente no lo hacen. Honestamente, estas compañías hacen lo mismo para hacer que los desarrolladores sean un recurso intercambiable, ya que esto les permite transferir personas de un proyecto a otro en poco tiempo. Probablemente no sea una sorpresa para usted que diferentes herramientas sean más adecuadas para diferentes entornos.

Diseño de software simple sin jerga en lugar de patrones arquitectónicos.

El objetivo del diseño del sistema debe ser la simplicidad. Cuanto más simple es el sistema, más fácil es comprenderlo y más fácil es encontrar problemas en él, así como implementarlo. Cuanto más claro sea el lenguaje por el cual se describe, más accesible será su diseño. Evite usar jerga que todos los miembros del equipo no entiendan, incluso los colegas más inexpertos deberían poder entender lo que está en juego a nivel de los demás.

Un diseño limpio es como un código limpio: es fácil de leer y fácil de entender. Hay muchas formas excelentes de escribir código limpio. Sin embargo, a menudo escuchará que alguien sugiere comenzar con la aplicación de patrones de diseño "pandilla de cuatro" a su código. El código limpio comienza con el principio de responsabilidad exclusiva, nombres claros y convenciones fáciles de entender. Estos principios se aplican igualmente a la arquitectura pura.

Entonces, ¿cuál es el papel de los patrones arquitectónicos? Los encuentro útiles, tan útiles como los patrones de diseño de código. Pueden darle ideas sobre cómo puede mejorar su código o arquitectura. Tome los patrones de diseño del código: me doy cuenta de mí mismo cuando noto un singleton en el código, y levanto las cejas y profundizo cuando veo una clase que se comporta como una fachada , pero en realidad solo hace llamadas. Pero aún no ha llegado el día en que hubiera pensado: "una fábrica abstracta simplemente lo solicita aquí". En verdad, me llevó mucho tiempo descubrir qué hace este patrón y antes de que me diera cuenta; La comprensión se produjo como resultado del trabajo duro con la inyección de dependencia , una de las pocas áreas en las que este patrón es generalizado y extremadamente útil . También admito que, aunque pasé mucho tiempo leyendo y comprendiendo los patrones de diseño de la "pandilla de cuatro", tuvieron mucha menos influencia en mi desarrollo profesional como programador que los comentarios que recibí de otros desarrolladores con respecto a mi código.

Del mismo modo, conocer patrones arquitectónicos comunes es algo bueno: ayuda a reducir el tiempo dedicado a las discusiones con personas que los entienden de la misma manera que usted. Pero los patrones arquitectónicos no son el objetivo, y no serán un sustituto de opciones de diseño de sistema más simples. Cuando diseña un sistema, puede darse cuenta de repente de que aplicó accidentalmente algún patrón común, y esto es bueno, porque más tarde le será más fácil referirse al enfoque utilizado. Pero nunca debe tomar uno o más patrones y usarlos como un martillo, para lo cual siempre verá las uñas.

Los patrones arquitectónicos surgieron cuando los ingenieros llamaron la atención sobre el hecho de que en ciertas situaciones tiene sentido tomar decisiones similares con respecto al diseño y su implementación. Con el tiempo, estas decisiones recibieron nombres, fueron grabadas y discutidas por el público en general. Los patrones arquitectónicos son herramientas que aparecieron después de encontrar soluciones, con la esperanza de que esto ayude a facilitar la vida de los demás. Como ingeniero, debe establecer como objetivo una búsqueda independiente de soluciones a sus problemas y aprender durante este proceso, en lugar de adoptar un patrón arquitectónico "exagerado" con la esperanza de que esto resuelva su problema.

Cómo aprender a diseñar mejores sistemas

La gente a menudo me pide consejos: ¿cómo "bombear" en la arquitectura y el diseño de sistemas? Los ingenieros experimentados generalmente recomiendan leer sobre patrones arquitectónicos, así como libros sobre arquitectura de software. Apoyo totalmente la recomendación de leer tanto como sea posible, especialmente libros, porque te permiten profundizar en el tema mucho más profundo que las publicaciones cortas, sin embargo, tengo varias recomendaciones prácticas más.

• Involucre a uno de los miembros del equipo y hagan pizarra juntos. Dibuje en la pizarra en qué está trabajando y explique el significado de la imagen. Asegúrese de que sus colegas entiendan lo que se dice. Y cuando finalmente lo entiendan, pida retroalimentación.
• Describa su diseño en un documento simple y compártalo con su equipo, solicitándoles comentarios. No importa cuán simple o compleja sea la tarea en la que está trabajando; puede ser una pequeña refactorización o un proyecto a gran escala, debe resumirla de manera concisa. Hágalo de tal manera que para usted este documento tenga sentido, y para el resto es comprensible; en busca de inspiración: aquí hay un ejemplo de cómo se hace esto en Uber . Comparta este documento con su equipo en un formato que permita comentar, por ejemplo, usando Google Docs, Office 365 o algo similar. Pídale a otros que lo complementen con sus pensamientos y preguntas.
• Crea dos diseños diferentes y compáralos. Cuando la mayoría de nosotros diseñamos arquitectura, generalmente van en un sentido: el que aparece en su cabeza. Sin embargo, la arquitectura no es algo en blanco y negro. Cree una segunda opción de diseño de arquitectura que también podría funcionar en su situación. Contrasta ambos diseños y explica por qué uno es mejor que el otro. Indique que ha considerado la segunda opción por algún tiempo como una alternativa, y explique por qué tomó una decisión que no está a su favor.
• Decida los compromisos que está dispuesto a hacer: descubra por qué los acepta y qué quiere lograr con su ayuda. Establezca claramente las restricciones existentes que se vio obligado a tener en cuenta.
• Realizar una revisión de los diseños de otras personas. Y hazlo sabiamente. Si su empresa tiene una cultura de compartir diseños que las personas comparten usando pizarras, reuniones o documentos, obtenga más de ellos. Por lo general, durante una revisión, las personas perciben el diseño del código de otra persona como observadores; en su lugar, haga preguntas aclaratorias para las partes que no comprende del todo. Pregunte qué alternativas consideraron. Pregunte qué compromisos hicieron y qué limitaciones consideraron. Sea el defensor del diablo y sugiera otra alternativa, posiblemente más simple, incluso si no es mejor que su solución, y pregúnteles qué piensan acerca de su propuesta. Aunque no haya pensado su diseño tan bien en comparación con el que lo presenta, su discusión aún puede aportar algo nuevo y ayudarlo a comprender mejor la tarea que está realizando.

El mejor diseño de software es simple y fácil de entender. La próxima vez que comience un nuevo proyecto, en lugar de reflexionar sobre la pregunta: " ¿Cómo diseñaré este sistema, qué patrones debería usar en la batalla y con qué metodología formal debería documentarlo? ", Piense: " ¿Cómo puedo llegar al diseño más simple posible, uno que sea fácil de entender para todos? "

Las mejores prácticas de la arquitectura de software, los patrones arquitectónicos de las aplicaciones empresariales, las formas formales de describir los sistemas son todas herramientas útiles para poseer, porque un día pueden ser muy útiles para usted. Pero al diseñar sistemas, vale la pena comenzar con uno simple y continuar siendo lo más simple posible. Intente evitar la complejidad que las arquitecturas más complejas y las herramientas formales inevitablemente aportan a sus sistemas.

Esta publicación provocó una acalorada discusión entre los trabajadores de la industria que compartieron sus experiencias y actitudes hacia la arquitectura de software. Puede leer estas discusiones en Hacker News , Lobste.rs y Reddit .

Mientras que la mayoría de los comentaristas están de acuerdo con el mensaje principal del artículo, otros notan que en realidad ese enfoque puede ser poco aplicable al mundo de la "empresa sangrienta", donde los arquitectos "comen su pan" por una buena razón; — 20 « », 300 IT- , — API, 5000 7000 .