software - architecture traduccion

¿Deberían los arquitectos de aplicaciones escribir el código? (22)

Esta es una pregunta frecuente que tiene puntos de vista en ambos lados. Los partidarios argumentarán:

Para diseñar un sistema para codificadores debes comprender cómo codificar (y codificar)
No se puede diseñar un sistema sin ser consciente de lo que está sucediendo a nivel del suelo
La arquitectura no se trata solo de un diseño de trazo amplio, sino de adaptarse a las necesidades cambiantes en el nivel de código

por otra parte,

La arquitectura es un rol de alto nivel y no debe preocuparse por los detalles de implementación
La codificación es una función detallada orientada hacia abajo, que está en desacuerdo con la gestión de riesgos, la naturaleza de visión amplia de la arquitectura
La arquitectura se trata de la gestión de riesgos técnicos y no de la implementación
La arquitectura se trata de liderazgo. Es difícil liderar desde atrás

En mi experiencia, los arquitectos no deberían dedicar mucho tiempo a la codificación, sino que deben mantenerse en contacto con la base de códigos principalmente a través de la comunicación, la revisión y las actualizaciones del desarrollador principal. Si dedica mucho tiempo a la codificación, pierde de vista los problemas de alto nivel y se vuelve ineficaz en la gestión del riesgo técnico.

La arquitectura es un rol de alto nivel y no debe preocuparse por la implementación> detalles

El código es el diseño. Imagínese a un arquitecto que diseña bonitos edificios pero se niega a entrar en detalles de implementación, como dónde colocar las salidas de emergencia, plomería, electricidad, ascensores o problemas legales de construcción.

* Coding is a detailed oriented, heads-down funtion which is at odds
con la gestión de riesgos, naturaleza de visión amplia de la arquitectura

Cuando codifica, al principio, concéntrese en los detalles. Luego se refactoriza con un enfoque más amplio.

La arquitectura se trata de liderazgo. Es difícil liderar desde atrás

El frente de batalla del desarrollo de software es la codificación. Puede ser el gerente de producto o el administrador del proyecto no codifica. Pero el arquitecto necesita hacerlo. Puede ser que deba dedicar más tiempo a refactorizar para mostrar qué tan bueno puede ser el código. De esta manera él lidera con el ejemplo.

¿Tan solo escribir las interfaces cuenta como código? Si es así, entonces este es el mínimo que esperaría de un arquitecto, mientras que en otros casos podría ser mucho más código de ellos, como clases con trozos de métodos.

A riesgo de desviarse del tema ...

En una aplicación a gran escala, es posible que un arquitecto no pueda mantenerse actualizado con el código que se está escribiendo. Además, no le sería posible escribir el código debido a otras responsabilidades importantes. Habiendo dicho eso, lo recomendaría, el arquitecto no debería perder el panorama general sobre la base de códigos que se está desarrollando. Esto se puede lograr monitoreando la base de código para la cobertura del código, métricas sobre la calidad del código, análisis de código estático, etc. Debe evaluar regularmente la calidad del código utilizando los criterios mencionados. Las prácticas de ''integración continua'' pueden ayudar aquí.

Algunas veces, tienen que codificar. Por ejemplo, cuando el equipo es solo una persona.

En mi opinión, pueden codificar si quieren, pero no deben perder la gran imagen. Un no ir es cambiar las estructuras diseñadas todos los días.

Como dijo Vlion, hacer esta pregunta en una comunidad predominantemente dominada por desarrolladores significa que las respuestas serán sesgadas hacia "sí".

Como alguien que tiene "arquitecto" en el título de su trabajo, pero que también recientemente recibió el gafete de "Ingeniero distinguido", mi lealtad se rompe. En general, creo que la codificación no suele ser un uso efectivo del tiempo de un arquitecto. Entonces, ¿qué debería estar haciendo?

