¿Cómo dejo de diseñar y empiezo a diseñar este proyecto según lo sugerido por mi líder? [cerrado]

Soy un desarrollador junior (~ 3 años de experiencia) y en mi trabajo estamos en el proceso de diseñar un nuevo sistema. Mi desarrollador principal será el arquitecto principal, sin embargo, me desafió a intentar diseñar el sistema yo mismo (en paralelo).

En el transcurso de algunas iteraciones de ideas de ideas y de proponer lo que vi como sugerencias de arquitectura, mi líder me ha dado la respuesta de que la mayoría de lo que he estado haciendo fue "diseñar" y no "diseñar".

Describió la diferencia como que la arquitectura es independiente de la implementación, mientras que un diseño es la descripción de una implementación. Dijo que necesito quitarme el sombrero de diseñador y ponerme el sombrero de arquitecto. Me dio un pequeño consejo sobre cómo hacerlo, pero también me gustaría preguntarte:

¿Cómo salgo del modo de diseñador de software y empiezo a pensar más como un arquitecto?

Aquí hay algunos ejemplos de "diseños" que se me ocurrieron y que mi líder no consideró relevantes para la arquitectura:

1. Se me ocurrió un algoritmo para cargar y descargar recursos de nuestro sistema y mi líder dijo que los algoritmos categóricamente no son arquitectura.
2. Se me ocurrió una serie de eventos que el sistema debería generar y en qué orden debería generarlos, pero esto tampoco parecía cortarlo como arquitectura.

Parece que estoy atrapado en los detalles y no retrocedo lo suficiente. Encuentro que incluso cuando se me ocurre algo que está en el nivel de la arquitectura, a menudo llego allí probando varias implementaciones y analizando los detalles y luego generalizando y abstrayendo. Cuando describí esto a mi liderazgo, dijo que estaba tomando el enfoque equivocado: necesitaba pensar "de arriba abajo" y no "de abajo hacia arriba".

Aquí hay algunos detalles más específicos sobre el proyecto :

• El proyecto que estamos diseñando es una aplicación web.
• Estoy estimando alrededor de 10-100 mil líneas de código.
• Somos una nueva empresa. Nuestro equipo de ingeniería es de aproximadamente 3-5 personas.
• Lo más parecido a lo que podría comparar nuestra aplicación es un CMS liviano. Tiene una complejidad similar y se ocupa en gran medida de la carga y descarga de componentes, la gestión del diseño y los módulos de estilo de complemento.
• La aplicación es ajax-y. El usuario descarga el cliente una vez y luego solicita los datos que necesita del servidor.
• Usaremos el patrón MVC.
• La aplicación tendrá autenticación.
• No estamos muy preocupados por el antiguo soporte del navegador (¡vaya!), Por lo que estamos buscando aprovechar lo último y lo mejor que está disponible y que saldrá a la luz. (HTML5, CSS3, WebGL ?, Extensiones de fuente de medios y más!)

Aquí hay algunos objetivos del proyecto :

• La aplicación necesita escalar. En el corto plazo, nuestros usuarios estarán en el orden de cientos a miles, pero estamos planeando decenas de miles a millones y más.
• Esperamos que la aplicación esté disponible para siempre. Esta no es una solución temporal. (En realidad, ya tenemos una solución temporal, y lo que estamos diseñando es el reemplazo a largo plazo de lo que tenemos).
• La aplicación debe ser segura, ya que puede tener contacto con información personal sensible.
• La aplicación debe ser estable. (Idealmente, sería estable alrededor del nivel de Gmail, pero no necesita estar en el extremo de un rover de Marte).

En primer lugar, diría que la diferencia entre arquitectura y diseño es principalmente la semántica. Algunos equipos tienen puntos de control entre los dos. Su líder técnico define la arquitectura como antes del diseño y la arquitectura como agnóstico de implementación. A partir de eso, supongo que estamos hablando del diseño como en el modelo en cascada y no del diseño industrial, que lo ayudaría a diseñar el producto con una vista para los usuarios antes de llegar a la arquitectura del software. Creo que la arquitectura a menudo se desliza en el diseño y eso no es necesariamente algo malo, a menudo es muy útil para el arquitecto tener un conocimiento profundo de lo que es posible dentro del sistema en cuestión.

