En tant qu'architecte logiciel, suis-je censé me concentrer autant sur l'analyse des journaux et la correction des bugs d'autrui?

Depuis l'obtention de mon diplôme (fin 2005), je travaillais pour la même entreprise en tant qu'ingénieur logiciel c ++. Il y a un an, j'ai été promu architecte logiciel mais je me suis retrouvé de plus en plus impliqué dans la qualification et la correction des bugs, support niveau 2.

50% de mon temps passé dans Notepad ++ à analyser les journaux du logiciel et à essayer de comprendre ce qui n'allait pas. 30% corrigeant les bugs des autres utilisateurs et le reste (le cas échéant) examinant le code spaghetti des développeurs.

J'ai commencé à détester ce produit et à réfléchir à une stratégie de sortie de l'entreprise.

Que penses-tu que je puisse faire dans cette situation? Est-ce que d'autres architectes logiciels corrigent encore des bogues dans le code?

La plupart des gens conviennent généralement qu'un architecte logiciel devrait être principalement impliqué dans la conception de haut niveau, l'établissement de normes, le choix d'outils ou de cadres, l'évaluation de produits, la mise en œuvre de prototypes et la démonstration de concepts, ainsi que la formation et le mentorat des développeurs.

Cependant, le titre peut souvent être une nomination politique à un développeur, un titre spécial attribué aux développeurs principaux de projets, ou même quelque chose d'aussi simple qu'une solution de contournement management-RH pour embaucher un développeur indispensable à un salaire ou à un taux Les ressources humaines ou la haute direction trouveraient inacceptable le titre de développeur de logiciel ou d’ingénieur en logiciel.

En d'autres termes, les titres sont généralement dépourvus de sens.

L'article de Wikipedia définit l' architecte logiciel comme suit :

un programmeur informatique qui fait des choix de conception de haut niveau et dicte des normes techniques , y compris des normes de codage de logiciel, des outils ou des plates-formes ...

Étant donné ci-dessus, vos estimations "50% de mon temps passé ... à analyser les journaux du logiciel ... 30% corrigeant les bogues d'autrui" vous placent bien loin de ce que l'architecte logiciel devrait normalement faire.

• Je dirais ci-dessus rend le titre qu'ils vous ont donné sur les 50+30=80%faux.

Notez que des activités telles que l'analyse des journaux ou la correction de bogues peuvent légitimement occuper une partie du temps de l'architecte, à condition que ces tâches servent l'objectif principal de ce rôle, à savoir faire des choix de conception de haut niveau et établir des normes techniques. En fait, c'est le cas pour tout type d'activités de développement, de maintenance et de test de logiciels.

Par exemple, si l'analyse des journaux vous permettait de comprendre comment faciliter les choses - en améliorant la conception, les outils ou les normes de codage - cela constituerait un effort parfaitement justifiable pour un architecte. De même, il pourrait être tout à fait correct pour un architecte de se familiariser avec la résolution d'un ou plusieurs bugs particuliers, à condition que cela entraîne des améliorations spécifiques de la conception et des processus, entraînant une réduction du taux de bogues, etc.

_{Sur une note un peu plus positive, votre question met en évidence au moins une compétence assez importante pour l’architecte: la capacité de classer différentes activités et de suivre les efforts consacrés à celles-ci. Pensez à ajouter à votre "boîte à outils" des compétences complémentaires pour résumer vos observations et vos estimations et les communiquer clairement, en particulier à l’échelle de la direction. :)}

En tant qu'architecte logiciel, suis-je censé me concentrer autant sur l'analyse des journaux et la correction des bugs d'autrui?

Supposé? Oui et non. Vous êtes responsable de la totalité de la qualité du produit et de son évolution - faites-le fonctionner demain, mais également l'année prochaine.
Est-ce que cela signifie donner un coup de main pour résoudre des problèmes difficiles? Absolument - au moins je le fais. Vous ne pouvez pas faire fonctionner le produit demain si vos clients vous quittent.
Cela signifie-t-il que vous devriez consacrer TOUT votre temps à cela? Absolument pas. Vous êtes responsable de la TOTALITÉ de la qualité et de l'évolution. Consacrer autant de temps à la recherche de problèmes est contre-productif.

Vous êtes censé être proactif:

1. Initiez des plans d’éducation pour que d’autres personnes (dev / support) puissent lever la charge. "apprendre à un homme à pêcher" et tout ce jazz.
2. Inventez des moyens et développez des outils pour permettre une analyse plus simple et plus rapide des défauts et l’isolement des causes premières. Si vous trouvez cela ennuyeux, d'autres développeurs, peut-être moins talentueux ou expérimentés, le trouvent non seulement ennuyeux, mais également difficile et peut-être même décourageant. Aidez-les à surmonter cela grâce à la technologie.
3. Démarrez un effort pour améliorer la qualité du produit (simplifiez, modulez, créez des cadres de test), donnez l'exemple, ne vous faites pas gémir et menacer de quitter.
4. Assurez-vous que les développeurs savent ce que vous faites - mais aussi vos gestionnaires. Le rôle d'un architecte est bien plus une affaire de relations avec d'autres que de codage et d'analyse. Autant que vous pourriez détester cela, la politique joue un rôle clé ici. En vous assurant que vos pairs voient vos réalisations, il sera plus facile de les convaincre plus tard que vous avez raison. Si vous n'y êtes pas encore, soutenez vos revendications par la recherche et les points de contact.
5. Si tout échoue, et seulement après avoir passé du temps à essayer d'améliorer les choses, parlez-en à votre responsable. Dites que vos compétences sont mieux utilisées lors des phases de planification et de conception et voyez ce qui peut être fait pour changer la situation actuelle. Votre produit est peut-être à la limite et la réponse de votre responsable peut être "nous avons besoin de vous pour cela, ici et maintenant". J'insisterais cependant sur un plan à long terme: comment allons-nous changer la situation actuelle?

Je vois le rôle d'architecte comme un privilège. Vous pouvez influencer le produit comme peu de gens le peuvent - le seul théoriquement plus influent que vous est le responsable de la R & D du produit (et éventuellement du marketing) - mais il est trop occupé à gérer.

Le rôle d'un architecte logiciel ne les a pas traditionnellement corrigés. Les architectes logiciels aident effectivement à résoudre les problèmes de conception des logiciels. Si, par bogue, vous entendez donc la manière dont le logiciel a été conçu se prête davantage à la fragilité ou à la difficulté d’agrandissement / maintenance, il incombera au SA de proposer ou de redéfinir les aspects de la logiciel pour résoudre ce problème.

Compte tenu de ce que vous avez dit:

50% de mon temps passé dans Notepad ++ à analyser les journaux du logiciel et à essayer de comprendre ce qui n'allait pas. 30% corrigeant les bugs des autres utilisateurs et le reste (le cas échéant) examinant le code spaghetti des développeurs.

Ce n’est pas le rôle d’un véritable administrateur système, c’est plutôt ce que je souhaiterais que nos programmeurs développeur 1 et développeur 2 commencent avec un développeur senior. Je dis cela en particulier parce que je trouve que cela aide vraiment les nouveaux développeurs de notre société à entrer dans le produit et le code en travaillant à ce niveau sur des problèmes de qualité du code. Êtes-vous un nouvel administrateur système dans votre entreprise et ils vous demandent de faire ce travail pour entrer dans le système? Si c'est le cas, c'est peut-être acceptable pour une courte période. Si tel est votre travail quotidien et ce depuis plus d’un an, il est peut-être temps de chercher un autre rôle.

Je comprends votre frustration, mais comprenez si vous écrivez le code ou si vous êtes le dernier à le toucher, le temps presse, et ils peuvent vous contacter, de nombreux responsables vont vous voir pour le corriger, quel que soit votre titre.

Si vous pensez que vous avez encore des amis dans le groupe de développement en crise, vous aiderez. Le problème, c’est quand, et plus important encore, leur direction s’habitue à vous aider, ils continuent à revenir. Comme le dit "aucune bonne action ne reste impunie." S'ils peuvent compter sur vous pour résoudre les problèmes, quel que soit votre titre, vous êtes simplement un autre développeur et une autre personne qu'ils peuvent utiliser.

C'est un problème difficile à résoudre, mais mon conseil est le suivant:

1. Demandez le numéro de facturation du projet pour cette heure du projet d'architecte non logiciel. Je trouve que les chefs de projet ne sont pas aussi pressés de demander votre temps, s’ils doivent en rendre compte.

2. Discutez avec votre responsable du temps perdu et des groupes ou projets concernés. Votre responsable peut vous dire de ne pas les aider et de rester concentré sur ses projets. Si tel est le cas, l’autre groupe vient et demande de l’aide, vous leur dites que votre patron n’a pas dit trop.

3. Organisez votre travail en gardant vos priorités claires et ne soyez pas si réactif face à vos projets d'architecture.

4. Agissez comme un architecte, demandez à vos pairs de vous voir comme un architecte et non comme le même développeur que vous avez été pendant toutes ces années. Vous avez l'habitude de vous traiter comme un développeur.

Bonne chance.

Non, vous êtes ici pour gérer la situation dans son ensemble.

Vous avez un problème de gestion: la résolution des bugs et l'amélioration de la qualité du code sont le travail des développeurs, en tant qu'architecte, vous devez lui donner des directives et l'architecture réelle (UML ou tout ce qui flotte dans votre bateau), puis en examinant régulièrement le code pour s'assurer que ces instructions sont suivies correctement. .

Cependant, vous pouvez implémenter et corriger des bugs sur l’architecture principale.

Exemple: vous travailleriez sur PRISM, MEF, etc. dans un projet WPF / C #, mais vous ne travailleriez pas sur XAML pour afficher l'écran de démarrage.

Vous travailleriez sur une conception de base de données, mais vous n'écririez pas de procédures stockées pour les opérations CRUD.

etc.

