Applications architectes écrire du code?

Même si votre argument contre le codage est valide, je pense qu'il est important que l'équipe de développement vous respecte et respecte vos décisions de conception. Si vous" subissez les conséquences " de vos décisions d'architecture en même temps que celles-ci, alors ils sont beaucoup moins susceptibles de les remettre en question.

Tout le temps, je vois des architectes qui sont déconnectés du côté du codage, et dont les équipes de développement le savent. Ils ne reçoivent pas beaucoup de respect.

Ab-so-frickin-lusely

Il n'y a rien de pire qu'un architecte qui a perdu le contact avec la réalité.

Cela fait partie du travail de garder les pieds sur terre et la tête dans les nuages.

Juste pour donner mes deux cents (et ma vision des "architectes")

Je crois qu'il existe plusieurs types d'architectes, chacun dans son propre domaine:

• Architectes d'affaires et fonctionnels : ils se préoccupent des opérations commerciales et du flux de travail des fonctions, et ils en fait ne devrait jamais coder, parce qu'ils doivent être capables de s'abstraire de tout type d'implémentation, et qu'ils doivent produire des spécifications fonctionnelles qui laissez la solution technique ouverte.

• Architectes applicatifs : ils divisent un domaine fonctionnel (comme "analyse des profits et pertes") en applications (comme "processeur de portefeuille", "lanceur", "répartiteur", "interface graphique"). Ils n'ont pas besoin de code, mais ils devraient être ancien codeur afin d'avoir une idée claire des défis techniques qui leur architecture doit répondre. Leur compétence principale n'est pas de coder, mais d'écouter des collègues techniques dans afin de choisir la bonne solution. Ils produiront alors une implémentation technique qui doit être implémentée (codée).

• Architectes techniques : ils sont en charge du choix et / ou de la mise en œuvre des cadres techniques (ceux qui sont génériques pour tout projet fonctionnel, comme les KPI, la journalisation, la gestion des exceptions), et ils devrait absolument coder (et code bien), puisque leurs composants seront utilisés par tous les autres fonctionnels Equipe.

• Architectes de développement (hey, that's me;)): en charge des outils et processus de développement, et des enquêtes technologiques, ils devraient coder et aimer coder aussi bien.

Je crois donc qu'il n'y a pas qu'une seule réponse: cela dépend de votre domaine architectural et de votre expertise: en ce qui concerne les "architectes d'applications", je crois que les trois dernières catégories peuvent avoir une expérience de codage différente...

Je pense que le rôle de l'architecture est en train de changer. Je vois de moins en moins d'architectes de tour d'ivoire qui conçoivent tout un système pour que les programmeurs humbles l'implémentent dans un processus en cascade.

Lors de projets itératifs, la communication entre architectes et programmeurs devient plus importante. L'architecte fait partie d'une équipe et devrait être capable de gérer les exigences changeantes et les nouvelles idées avec les programmeurs. Dans des situations comme ça le travail d'un architecte et d'un programmeur sont plus étroitement liés. J'ai vu des équipes où les dev-leads ont pris le rôle d'architectes livrer des architectures bien pensées pour des solutions vraiment compliquées.

Modifier {[6] } En réponse au commentaire
Je pense que la distinction entre application, solution et enterprise architect est un peu artificielle et ne correspond pas vraiment dans de nombreux cas. Rôles comme architecte de sécurité, architecte de données, etc. donner une dissuasion beaucoup plus claire entre les responsabilités. Vous pouvez regarder ici pour plus de détails http://stevendwright.home.comcast.net / ~stevendwright/ArchRoles.htm

En passant, en lisant à nouveau votre question, j'ai remarqué que de nombreux arguments contre le codage des architectes semblent indiquer un fort rôle de gestion/leadership pour l'architecte. Je pense que c'est une bonne idée de séparer les rôles de gestion et d'architecture. Il est préférable que vos techniciens partagent leur temps entre le codage et l'architecture plutôt qu'entre la gestion et l'architecture.

Oui. Les architectes de logiciels qui n'ont pas écrit de code depuis des années perdent le contact avec les réalités de la construction d'un produit. Ils commencent à produire de grands dessins avec des niveaux d'abstraction toujours plus élevés, qui semblent continuer à glisser leurs dates de navire.

Chaque projet sur lequel j'ai travaillé qui a inclus un architecte qui n'a pas passé une partie importante de son temps à travailler avec le code a eu des problèmes en raison de cette absence de connaissances pratiques.

Qui inclut les projets où j'étais cet architecte: -)

C'est maintenant un grand drapeau rouge personnel.

Je suis d'accord avec tous les arguments en faveur des architectes qui codent. Les arguments contre ne sont pas bien ensemble pour moi.

Le code doit abstraire le concepts de haut niveau ainsi que le bas dans une application. À moins que la conception et le code ne soient intégrés à tous les niveaux, la solution sera moins qu'optimale.

Quant à "Le codage est une fonction détaillée orientée vers le bas qui est en contradiction avec la gestion des risques, la nature large de l'architecture" - dans mon expérience, une vue large-et la gestion des risques en particulier-font de meilleurs codeurs pas pire: -)

