Les architectes d’application doivent-ils é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 en matière de conception. Si vous “subissez les conséquences” de vos décisions d’architecture avec eux, alors ils sont beaucoup moins susceptibles de les interroger.

Je vois tout le temps des architectes déconnectés du codage et dont les équipes de développement le connaissent. Ils n’ont pas beaucoup de respect.

Ab-so-frickin-lutely

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 domaine:

• les architectes métier et fonctionnels : ils sont concernés par le stream de travail des opérations et des fonctions, et ils ne devraient jamais coder , car ils doivent pouvoir s’abstraire de tout type d’implémentation et produire des spécifications fonctionnelles laissant la solution technique ouverte .

• les architectes applicatifs : ils divisent un domaine fonctionnel (comme “l’parsing des profits et pertes”) en applications (comme “processeur de portefeuille”, “lanceur”, “répartiteur”, “gui”). Ils n’ont pas besoin de coder, mais ils doivent être d’anciens codeurs afin d’avoir une idée claire des défis techniques auxquels leurs architectures doivent faire face. Leur compétence principale n’est pas de coder, mais d’écouter des collègues techniques afin de choisir la bonne solution. Ils produiront ensuite une mise en œuvre technique qui doit être mise en œuvre (codée).

• architectes techniques : ils sont chargés de choisir et / ou d’implémenter des frameworks techniques (ceux qui sont génériques pour tout projet fonctionnel, comme KPI, logging, gestion des exceptions), et ils doivent absolument coder (et bien coder), puisque leurs composants seront utilisé par toutes les autres équipes fonctionnelles.

• architectes de développement (hey, c’est moi ;)): en charge des outils et des processus de développement, et des enquêtes technologiques, ils doivent aussi coder et aimer le codage .

Je crois donc qu’il n’ya pas qu’une seule réponse: cela dépend de votre domaine d’architecture et de votre expertise: en ce qui concerne les «architectes d’applications», je pense 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 tours en ivoire qui conçoivent un système complet que les petits programmeurs doivent implémenter dans un processus en cascade.

Lors de la réalisation 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 de telles situations, le travail d’un architecte et d’un programmeur est plus étroitement lié. J’ai vu des équipes dans lesquelles les développeurs avaient assumé le rôle d’architectes pour fournir des architectures bien pensées pour des solutions vraiment complexes.

edit En réponse à un commentaire
Je pense que dans la distinction entre application, solution et entreprise, l’architecte est un peu artificiel et ne correspond pas vraiment à de nombreux cas. Les rôles tels que l’architecte de la sécurité, l’architecte de données, etc., permettent de mieux distinguer les responsabilités. Vous pouvez regarder ici pour plus de détails http://stevendwright.home.comcast.net/~stevendwright/ArchRoles.htm

À propos, à la lecture de votre question, j’ai remarqué que nombre d’arguments contre les architectes de codage semblent indiquer un rôle de direction / leadership important 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 votre personnel technique partage son temps entre le codage et l’architecture, entre la gestion et l’architecture.

Oui. Les architectes logiciels qui n’ont pas écrit de code depuis des années ne sont plus en phase avec les réalités de la construction d’un produit. Ils commencent à produire de grands designs avec des niveaux d’abstraction toujours plus élevés, qui semblent continuer à glisser leurs dates de livraison.

Tous les projets sur lesquels j’ai travaillé et pour lesquels un architecte qui ne consacrait pas une grande partie de son temps au code a rencontré des problèmes en raison de l’absence de connaissances pratiques.

Cela inclut les projets où j’étais cet architecte 🙂

C’est maintenant un gros drapeau rouge personnel.

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

Le code a besoin d’abstraire les concepts de haut niveau ainsi que le bas dans une application. Si la conception et le code ne sont pas intégrés à tous les niveaux, la solution ne sera pas optimale.

En ce qui concerne “Le codage est une fonction de base orientée vers le détail, qui est en contradiction avec la gestion des risques, la vision générale de l’architecture” – selon moi, une vue large

“L’architecture concerne la gestion des risques techniques et non l’implémentation” – ce n’est pas le cas. Il s’agit de la gestion des risques et de la mise en œuvre (et de nombreuses autres choses).

“L’architecture concerne le leadership. Il est difficile de mener par derrière” – pourquoi le codage vous place-t-il en arrière? Personnellement, je trouve que le meilleur endroit pour diriger est avec les personnes avec lesquelles vous travaillez.

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

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

Oui, pour garder leur expérience de codage.

Il y a des architectes et des stratèges informatiques. Si vous dirigez un projet d’intégration impliquant 500 personnes réparties sur plusieurs départements, alors non, cela va nuire. Si vous dirigez la conception et l’implémentation de quelques 10 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 doivent tout coder dans l’application. Mais ils devraient recevoir des 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 aucun rôle à jouer dans ce rôle … Parce que l’idée est qu’une architecture devrait faciliter le développement et la maintenance de l’application. Mais si l’architecte ne peut pas se développer, comment sait-il comment 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 le devraient. Si l’architecte doit manger ses propres aliments pour chiens (et utiliser l’architecture), il est plus enclin à vouloir corriger les mauvaises décisions ou à s’en inspirer. En touchant aussi le code, ils sont au moins un peu familiarisés. Donc, si un développeur vient à lui avec un problème de codage, les yeux de l’architecte ne s’éterniseront pas, car il licencie le développeur et dit que le développeur le fait mal, mais n’offre aucune idée de la manière de le faire.

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

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