Comprender el negocio.
Comprender los sistemas utilizados para habilitar el negocio.
Trabajando con la empresa en estrategias y tácticas de TI.
Asegurarse de que los proyectos actuales se estén llevando a cabo con una visión a largo plazo, donde el administrador del proyecto se concentra en la vista a corto plazo.

Entonces, ¿cómo debe un arquitecto mantenerse en contacto con la realidad? Creo que mediante reuniones periódicas y caminatas, simplemente hablando con personas de todos los niveles y aceitando las ruedas de la comunicación.

Como todos aquí son codificadores, los favoritos deben ser los infiernos, sí, respuesta, y no obtendrás ningún desacuerdo de mí.

Pero la respuesta más detallada es más correcta en mi opinión, porque valora apropiadamente la experiencia del dominio. Las personas que conocen programas de combate pequeños, pero que solo los usan son muy valiosos.

La forma en que se dividen las funciones arquitectónicas parece depender del tamaño y la naturaleza de la organización.

Si lo hiciera a mi manera, le daría al cliente un papel de Story Architect si escriben buenas historias útiles y detalladas y casos de uso.

Estás preguntando esto en un sitio de codificación. Básicamente conseguirás que todos caigan en el lado del "sí".

Mi punto de vista es, sí, pero solo lo suficiente como para seguir el ritmo de las necesidades cambiantes, no más

Esta respuesta estándar de los Desarrolladores es que un Arquitecto también debería estar codificando. Pero es un tipo de desarrollador que pone la tecnología primero. Pero tiendo a estar en desacuerdo. Sí, es beneficioso tener algunas habilidades de codificación para poder revisar el código.

Pero lo único que hace un arquitecto es reunir los requisitos del negocio con la implementación. Y en nuestro caso el código. Si tiene un sistema seriamente complejo, no puede codificar y hacer Arquitectura al mismo tiempo, porque está operando a demasiados niveles de abstracción diferentes.

En cambio, deberías poder confiar en los Desarrolladores. Deben ser capaces de describir los aspectos de la implementación y cómo encajan en el requisito comercial que les ha indicado. La tecnología elegida es la decisión de Architects, pero para llegar a esa decisión debe investigar o utilizar la experiencia anterior. Eso no significa que no hable con los Desarrolladores, ni les permita investigar una tecnología específica para ver si la Arquitectura realmente funciona.

Hay arquitectos y hay estrategas de TI. Si lidera un proyecto de integración que involucra a 500 personas en varios departamentos, entonces no, se interpondrá en el camino. Si dirige el diseño y la implementación de hasta 10 personas en un proyecto de desarrollo, entonces sí. De lo contrario, será mucho menos probable que tenga la información adecuada sobre la realidad cotidiana de trabajar con su arquitectura.

Incluso si su argumento en contra de la codificación es válido, creo que es importante que el equipo de desarrollo lo respete a usted y a sus decisiones de diseño. Si "sufres las consecuencias" de tus decisiones de arquitectura junto con ellas, es mucho menos probable que las cuestionen.

Todo el tiempo, veo arquitectos que están fuera de contacto con el lado de la codificación, y cuyos equipos de desarrollo lo saben. No reciben mucho respeto.

La arquitectura es una habilidad central para los desarrolladores de software. Puede haber algunas ocasiones excepcionales en las que pueda tener sentido para un arquitecto no codificar, pero no recuerdo haber encontrado ocasiones similares en mi propia experiencia.

El arquitecto debe codificar en el proyecto o, como mínimo, ser plenamente capaz de codificar el proyecto. La segunda parte de esto significa que tienen que poder codificar utilizando las herramientas y técnicas que utiliza el resto del equipo. (Sin continuar codificando, debe ser muy difícil mantener estas habilidades).

Finalmente, cuando los arquitectos son responsables de elegir las herramientas y técnicas para ser utilizadas por otros, no pueden elegir bien sin utilizar realmente las herramientas propuestas. En este escenario, el arquitecto no codificador rápidamente degenera en un jefe de pelo puntiagudo con una pila de folletos en su escritorio.