" L'architecture concerne la gestion des risques techniques et non la mise en œuvre" - il s'agit de la gestion des risques et de la mise en œuvre (et un tas d'autres choses).

"L'architecture est une question de leadership. Il est difficile de mener par derrière " - pourquoi le codage vous met-il derrière? Personnellement, je trouve que le meilleur endroit pour diriger est avec les gens avec qui vous travaillez.

Je (pense) suis architecte, le codage est ce qui rend ce travail amusant.

Ensuite, vous voyez que vos idées prennent vie, vous pouvez voir votre conception fonctionner, et vous pouvez voir les erreurs dans la conception (trop tard de toute façon, mais la prochaine fois...)

Oui, pour garder leur expérience de codage.

Il y a des architectes et il y a des stratèges informatiques. Si vous menez un projet d'intégration impliquant 500 personnes dans plusieurs départements, alors non, cela va vous gêner. Si vous dirigez la conception et la mise en œuvre de quelques 10s de personnes sur un projet de développement, alors oui. Sinon, vous aurez beaucoup moins de chances d'avoir un aperçu approprié de la réalité quotidienne du travail avec votre architecture.

Je ne pense pas qu'ils aient besoin de tout coder dans l'application. Mais ils devraient recevoir certaines tâches. Certains " architectes "sont essentiellement des hacks sans expérience technique qui se font passer pour des" codeurs légendaires " et des systèmes de conception qui ajoutent des semaines ou des mois à la quantité de travail que vous auriez dû faire si vous n'aviez pas d'architecture. S'ils ne peuvent pas écrire de code, ils n'ont aucune affaire à jouer ce rôle...Parce que l'idée est une architecture devrait rendre l'application plus facile à développer et à maintenir. Mais si l'architecte ne peut pas développer, comment saura-t-il faire une architecture?

De plus, même les meilleurs architectes prennent de mauvaises décisions. Parfois, quelque chose a fière allure sur le tableau blanc, mais en réalité, une décision architecturale finit par rendre les choses beaucoup plus difficiles qu'elles ne devraient l'être. Si l'architecte doit manger sa propre nourriture pour chien (et utiliser l'architecture), il est plus enclin à vouloir corriger les mauvaises décisions ou à les contourner. De plus, en touchant le code, ils le connaissent au moins un peu. Donc, si un développeur vient à eux avec un problème de codage, les yeux de l'architecte ne seront pas émaillés car il/elle rejette le développeur et dit que le développeur le fait mal mais n'offre aucun aperçu sur la bonne façon de le faire.

L'architecte n'a pas besoin de faire de gros projets dans la base de code. Mais ils devraient au moins effectuer de petites tâches dans la base de code qui les obligent à utiliser leur propre architecture. Également les petites tâches impliqueront probablement de lire beaucoup de code d'autres personnes pour leur donner une idée de la façon dont les gens utilisent l'architecture et si quelque chose peut être fait pour l'améliorer.

Comme Vlion l'a déclaré, poser cette question dans une communauté majoritairement dominée par les développeurs signifie que les réponses seront biaisées vers "oui".

En tant que quelqu'un qui a "architecte" dans son titre de travail mais qui a également récemment reçu l'insigne d ' "Ingénieur distingué", ma loyauté est déchirée. En général, je pense que le codage n'est généralement pas une utilisation efficace du temps d'un architecte. Alors que dois-je faire?

• Comprendre l'entreprise.
• Comprendre les systèmes utilisés pour permettre à l'entreprise.
• Travailler avec l'entreprise sur la stratégie et les tactiques informatiques.
• S'assurer que les projets en cours sont réalisés avec une vue à long terme, où le gestionnaire de projet se concentre sur la vue à court terme.

Alors, comment un architecte doit-il rester en contact avec la réalité? Je pense que par des réunions régulières et des promenades, juste parler aux gens à tous les niveaux et huiler les roues de la communication.

J'en suis venu à croire que, le plus souvent, les "détails d'implémentation" ne sont pas des détails (dans le sens où de nombreux problèmes surviennent lorsque vous considérez certains problèmes d'implémentation spécifiques comme de simples détails qui pourraient être ignorés comme des minuties d'un point de vue "architectural")

Un architecte d'application doit être capable de définir une architecture d'application, de concevoir l'application, d'implémenter les modèles et de coacher d'autres pour coder. Si vous ne pouvez pas faire ces choses, vous n'êtes pas un architecte d'application.

Parfois, ils doivent coder. Par exemple, lorsque l'équipe n'est qu'une seule personne.

À mon avis, ils peuvent coder s'ils le veulent mais ne doivent pas perdre la vue d'ensemble. Un pas est de changer les structures conçues tous les jours.

Vous demandez cela sur un site de codage. Vous allez obtenir fondamentalement tout le monde tomber sur le "oui" côté.

Mon point de vue est, oui, mais seulement assez pour suivre les besoins changeants, pas plus