En tant que “architecte” dans son titre mais qui a récemment reçu le badge de “Distinguished Engineer”, mes loyautés sont déchirées. En général, je pense que le codage n’est pas une utilisation efficace du temps d’un architecte. Alors, que dois-je faire?

• Comprendre l’entreprise.
• Comprendre les systèmes utilisés pour activer 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 dans une perspective à long terme, où le chef de projet se concentre sur la vision à court terme.

Alors, comment un architecte doit-il restr en contact avec la réalité? Je pense par des réunions et des walkarounds réguliers, je parle juste aux gens à tous les niveaux et je roule les roues de la communication.

J’en suis venu à croire que, le plus souvent, les «détails de mise en œuvre» ne sont pas des détails (dans la mesure où de nombreux problèmes sont considérés comme de simples détails d’un sharepoint vue architectural). )

Un architecte d’application doit être en mesure de définir une architecture d’application, de concevoir l’application, d’implémenter les modèles et d’encadrer les autres codes. 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 est une seule personne.

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

Vous demandez cela sur un site de codage. Vous allez essentiellement faire tomber tout le monde du côté “oui”.

Mon sharepoint vue est, oui, mais seulement suffisant pour répondre à l’évolution des besoins, pas plus

Puisque tout le monde ici est un codeur, les favoris doivent être les enfers – ouais, et vous n’obtiendrez aucun désaccord avec moi.

Mais la réponse plus fine est plus correcte à mon avis, car elle valorise de manière appropriée l’expertise du domaine. Les personnes qui connaissent peu le logiciel de combat mais qui l’utilisent sont tellement précieuses.

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 Story Architect s’il écrivait des histoires et des cas d’utilisation utiles, détaillés et utiles.

L’écriture des interfaces compterait-elle comme code? Si c’est le cas, alors c’est le minimum que j’attends d’un architecte, alors que dans d’autres cas, il peut s’agir de code beaucoup plus important, comme les classes avec des stubs pour les méthodes.

L’architecture est une compétence de base pour les développeurs de logiciels. Il peut y avoir quelques rares occasions où un architecte peut avoir du mal à coder, mais je ne me souviens pas d’avoir rencontré de telles occasions dans ma propre expérience.

L’architecte doit soit coder sur le projet ou au minimum, être pleinement capable de coder sur le projet. La seconde partie signifie qu’ils doivent pouvoir coder en utilisant les outils et les techniques utilisés par le rest de l’équipe. (Sans continuer à coder, il doit être très difficile de maintenir ces compétences.)

Enfin, lorsque les architectes sont responsables du choix des outils et des techniques à utiliser par d’autres, ils ne peuvent pas faire un tel choix sans utiliser les outils proposés. Dans ce scénario, l’architecte non codeur dégénère rapidement en un patron aux cheveux pointus avec une stack 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 les problèmes avec mes collègues que le codage. 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 se préoccuper de la mise en œuvre> détails

Le code est le design. Imaginez un architech qui conçoit de jolis bâtiments mais refuse d’entrer dans les détails de la mise en œuvre, par exemple, où placer les issues de la fusion, la plomberie, l’élecsortingcité, les ascenseurs ou les problèmes juridiques.

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

avec la gestion des risques, la nature large de l’architecture

Lorsque vous codez, commencez par vous concentrer sur les détails. Ensuite, vous refactorez avec un objective plus large.

L’architecture concerne le 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 doit le faire. Peut-être devrait-il consacrer plus de temps à la refactorisation en 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, un architecte ne peut pas restr à 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 une grande image 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 mésortingques sur la qualité du code, l’parsing du code statique, etc. Il devrait régulièrement évaluer la qualité du code en utilisant les critères mentionnés. Les pratiques de «l’continuous integration» peuvent aider ici.

Cette réponse standard des développeurs est qu’un architecte devrait également être en train de coder. Mais c’est une sorte de développeur qui met la technologie au premier plan. Mais j’ai tendance à être en désaccord. Oui, il est utile d’avoir des compétences en codage pour pouvoir réviser le code.

Mais la seule chose qu’un architecte fait est de rassembler les exigences de l’entreprise avec l’implémentation. 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, car vous utilisez trop de niveaux d’abstraction différents.

Au lieu de cela, vous devriez pouvoir compter sur les développeurs. Ils doivent être en mesure de décrire les aspects de la mise en œuvre et la manière dont ils s’inscrivent dans les exigences commerciales que vous leur avez signalées. La technologie choisie est la décision des architectes, mais pour prendre cette décision, il doit faire des recherches ou utiliser des expériences passées. Cela ne signifie pas qu’il ne parle pas aux développeurs, ni ne les laisse enquêter sur une technologie spécifique pour voir si l’architecture fonctionne vraiment.