Dicho todo esto, necesita algunos consejos para la situación en la que se encuentra. Hay todo un mundo de arquitectura de software, documentos, libros, conferencias, pero generalmente está buscando patrones y abstracciones. Sin más detalles sobre el proyecto, solo puedo dar un amplio ejemplo. Por ejemplo, si estaba trabajando en integración, existe la Arquitectura Orientada a Servicios ( SOA)) patrón en el que divide partes del sistema en 'servicios' para que pueda trabajar con cada parte de una manera definida, en el programa web esto a menudo se implementa como Servicios Web (aunque no debería ser tan limitado a eso) y más recientemente el aumento de las API RESTful con JSON, nuevamente diría que este es un diseño que proviene de la arquitectura de SOA. Diría que Model, View, Controller (MVC) es otro ejemplo de un patrón de arquitectura de uso común, que divide la responsabilidad de los componentes de un sistema para permitir que las partes se intercambien, para contener errores y pruebas.

Desde un nivel de 10,000 pies, si puede dibujarlo en una pizarra y explicarlo a un programador competente que no trabaja en su campo y no conoce su lenguaje de programación y detalles de implementación actuales, entonces probablemente sea arquitectura. Si puede escribir un libro sobre el tema que le interese a cualquier persona ajena a su empresa, probablemente sea arquitectura. Si encuentra detalles que se explican por sí mismo y no puede generalizarlos a otras bases de código / compañías / industrias, entonces probablemente sea diseño.

Estoy de acuerdo en que los dos ejemplos que da son diseño de código y no arquitectura. La primera porque creo que cuando dices que se te ocurrió un 'algoritmo' para cargar recursos, creo que quieres decir que diseñaste un conjunto de instrucciones para llevar a cabo esa tarea, y no que diseñaste un nuevo algoritmo que enseñarán en el primer año COMSC el año que viene. En el segundo ejemplo, nuevamente estoy de acuerdo en que es diseño. Si me mostraras alguna de estas ideas, no podría usarlas en mi proyecto de software aleatorio. Tiene que ir a un 'nivel superior', orientado a objetos (OO) en Java en lugar de querer que la clase de cliente sea una subclase de la clase de persona. Incluso hablar de excepciones en general podría considerarse un nivel demasiado bajo (demasiado cerca de la implementación).

Para tratar de abordar los detalles que enumera, creo que lo que debería estar pensando es cómo diseñar un CMS basado en la web. Wordpress tiene un códice de arquitectura de sitio donde hablan mucho sobre los detalles de implementación del diseño, pero la publicación deja claro que su arquitectura principal se centra en hacer que Wordpress sea extensible con temas. Diseñar una interfaz clara para un tema de modo que pudiera ser escrito por alguien fuera de la empresa fue claramente una decisión de arquitectura que tomaron. Este es el tipo de cosas que es bueno dejar en el papel al diseñar su solución 'a largo plazo' (no temporal) para que todas las decisiones de diseño e implementación que se tomen durante el desarrollo (por todos los desarrolladores, no solo el arquitecto) están en línea con esta idea.

Otros ejemplos de arquitectura para su situación:

1. Poner todo en máquinas virtuales, alojadas en un proveedor de la nube o en casa y tener instancias de máquinas sin estado, para que cualquier falla de la máquina pueda ser reemplazada por una nueva instancia de una máquina virtual sin tener que copiar en ningún estado o perder información.
2. Construyendo pruebas de falla de producción en vivo desde el principio con simios del caos .

Tal vez intente dibujar todo el sistema en una pizarra. Pruébelo en diferentes niveles de detalle, el primer tablero podría ser GUI-> despachador-> backend-> DB o algo así, y luego profundice hasta que comience a usar pronombres.

La distinción entre estas dos ideas es realmente importante donde trabajo.

Lo que llamamos "arquitectura", lo llamamos "programación en inglés". Esto es en parte importante porque si no puede describirlo a un no programador, entonces algo está mal. Puede ser que no comprenda el problema lo suficientemente bien, O puede ser que esté resolviendo un problema "fantasma" (no discutido aquí).