Une partie de la solution consisterait à trouver un ingénieur disposé à assumer cette charge.

Bien sûr, la raison en est que vous trouvez ce travail indésirable, ce qui n’envoie pas le message qu’il est attrayant pour les autres ingénieurs, ils ne sont donc pas impatients de le reprendre.

Je vois deux possibilités.

1. On vous a confié le poste d'architecte pour pouvoir travailler sur de plus grands éléments d'image.
   Dans ce cas, vous devez indiquer à la direction que vous ne pouvez pas travailler sur ces éléments plus généraux, car personne n’a pris la relève pour assumer le rôle de support de niveau inférieur. C'est alors leur problème à résoudre.

2. Le titre est en grande partie cérémonial - un os jeté à vous pour vous garder.

Dans ce cas, la direction pourrait ne pas être très intéressée par la réduction de votre charge de support.

-

Une chose qui ne vous aidera certainement pas à atteindre votre objectif est d’adopter une attitude de mépris pour les autres développeurs et ingénieurs que je vois transparaître dans votre question. Vous voulez que ces personnes s’intègrent et gèrent ces problèmes en toute confiance afin que vous n’y soyez pas obligé (éventuellement en faisant des erreurs en cours de route). S'ils savent que vous ne ferez que critiquer leurs solutions et que vous les corrigerez plus tard, ils ne feront probablement jamais un pas en avant.

50% de mon temps passé dans Notepad ++ à analyser les journaux du logiciel et à essayer de comprendre ce qui n'allait pas. 30% corrigeant les bugs des autres utilisateurs et le reste (le cas échéant) examinant le code spaghetti des développeurs.

C'est certainement un type de travail que vous n'êtes PAS censé faire pour ce rôle. Selon mon expérience / mes observations, l’ architecte doit être impliqué dans la conception des applications, les améliorations, la clarification des exigences techniques et les problèmes de performances potentiels (ne pas vérifier les journaux quotidiennement, mais surtout analyser les problèmes / erreurs graves) qu’il faut résoudre ou éviter.

En d'autres termes, mon point n ° 1 est le suivant: les architectes sont des concepteurs de haut niveau et des intégrateurs de systèmes possédant une expérience pratique de la manière dont les rouages ​​de la technologie fonctionnent / s'appliquent et doivent être utilisés.

Si vous avez la possibilité d'attribuer et de gérer la qualité du code, vos compétences en matière de gestion du travail doivent être améliorées. Ainsi, la planification du travail devrait être votre priorité sur l'approche "comment faire le travail".

Point n ° 2 : si vous êtes l’un des rares développeurs utilisant ces applications, alors ce titre n’est qu’un nouveau glaçage au sucre proposé par la direction de la société pour vous permettre de conserver le même rôle de "réparateur" avec un nouveau titre original .

Le rôle d'un architecte logiciel est bien plus que ce que vous faites dans votre entreprise actuelle. Il est responsable de la définition des normes de conception des logiciels, de la conception de haut niveau, des normes de codage, etc., et de la correction des bogues, ce qui n’est en fait qu’une petite partie de la réalité. Mais comme vous l'avez dit, vous travaillez sur un produit, cela signifie que, en tant qu'architecte logiciel, vos attentes en matière de fiabilité du produit seront assez élevées et, dans un tel cas, votre implication dans de telles choses ne sera pas seulement aider le produit mais aussi la société, car vous êtes assez expérimenté dans ce domaine. Mais vous devriez également être familiarisé avec le développement de nouvelles fonctionnalités et de nouvelles tâches, ce qui inculquera votre intérêt pour votre organisation actuelle.

En tant qu'architecte logiciel, suis-je censé me concentrer autant sur l'analyse des journaux et la correction des bugs d'autrui?

En parlant de «oui».

Voici comment je qualifierais ma réponse:

1. Par défaut, vous devez laisser les développeurs de logiciels analyser les journaux et corriger les bogues.
2. Cependant ... Vous devez être conscient des défauts entraînant une perte de données, un retour en arrière fastidieux de la base de données, un délai de traitement important pour les développeurs, ou des excuses du client.
   1. En règle générale, vos rapports directs doivent vous informer de ces défauts.
   2. Vous devez créer une culture dans laquelle vos subordonnés directs se sentent habilités à vous informer de ces défauts, sans être obligés de vous en parler.

Plus sur le n ° 2:

1. Ces types de défauts impliquent généralement une défaillance architecturale. Quand ils le font, vous devez comprendre la nature précise du défaut et créer un correctif.
   1. Donc, par extension, vous devez être prêt, disposé et capable de parcourir les journaux et de corriger les bugs des autres (même si vous ne commettez pas directement le code dans le référentiel de code source).

La réponse est probablement non. Pourquoi passez-vous tant de temps à résoudre les problèmes de débogage et de support? Est-ce que quelqu'un vous attribue ce travail?

Il semble que vous deviez clarifier ce que vous devriez faire. Vous devrez peut-être corriger des bugs; cela ne devrait probablement pas être la majorité de votre temps.