Les nombreux chapeaux en génie logiciel | de Ray Naldo | janvier 2023

Comment passer au niveau supérieur en tant qu’ingénieur logiciel – sans programmation

Le logiciel est la force motrice du monde d’aujourd’hui. Combien y en a-t-il dans le monde ? Des milliards, peut-être. Personne ne sait. Mais je pense que nous sommes tous d’accord sur le fait que tous les logiciels ont un but et que le meilleur logiciel est un logiciel qui fonctionne.

Maintenant, c’est là que nos chemins peuvent se séparer.

Pour moi, c’est un logiciel qui résout les problèmes des utilisateurs. Accent mis sur l’utilisateur.
Ces utilisateurs peuvent être nous, des chefs de produit, des utilisateurs finaux, des amis, des inconnus, n’importe qui.

Ainsi, le génie logiciel résout des problèmes par le biais de logiciels.
Résolvons-nous les bons problèmes ? S’agit-il vraiment de problèmes d’utilisateurs ?
C’est ce qui en fait « l’ingénierie ».

Le code, les blocs de construction du logiciel, devrait être orienté vers cet objectif. Les logiciels qui résolvent des problèmes inexistants sont le produit d’une ingénierie excessive.

Ingénieur pièce

Un programmeur n’est pas un ingénieur logiciel. Conceptuellement, un programmeur est un entrepreneur en logiciels. Il est courant que les programmeurs travaillent sur une seule étape du cycle de vie d’un projet à la fois. Un élève du primaire peut être un programmeur, un analyste financier peut être un programmeur et une IA peut être un programmeur 0.1x.

Un ingénieur logiciel est un programmeur, oui, mais il supervise également l’ensemble du SDLC (Software Development Life Cycle). La planification, l’analyse, la conception, le développement, les tests et la maintenance sont le pain quotidien des ingénieurs logiciels.

Il existe de nombreux parallèles entre le génie logiciel et les rôles d’ingénierie plus traditionnels. Comme un ingénieur conventionnel, un ingénieur logiciel est responsable de la conception, de la construction et de la maintenance des systèmes en tant que solutions aux problèmes du monde réel.

Partie psychologue

Toute personne impliquée dans un projet de développement logiciel a peut-être remarqué que la psychologie joue un rôle important dans la réussite du projet. Que ce soit la gestion de l’équipe ou nos propres émotions, les deux nécessitent des approches psychologiques. La psychologie joue également un rôle important lors de la collecte des besoins et du support de production.

Parfois, nous devons écouter les utilisateurs pour qu’ils s’ouvrent sur leurs problèmes. Parfois, les utilisateurs ne savent pas ce qu’ils veulent, et même s’ils le savent, ce n’est pas toujours ce dont ils ont besoin. C’est pourquoi agir uniquement sur les commentaires des utilisateurs est discutable. Agir sur les commentaires des utilisateurs et sur la façon dont ils effectuent leurs tâches, soit en les observant, soit par des analyses d’utilisation détaillées, est la norme de référence.

Et, bien sûr, en partie grand-voyant

Construire un logiciel en fonction des exigences fonctionnelles est une voie claire. Construire un logiciel robuste et évolutif pour nos utilisateurs actuels et futurs est une voie obscure. Par définition, la pérennité consiste à anticiper l’avenir et à développer des méthodes pour minimiser les effets des chocs et des stress des événements futurs. L’accent est mis sur la « minimisation ». Cela ne signifie pas que nous devons couvrir tous les scénarios futurs aussi parfaitement que possible. N’oubliez pas YAGNI et EMBRASSER des principes.

La pérennité ne consiste pas à ajouter ou à supprimer des éléments. La pérennité garantit que notre système est conçu pour être flexible et s’adapter aux événements futurs avec seulement des modifications mineures.

La fiabilité, l’évolutivité, la sécurité et la maintenabilité sont quelques éléments qui doivent être soigneusement préparés au cours des phases initiales du développement logiciel. Nous devons atténuer les risques plus que corriger les bogues, implémenter des fonctionnalités en toute sécurité plutôt que d’ajouter des fonctionnalités de sécurité, etc. Pour les systèmes distribués, différents types doivent se concentrer sur différentes choses.

Un système d’échange financier devrait avoir un niveau élevé de cohérence et une faible latence, tandis que le commerce électronique pourrait donner la priorité à une disponibilité élevée et à une faible latence plutôt qu’à la cohérence. L’optimisation des performances est une autre chose délicate. Optimisez tôt, et nous pourrions avoir une optimisation prématurée ; optimiser plus tard, et les utilisateurs peuvent partir lorsque leur patience est épuisée. Pour éviter la malédiction du premier, si le gain n’est pas évident, accompagnez-le toujours de benchmarks et de profilage.

Le génie logiciel est une collaboration entre des experts du domaine (utilisateurs) et des experts techniques. Pour résoudre un problème, bien sûr, nous devons d’abord comprendre le problème. Nous devons entrer dans la tête de nos utilisateurs et comprendre comment ils pensent. Ils vous donneront des informations plus approfondies sur le domaine qui pourraient être utiles plus tard.

Par exemple, lorsqu’on nous demande de mettre en œuvre quelque chose et que nous réalisons un autre moyen qui pourrait résoudre le problème plusieurs fois plus rapidement ou même gratuitement parce que nous l’avons préparé au préalable. Converser avec les utilisateurs peut aussi cultiver la compassion. Nous commençons à réfléchir à ce dont les utilisateurs ont vraiment besoin au lieu de trop d’ingénierie. Cela améliorera la façon dont nous concevons et construisons notre logiciel. L’écoute rapporte des dividendes, vraiment.

La plus ancienne forme de communication humaine est l’écoute. L’écoute nous connecte activement avec le monde – avec les autres. Il établit la confiance avec nos utilisateurs. Il est dommage que la plupart des cours de génie logiciel ne nous enseignent pas la compétence de communication la plus importante. De nombreux étudiants et apprenants doivent l’apprendre à la dure sur le tas. On nous apprend toujours à être de meilleurs programmeurs au lieu de meilleurs ingénieurs en logiciel. On nous apprend toujours à communiquer avec les machines, mais nous laissons de côté la compétence importante qui a tout déclenché : parler avec nos utilisateurs et les écouter.

Oh l’ironie.