Los términos utilizados para estos dos aspectos diferentes del diseño son a menudo diferentes, pero los principios se reconocen fácilmente en todas partes. Un aspecto (en su caso, el arquitecto, en mi caso, el diseñador) programa en inglés, mientras que el otro (en su caso, "diseñador", en mi caso, "desarrollador") programa en un idioma particular. También se distinguen con bastante frecuencia como "diseño" e "implementación". "Diseño" es lo que se supone que debe lograr, y "implementación" es el código que lo hace posible.

Algunos ejemplos de lo que he trabajado:

La arquitectura de un programa es: necesitamos un Administrador centralizado o un concentrador al que podamos agregar módulos fácilmente. Este administrador distribuiría eventos a todos los módulos registrados. Un módulo puede registrarse en el Administrador de eventos y, por lo tanto, publicar eventos en el resto del sistema y recibir los eventos que le interesan. Cada módulo tiene un "buzón" que puede verificar y vaciar a su gusto. Esto nos permitiría acomodar nuevos módulos que aún no sabemos que necesitamos.

No hay código allí. Podría escribirse en cualquier idioma. La implementación no está dictada por esta descripción.

La arquitectura de otro proyecto es: necesitamos una forma de iniciar y detener de manera confiable otros programas sin esperarlos. Podríamos tener un gerente que sea responsable de un programa en particular. Simplemente podemos decirle que inicie o detenga su programa y el gerente se encarga de ello. Si se le pide a este otro programa que se detenga y no lo hace en un período de tiempo determinado, el gerente sabe cómo obligarlo a detenerse y limpiar el desorden. El programa no se inicia ni se detiene por nada más, y se le puede preguntar al administrador si su programa se está ejecutando, deteniendo o esperando para detenerse. Esto nos permite continuar con las otras cosas que tenemos que hacer, mientras que estos otros programas se inician y se detienen correctamente.

Nuevamente, nada aquí dicta la implementación, aunque algunas implementaciones son claramente más útiles que otras.

La diferencia entre diseño (lo que llamaríamos patrones o implementación) y arquitectura (lo que llamaríamos diseño) es que uno de ellos resuelve un problema de codificación / implementación y el otro resuelve un problema del mundo real.

Tal vez esto ayude. Siempre he visto la antigüedad de un ingeniero como una cuestión de cuán grande es el problema que pueden resolver por sí mismos.

Aproximadamente, para transmitir la idea:

• Puede dar a alguien nuevo en la programación de tareas pequeñas y contenidas con muchas instrucciones explícitas sobre cómo la tarea debe integrarse con otras piezas

• Un desarrollador de nivel medio es alguien que puede tomar una descripción de una parte de una aplicación y hacer que funcione dentro del contexto de esa aplicación.

• Un desarrollador senior puede construir una aplicación de tamaño mediano desde cero, dentro de las limitaciones técnicas de una tienda.

• Un desarrollador más experimentado puede hacer eso y tomar decisiones tecnológicas en el camino sobre qué tecnologías usar para que funcione bien.

... pero esas no son reglas duras y rápidas. Y algunas personas salen por la puerta como IMHO "senior", incluso si tienen que pasar algún tiempo con un título diferente.

Lo que el arquitecto pregunta es ver el problema incluso de manera más general que eso. Si tuviera que reunir una serie de aplicaciones para que el sistema funcione:

• ¿Qué aplicaciones y servicios necesitarás?
• ¿Qué piezas interactúan con los clientes y cuáles interactúan entre sí?
• ¿Cómo se comunicarán?
• ¿Dónde almacenarán los datos?
• ¿Dónde están los riesgos de fallas?
• ¿Cómo proporcionará confiabilidad?
• ¿Cómo proporcionará seguridad?

Entonces, en cierto sentido, la arquitectura técnica es como la arquitectura de un edificio. Es el diseño o el plan. Muestra lo que se necesita para las distintas partes, cómo se mantienen juntas y, lo que es más importante, por qué .