Puisque tout le monde ici est un codeur, les favoris doivent être les hells-oui réponse - et vous n'aurez aucun désaccord de ma part.

Mais la réponse à grain plus fin est plus correcte à mon avis, car elle valorise de manière appropriée l'expertise du domaine. Les gens qui connaissent peu bout logiciel, mais il suffit de l'utiliser sont si précieux.

La répartition des rôles architecturaux semble dépendre de la taille et de la nature de l'organisation.

Si je l'avais à ma façon, je donnerais au client un rôle de l'architecte d'histoire s'ils écrivent des histoires et des cas d'utilisation bons, utiles et détaillés.

Le simple fait d'écrire les interfaces compterait-il comme du code? Si c'est le cas, c'est le minimum que j'attendrais d'un architecte, alors que dans d'autres cas, il peut s'agir de beaucoup plus de code de leur part, comme des classes avec des stubs pour les méthodes.

L'architecture est une compétence essentielle pour les développeurs de logiciels. Il peut y avoir quelques rares occasions où il pourrait être logique pour un architecte de ne pas coder, mais je ne me souviens pas avoir jamais rencontré de telles occasions dans ma propre expérience.

L'architecte doit coder sur le projet ou, au minimum, être pleinement capable de coder sur le projet. La deuxième partie de cela signifie qu'ils doivent être capables de coder en utilisant les outils et les techniques utilisés par le reste de l'équipe. (Sans poursuivre pour coder, il doit être très difficile de maintenir ces compétences.)

Enfin, lorsque les architectes sont chargés de choisir les outils et les techniques à utiliser par d'autres, ils ne peuvent pas bien faire un tel choix sans utiliser réellement les outils proposés. Dans ce scénario, l'architecte non codant dégénère rapidement en un patron aux cheveux pointus avec une pile de brochures sur son bureau.

Je me demande pourquoi personne n'a mentionné les revues de code ou la programmation par paires qui peuvent remplacer le codage.

Je passe beaucoup plus de temps à lire le code et à résoudre des problèmes avec mes collègues qu'à coder. Cela me donne presque la même compréhension du code, de sa structure et de sa complexité que de l'écrire moi-même et prend beaucoup moins de temps. Quand je code, je le fais pour le plaisir ou pour explorer de nouvelles technologies (C'est le seul endroit où j'ai trouvé le codage utile).

L'architecture est un rôle de haut niveau et ne devrait pas être préoccupé par la mise en œuvre > détails

Le code est le design. Imaginez un architecte qui conçoit de jolis bâtiments mais refuse d'entrer dans les détails de mise en œuvre comme où mettre les sorties de fusion, la plomberie, l'électricité, les ascenseurs ou les problèmes juridiques de construction.

* Coding is a detailed oriented, heads-down funtion which is at odds

Avec la gestion des risques, vue d'ensemble nature de l'architecture

Lorsque vous codez, au début, concentrez-vous sur les détails. Ensuite, vous refactorisez avec un objectif plus large.

L'architecture est une question de leadership. Il est difficile de mener par derrière

Le front de bataille du développement logiciel est le codage. Peut être le chef de produit ou le chef de projet ne code pas. Mais l'architecte a besoin de le faire. Peut-être qu'il devrait passer plus de temps à refactoriser montrant à quel point le code peut être bon. De cette façon, il mène par l'exemple.

Au risque de s'écarter du sujet...

Sur une application à grande échelle, il peut ne pas être possible pour un architecte de rester à jour avec le code en cours d'écriture. De plus, il ne lui serait pas possible d'écrire le code en raison d'autres responsabilités importantes. Cela dit, je recommanderais que l'architecte ne perde pas la vue d'ensemble de la base de code en cours de développement. Cela peut être réalisé en surveillant la base de code pour la couverture du code, les mesures sur la qualité du code, analyse de code statique, etc. Il devrait évaluer régulièrement la qualité du code en utilisant les critères mentionnés. Les pratiques d '"intégration continue" peuvent aider ici.

Cette réponse standard des développeurs est qu'un architecte devrait également coder. Mais c'est une sorte de développeur qui met la technologie en premier. Mais j'ai tendance à être en désaccord. Oui, il est bénéfique d'avoir des compétences en codage, afin de pouvoir revoir le code.

Mais la seule chose qu'un architecte fait est de réunir les exigences métier avec la mise en œuvre. Et dans notre cas le code. Si vous avez un système très complexe, vous ne pouvez pas coder et faire de l'architecture en même temps, parce que vous opérez à trop de niveaux d'abstraction différents.

Au lieu de cela, vous devriez pouvoir compter sur les développeurs. Ils devraient être en mesure de décrire les aspects de la mise en œuvre, et comment il correspond à l'exigence métier que vous leur avez souligné. La technologie choisie est la décision des architectes, mais pour en arriver à cette décision, il doit faire des recherches ou utiliser l'expérience passée. Cela ne signifie pas qu'il ne parle pas aux développeurs, ou les laisse enquêter sur un spécifique technologie pour voir si l'architecture fonctionne vraiment.