Me pregunto por qué nadie ha mencionado las revisiones de códigos o la programación de pares que puede reemplazar la codificación.

Paso mucho más tiempo leyendo el código y resolviendo problemas con mis compañeros de trabajo que codificando. Esto me da casi la misma comprensión del código, su estructura y complejidad que escribirlo por mí mismo y me lleva mucho menos tiempo. Cuando codigo, lo hago por diversión o para explorar nuevas tecnologías (este es el único lugar donde encontré la codificación útil).

No creo que necesiten codificar todo en la aplicación. Pero deberían recibir algunas tareas. Algunos "arquitectos" son básicamente hacks sin experiencia técnica que se hacen pasar por "codificadores legendarios" y diseñan sistemas que agregan semanas o meses a la cantidad de trabajo que tendrían que hacer si no tuvieran una arquitectura. Si no pueden escribir código, no tienen nada que hacer en ese rol ... Porque la idea es una arquitectura que haga que la aplicación sea más fácil de desarrollar y mantener. Pero si el arquitecto no puede desarrollarse, ¿cómo sabrá él cómo hacer una arquitectura?

Además, incluso los mejores arquitectos toman malas decisiones. A veces, algo se ve muy bien en la pizarra, pero en realidad una decisión arquitectónica termina haciendo las cosas mucho más difíciles de lo que deberían ser. Si el arquitecto tiene que comer su propia comida para perros (y usar la arquitectura), están más inclinados a querer corregir las malas decisiones o a diseñar formas de evitarlas. También al tocar el código están al menos un poco familiarizados con él. Por lo tanto, si un desarrollador recurre a ellos con un problema de codificación, los ojos del arquitecto no se desvanecerán cuando rechace al desarrollador y le diga que el desarrollador lo está haciendo mal, pero no ofrece información sobre el camino correcto para hacerlo.

El arquitecto no necesita hacer grandes proyectos dentro de la base de código. Pero al menos deberían hacer pequeñas tareas dentro de la base de código que los obligue a usar su propia arquitectura. Además, las tareas pequeñas probablemente implicarán leer mucho del código de otras personas para darles una idea de cómo las personas están utilizando la arquitectura y si se puede hacer algo para mejorarla.

Sí, para mantener su experiencia de codificación.

Sí. Los arquitectos de software que no han escrito el código durante años pierden contacto con las realidades de la creación de un producto. Comienzan a producir diseños grandiosos con niveles de abstracción cada vez más altos, que parecen seguir deslizando sus fechas de envío.

Solo para dar mi granito de arena (y mi visión de "arquitectos")

Creo que hay varios tipos de arquitectos, cada uno en su propio dominio:

arquitectos comerciales y funcionales : se preocupan por las operaciones comerciales y el flujo de trabajo de funciones, y en realidad nunca deberían codificar , porque tienen que poder abstraerse de cualquier tipo de implementación, y deben producir especificaciones funcionales que dejen la solución técnica abierta .
Arquitectos aplicativos : dividen un dominio funcional (como el "análisis de ganancias y pérdidas") en aplicaciones (como "procesador de cartera", "iniciador", "despachador", "gui"). No necesitan código, pero deberían ser codificadores anteriores para tener una idea clara de los desafíos técnicos que sus arquitecturas deben abordar. Sin embargo, su habilidad principal no es la codificación, sino escuchar a colegas técnicos para elegir la solución adecuada. Luego producirán una implementación técnica que debe implementarse (codificarse).
arquitectos técnicos : están a cargo de elegir y / o implementar marcos técnicos (aquellos que son genéricos para cualquier proyecto funcional, como KPI, registro, gestión de excepciones), y deben codificar (y codificar) bien, ya que sus componentes serán utilizado por todos los otros equipos funcionales.
arquitectos de desarrollo (hey, that''s me ;)): a cargo de las herramientas y los procesos de desarrollo, y las encuestas tecnológicas, también deberían codificar y amar la codificación .