(Por cierto, me han explicado una curva de crecimiento similar para los arquitectos, desde diseñar una familia de aplicaciones relacionadas o un conjunto de características muy complejas, hasta establecer la dirección técnica de un grupo, y tomar decisiones técnicas estratégicas para toda una organización .)

Dicho esto, creo que la mayoría de los ingenieros en todos los niveles también tienen que hacer "arquitectura". No es una línea brillante. Parece que si te enfocas primero en el panorama general y no te obsesionas con los detalles de implementación, estarás más en línea con lo que está buscando. Por cierto, la capacidad de ver el panorama general y los pequeños detalles es un gran activo en esta industria, por lo que esto parece una gran oportunidad.

... Aquí hay una analogía. Digamos que te piden que crees un Magic Black Box. Como ingeniero, se espera que te obsesiones con el funcionamiento interno de Magic Black Box. Pero como arquitecto, su enfoque es diferente. Es posible mirar en la caja por curiosidad, pero que se espera que obsesionarse con todo alrededor de todos los negros cajas mágicas.

Similar a esa analogía, puede pensar en el papel de la arquitectura como ver todo el sistema como la caja mágica. Entonces, si tomas una Gigantic Glass Box y pones a los clientes, las aplicaciones del cliente, el firewall, el nivel de servicio, la base de datos e incluso a los desarrolladores dentro, entonces, como arquitecto, te obsesionarás sobre cómo hacer esa enorme caja del sistema trabajar bien .

La diferencia exacta entre "diseño" y "arquitectura" es un poco subjetiva y hay cierta superposición. Sin embargo, esta es la diferencia tal como la entiendo:

La arquitectura analiza conceptos de alto nivel. ¿Quiénes son los actores en el sistema? ¿Cuáles son los objetos principales y cuáles son responsables de qué? Cuando pienso en arquitectura, pienso en Visio, no en código.

Por ejemplo, un sistema de eventos podría tener un administrador de eventos que acepte eventos entrantes y los envíe a los controladores de eventos. La idea de hilos, asíncrono v. Síncrono y otros conceptos de nivel inferior no entran en juego aquí. MVC es otro ejemplo: los detalles específicos no se especifican en el alto nivel de cómo interactúan las tres piezas, solo que hay tres preocupaciones separadas manejadas por paquetes de código separados.

El diseño implica la creación de prototipos, esbozar interfaces de código, esqueletos de código, etc. Se ubica entre la arquitectura abstracta y el trabajo de "mono de código" de bajo nivel.

En un marco de eventos, el diseño podría decir "un evento usa esta interfaz" y "hay un grupo de subprocesos que el administrador de eventos usa para enviar eventos a los trabajadores". Un diseño para MVC podría ser "usar Hibernate para el modelo, Spring para el controlador y GWT para la vista".

Cuando realizo trabajos de diseño, esbozo interfaces y esqueletos de código, luego entrego los resultados a los programadores. A veces soy ese programador. Pero son dos fases separadas, y ambas existen más hacia el concreto que la arquitectura.

Ponerse el sombrero de arquitectura significa despejar su mente del código y pensar en objetos en una pizarra. Piense en objetos, paquetes, marcos y el flujo de mensajes entre ellos. Si está pensando en una sola línea de código, lo está haciendo mal. No se atasque en algo como "oh, ese mensaje podría ser una cadena, o usar SOAP, o lo que sea". En este nivel, el hecho de que se está produciendo comunicación es suficiente. Los detalles son irrelevantes.

Si puedo agregar algo aquí, es eso: no pienses en el código . En absoluto.

No piense cómo va a escribir el código para lograr algo, pero piense cuál sería el mejor método para lograrlo. Su descripción de lo que debe hacer debe ser independiente del idioma , por lo que estará hablando de patrones de diseño, que son un "lenguaje" común entre usuarios de diferentes lenguajes de programación, para analizar cómo proceder.

Para su caso de uso específico, más preguntas arquitectónicas en mi opinión estarían en la línea de:

• ¿Por qué estás usando MVC? ¿Es todo lo que sabes? ¿Hay mejores patrones para usar? ¿Por qué?
• ¿Qué marco utilizará y por qué ?
• ¿Cómo vas a escalar? No en cuanto al código, porque eso aún no importa. ¿Cuáles serán las condiciones para escalar horizontalmente? ¿Qué servicio (AWS) utilizará para hacer esto?
• ¿Cómo se realizará la autenticación? No en cuanto al código: ¿generará un token aleatorio y único en cada solicitud y lo verificará con el token esperado? No pienses cómo harás esto en código. Piense por qué está haciendo esto, porque esto se puede hacer en prácticamente cualquier idioma web.

Básicamente, no hables nada sobre el código. Incluso si no sabes cómo hacer algo, cuando hay voluntad, hay una manera . Piensa más sobre cómo encajarán mejor las piezas del rompecabezas, antes de preocuparte por armarlas.

Piense en todas las operaciones (es decir, casos de uso) que su sistema puede realizar. Para cada operación, documente lo que sucede en términos de su dominio comercial para cada operación. Solo debe hablar en términos de su dominio problemático y no describir ningún detalle de implementación. Dibuja un gran bloque y llámalo Sistema. La combinación de este "gran bloque" y las descripciones de operación es la arquitectura del sistema de más alto nivel.

Si bien esta arquitectura de alto nivel proporciona un punto de partida decente, realmente no tiene mucho valor al construir un sistema real. Debe bajar un nivel de detalle para convertir esto en una arquitectura útil.

Entonces, sigue la misma idea general que el enfoque de "bloque grande", solo que comienza a agregar "subbloques" que son necesarios para realizar cada operación. Estos "subbloques" se denominan frecuentemente clases o módulos de dominio. Estos se identifican fácilmente mediante el uso de las descripciones de sus operaciones (desde el enfoque de bloque grande) y dibujando diagramas de secuencia. Se llaman clases de dominio porque no están destinadas a ser clases "reales", pero están destinadas a describir su sistema en términos del dominio del problema de su sistema.

El resultado final de crear todo el diagrama de secuencia e identificar todos los "subbloques" es que ahora tiene una lista de clases de dominio y sus listas de operaciones. Esto generalmente termina dando como resultado una arquitectura de software bastante utilizable, donde cada uno de los "subbloques" / módulos podría distribuirse a diferentes desarrolladores para diseñarlos e implementarlos.

Por supuesto, si lo deja como está, sus diseñadores tendrán mucha interacción entre ellos para definir las interfaces entre los módulos. Por lo tanto, el arquitecto también puede decidir sobre los mecanismos de interfaz específicos y los tipos de datos que se utilizarán entre los módulos.

Además, algunos "subbloques" seguirán siendo muy complicados bajo el capó. Por lo tanto, puede ser necesaria otra iteración del enfoque de "subbloque", pero solo esta vez en uno de los módulos recientemente identificados.

Finalmente, puede haber algunos patrones / limitaciones específicos entre las interfaces a las que el arquitecto desea que se adhiera el sistema (por ejemplo, devoluciones de llamadas de eventos frente a llamadas de método directo), por lo que esas decisiones tendrían que mencionarse en el diseño arquitectónico. Además, puede haber módulos "comunes" que el arquitecto quiere que todos usen.

Como desarrollador, probablemente esté acostumbrado a proporcionar soluciones. Esa es una muy buena forma de pensar, pero puede obstaculizar cuando se trata de pensar en arquitectura.

Creo que es útil describir primero el problema que está intentando resolver. ¿Qué son los requerimientos? ¿Cuáles son las restricciones? ¿Puede hablar con las partes interesadas para conocer estos requisitos?

Podría ayudar si también puede describir sus propios objetivos de diseño. ¿Su solución necesita escalar, o es suficiente un diseño para un solo usuario? ¿Cuánto tiempo necesita su solución para seguir siendo válida? ¿Es una solución única o una solución de infraestructura a largo plazo? Quizás también tan importante: ¿Cuáles son los límites aceptados de su arquitectura?

Y como esta es una experiencia de aprendizaje, no tenga miedo de hacer preguntas, incluso si son tontas.