¿Cómo trabajan los arquitectos de software con el personal de programación?

Estoy en la posición arquitectónica actualmente. Para ser precisos, el trabajo de mi equipo es reunir problemas técnicos que rodean a nuestros servidores y encontrar o desarrollar e implementar soluciones a estos problemas. En el equipo, estoy reuniendo requisitos, proporciono pautas arquitectónicas y proporciono orientación y apoyo en cuestiones de desarrollo.

Para mí, hago dos cosas y parecen funcionar muy bien.

Por un lado, enfatizo ciertos objetivos de diseño importantes y me aseguro de que cada desarrollador en el proyecto comprenda el propósito de esta decisión. También proporciono una guía sobre quién implementaría esta propiedad, pero aceptaré con gusto cualquier aporte que me den mis desarrolladores. Incluso estoy bien con una arquitectura completamente diferente siempre que pueda ver que es buena y que tiene los objetivos de diseño que necesito.

Por ejemplo, en uno de nuestros proyectos actuales, dos objetivos de diseño muy importantes:

• Debe proporcionar un mecanismo de complemento para que nuestros otros proyectos puedan personalizar este software a sus necesidades específicas.
• Tiene que soportar la distribución a través de múltiples servidores, actualmente con un enfoque simple de servidor maestro / servidor esclavo

En el primer caso, verifico continuamente que ningún código específico del proyecto ingrese al núcleo de la aplicación y la próxima semana, separaremos la aplicación principal del código específico del proyecto prototipo. En el segundo caso, ofrecí la arquitectura y simplemente la usamos, ya que nadie tenía grandes objeciones o una arquitectura mucho mejor.

Por otro lado, actualmente estoy estableciendo una cultura de calidad en mi equipo. Requiere algo de trabajo, porque tengo algunos desarrolladores junior que simplemente no tienen la suficiente experiencia, otros desarrolladores que no están acostumbrados a ser tan exigentes con la calidad, pero están mejorando rápidamente. Cada vez que alguien implementa una nueva característica, hacemos una revisión de código bastante rigurosa, creamos tickets estimados y planificados para implementar las cosas de la revisión, etc.

El resultado de estas dos cosas es que obtengo una base de código de alta calidad sin la necesidad de planificar la arquitectura en cada pequeño detalle y sin la necesidad de administrar a cada desarrollador de manera íntima.

Además, observando su comentario sobre la alta carga de trabajo, este tiene un resultado de seguimiento muy interesante: mis desarrolladores están muy, muy motivados y realizan una cantidad tonta de trabajo, porque se sienten confiables y capacitados sobre su trabajo. Es su trabajo, es su propio producto y, cuando el resultado es asombroso, hicieron un trabajo increíble. Estoy ahí para ayudarlos con decisiones difíciles y reconocer los errores o problemas temprano para que vuelvan a la pista más rápido.

Desafortunadamente, los beneficios de una buena arquitectura no son obvios al comienzo del proyecto. Las personas se darán cuenta de los beneficios de una buena arquitectura con el tiempo. En mi experiencia, la clave del éxito del arquitecto es

• Ser parte del equipo. Participe en el desarrollo del día a día donde sea posible.
• Ganar la confianza del equipo. El arquitecto necesita construir una buena relación / confianza con el equipo de desarrollo. En nuestra organización, los arquitectos no tienen autoridad como los gerentes de línea / gerentes de proyecto, pero al mismo tiempo necesitan hacer las cosas.
• Comunique los fundamentos / beneficios de las decisiones arquitectónicas lo suficientemente detalladas como para hacer que los beneficios sean obvios.

En algunas situaciones, los beneficios no son obvios y ahí es donde ayuda la confianza de los miembros del equipo en el arquitecto.

Como ejemplo práctico al comienzo de nuestro proyecto actual, hablamos sobre la inyección de dependencia (DI) y AOP. Inicialmente hubo escepticismo por parte del equipo, pero comenzó a usarlo de cualquier manera a menor escala. Una vez que comenzamos a usarlo, ahora el equipo se siente cómodo, lo estamos extendiendo a otras áreas.

La revisión del código ayudaría mucho en su situación, pero se deben establecer algunas pautas de programación para que puedan usarse en las revisiones por pares. Si encuentra que alguien está produciendo constantemente un código de línea de 10k, es posible que desee ayudarlo a refactorizar uno de estos en un código más manejable / legible (programación de pares).