Il y a eu beaucoup de questions avec de bonnes réponses sur le rôle d'un architecte logiciel (SA) sur StackOverflow et Programmers SE . J'essaie de poser une question un peu plus ciblée que celles-ci. La définition même d'une SA est large donc pour cette question, définissons une SA comme suit:
Un architecte logiciel guide la conception globale d'un projet, s'implique dans les efforts de codage, effectue des revues de code et sélectionne les technologies à utiliser.
En d'autres termes, je ne parle pas de repos managérial et de gilet à la crête (d'autres mots riment bien) des SA. Si je devais poursuivre n'importe quel type de poste SA, je ne veux pas être loin du codage. Je pourrais sacrifier du temps pour interagir avec les clients et les analystes commerciaux, etc., mais je suis toujours impliqué techniquement et je ne suis pas seulement au courant de ce qui se passe lors des réunions.
Avec ces points à l'esprit, que devrait apporter un SA à la table? Doivent-ils entrer avec une mentalité de "poser la loi" (pour ainsi dire) et de faire respecter l'utilisation de certains outils pour s'adapter "à leur manière", c'est-à-dire les directives de codage, le contrôle des sources, les modèles, la documentation UML, etc.? Ou devraient-ils spécifier la direction et la stratégie initiales, puis être décontractés et intervenir au besoin pour corriger la direction du navire?
Selon l'organisation, cela peut ne pas fonctionner. Une SA qui s'appuie sur TFS pour appliquer tout peut avoir du mal à mettre en œuvre son plan chez un employeur qui utilise uniquement StarTeam. De même, une SA doit être flexible en fonction de l'étape du projet. S'il s'agit d'un nouveau projet, ils ont plus de choix, alors qu'ils pourraient en avoir moins pour les projets existants.
Voici quelques histoires de SA que j'ai vécues comme un moyen de partager quelques informations dans l'espoir que les réponses à mes questions pourraient également éclairer ces questions:
J'ai travaillé avec un SA qui a révisé littéralement chaque ligne de code de l'équipe. L'AS ferait cela non seulement pour notre projet, mais pour d'autres projets de l'organisation (imaginez le temps consacré à cela). Au début, il était utile de faire respecter certaines normes, mais plus tard, il est devenu paralysant. FxCop était la façon dont le SA trouverait des problèmes. Ne vous méprenez pas, c'était un bon moyen d'enseigner aux développeurs juniors et de les forcer à penser aux conséquences de leur approche, mais pour les développeurs seniors, c'était considéré comme quelque peu draconien.
Une SA particulière était contre l'utilisation d'une certaine bibliothèque, affirmant qu'elle était lente. Cela nous a obligés à écrire des tonnes de code pour réaliser les choses différemment alors que l'autre bibliothèque nous aurait fait gagner beaucoup de temps. Avance rapide jusqu'au dernier mois du projet et les clients se plaignaient de la performance. La seule solution était de changer certaines fonctionnalités pour utiliser l'approche initialement ignorée malgré les premiers avertissements des développeurs. À ce stade, beaucoup de code a été jeté et non réutilisable, ce qui a entraîné des heures supplémentaires et du stress. Malheureusement, les estimations utilisées pour le projet étaient basées sur l'ancienne approche que mon projet était interdit d'utiliser, donc ce n'était pas un indicateur approprié pour l'estimation. J'entendais le PM dire "nous l'avons déjà fait",
Le SA qui imposerait l'utilisation des DTO, des DO, des BO, des couches de service, etc. pour tous les projets. Les nouveaux développeurs ont dû apprendre cette architecture et les directives d'utilisation de SA. Des exceptions aux directives d'utilisation ont été faites lorsqu'il était absolument difficile de suivre les directives. Le SA était fondé sur son approche. Les classes pour les DTO et toutes les opérations CRUD ont été générées via CodeSmith et les schémas de base de données étaient une autre boule de cire similaire. Cependant, ayant utilisé cette configuration partout, la SA n'était pas ouverte aux nouvelles technologies telles que LINQ to SQL ou Entity Framework.
Je n'utilise pas ce post comme plateforme pour la ventilation. Il y avait des aspects positifs et négatifs à mes expériences avec les histoires de SA mentionnées ci-dessus. Mes questions se résument à:
- Que devrait apporter un SA à la table?
- Comment peuvent-ils trouver un équilibre dans leur prise de décision?
- Doit-on aborder un emploi SA (tel que défini précédemment) avec la mentalité qu'ils doivent appliquer certaines règles de base?
- Autre chose à considérer?
Merci! Je suis sûr que ces tâches sont facilement étendues aux personnes qui sont des cadres supérieurs ou des responsables techniques, alors n'hésitez pas à répondre à ce niveau également.