Por lo tanto, creo que no hay una sola respuesta: depende de su campo de arquitectura y experiencia: cuando se trata de ''arquitectos de aplicaciones'', creo que las tres últimas categorías pueden tener una experiencia de codificación diferente ...

Todos los proyectos en los que he trabajado que incluyen a un arquitecto que no pasó gran parte de su tiempo con el código han tenido problemas debido a la falta de conocimiento práctico.

Eso incluye los proyectos donde yo era ese arquitecto :-)

Ahora es una gran bandera roja personal.

Estoy de acuerdo con todos los argumentos a favor de los arquitectos que codifican. Los argumentos en contra no se juntan bien para mí.

El código necesita abstraer los conceptos de alto nivel y el bajo en una aplicación. A menos que el diseño y el código estén integrados en todos los niveles, la solución será menos que óptima.

En cuanto a "Codificar es una función detallada orientada hacia abajo que está en desacuerdo con la gestión de riesgos, la naturaleza de la arquitectura de vista amplia" -en mi experiencia una visión amplia -y especialmente la gestión de riesgos- no mejora la calidad de los codificadores :-)

"La arquitectura se trata de la gestión de riesgos técnicos y no de la implementación", pero no lo es. Se trata de la gestión e implementación de riesgos (y un montón de otras cosas).

"La arquitectura se trata de liderazgo. Es difícil liderar desde atrás". ¿Por qué la codificación lo deja atrás? Personalmente, creo que el mejor lugar para liderar es con las personas con las que estás trabajando.

Un arquitecto de aplicaciones debe ser capaz de definir una arquitectura de aplicaciones, diseñar la aplicación, implementar los patrones y entrenar a otros para codificar. Si no puede hacer esas cosas, entonces no es un arquitecto de aplicaciones.

Yo (creo que) soy arquitecto, la codificación es lo que hace que este trabajo sea divertido.

Luego ves que tus ideas cobran vida, puedes ver que tu diseño funciona, y puedes ver los errores en el diseño (demasiado tarde de todos modos, pero la próxima vez ...)

Ab-tan-frickin-lutely

No hay nada peor que un arquitecto que ha perdido el contacto con la realidad.

Es parte del trabajo mantener los pies en el suelo y la cabeza en las nubes.

Creo que el papel de la arquitectura está cambiando. Veo menos y menos arquitectos de torre de marfil que diseñan un sistema completo para que los programadores humildes lo implementen en un proceso de cascada.

Al hacer proyectos iterativos, la comunicación entre arquitectos y programadores se vuelve más importante. El arquitecto es parte de un equipo y debe ser capaz de manejar requisitos cambiantes y nuevas ideas junto con los programadores. En situaciones como esta, el trabajo de un arquitecto y un programador están más estrechamente relacionados. He visto equipos donde los desarrolladores de desarrollo asumieron el papel de arquitectos que entregan arquitecturas bien pensadas para soluciones realmente complicadas.

editar En respuesta al comentario
Creo que en la distinción entre aplicación, solución y arquitecto de empresa es un poco artificial y no encaja realmente en muchos casos. Roles como el arquitecto de seguridad, el arquitecto de datos, etc. proporcionan una desincronización mucho más clara entre las responsabilidades. Puedes mirar aquí para más detalles http://stevendwright.home.comcast.net/~stevendwright/ArchRoles.htm

Por cierto, después de volver a leer su pregunta noté que muchos de los argumentos en contra de la codificación de arquitectos parecen indicar un fuerte rol de gestión / liderazgo para el arquitecto. Creo que es una buena idea separar los roles de administración y arquitectura. Es mejor que su personal técnico divida su tiempo entre la codificación y la arquitectura que entre la administración y la arquitectura.

He llegado a creer que, en la mayoría de los casos, los "detalles de implementación" no son detalles (en el sentido de que surgen muchos problemas cuando se consideran algunos problemas específicos de implementación como meros detalles que podrían descartarse como minucias desde una perspectiva "arquitectónica"). )