En tant que responsable de l’ingénierie, si jusqu’à présent vous n’avez fait que vous concentrer sur.. :

• Rédaction d’un programme exécutable dans un délai précis pour répondre aux besoins du client/des parties prenantes.
• Expédition d’un produit qui n’est pas défectueux et qui fonctionne bien
• Respecter les calendriers exacts de mise à disposition des produits

… bien, vous vous en sortez bien du point de vue commercial. Mais il y a une partie importante et pourtant souvent négligée de la construction d’un produit que vous risquez d’ignorer : les principes de base d’un code propre.

Certains dirigeants ont tendance à ne pas tenir compte de cet aspect et causent une injustice à l’égard de l’aspect technique du produit.

Oui, combien de fois votre équipe s’est-elle retrouvée coincée à travailler sur le code désordonné de quelqu’un d’autre ? Ou vous avez du mal à créer des fonctionnalités ? Ou à la recherche d’une documentation bien rédigée pour les guider ?

Les risques sont plus fréquents, et tous ces événements signalent l’intégration d’une dette technique supplémentaire dans le produit sous la forme d’un code spaghetti.

Cela m’amène à notre sujet,

Voyons ce qu’il a à nous dire sur le sujet.

Keerthi : À l’heure actuelle, les entreprises qui possèdent des produits logiciels hérités se retrouvent avec une dette technique importante sous la forme d’un code spaghetti. De votre point de vue, quels sont les éléments que les entreprises négligent lorsqu’elles conçoivent des logiciels ?

Jana : Tout d’abord, je pense que l’équipe d’ingénieurs doit savoir quelles sont les priorités de la direction ; par exemple, il y a un risque de dette technique et de code spaghetti qui s’infiltre dans la base de code lorsqu’il y a un calendrier de publication agressif ou lorsque les processus d’ingénierie tels que CI/CD ne sont pas articulés correctement par la direction.

Deuxièmement, les dirigeants doivent trouver un moyen de mettre en place des processus d’ingénierie qui ont une grande capacité de pardon.

Souvent, les dirigeants peuvent fixer des attentes très élevées en termes d’automatisation – tout code que vous écrivez doit être entièrement automatisé, et ensuite ils disent, l’attente est si claire que je ne vous permettrai pas de vérifier un code qui n’est pas entièrement automatisé d’un point de vue des tests.

Cependant, les développeurs sont toujours confrontés à des défis lorsqu’il s’agit de s’assurer qu’ils disposent de cas de test entièrement automatisés. Pourtant, ils parviennent parfois à proposer ce que j’appelle des cas de test exécutables, dans le sens où ils fonctionnent bien dans leur ID, Eclipse, etc.

Dans ce cas, il ne s’agit pas d’une bonne culture car, même si la demande est correcte et extrêmement élevée, il n’y a pas de possibilité de pardon.

Nous devons permettre aux développeurs d’adopter au moins ce type de pratique, que j’appelle une pratique d’ingénierie extrêmement exigeante mais indulgente.

C’est pourquoi il est essentiel que les dirigeants en prennent conscience et procèdent à des améliorations au fil du temps, plutôt que de fixer des attentes très élevées dès le départ et de forcer l’équipe à échouer.

Keerthi : Votre opinion : Qu’est-ce qui pousse l’équipe d’ingénieurs à rendre le code désordonné ?

Jana : Intentionnellement, personne ne voudrait écrire un code désordonné. D’après mon expérience, cela se produit généralement lorsque l’équipe d’ingénieurs est composée de jeunes gens qui sont soit en phase d’apprentissage, soit en phase initiale – lorsqu’ils se lancent dans une autre activité de correction de bogues ou dans l’ajout d’une nouvelle fonctionnalité – et qu’ils manquent de clarté en termes de technologie, de cadre ou d’infrastructure du produit.

Vous voyez, le développement de logiciels est un processus continu.

Même si tous les processus continus sont assortis d’excellentes procédures opérationnelles normalisées, les nouvelles personnes qui participent à la construction de vieilles choses vont casser des choses, et c’est courant.

Je pense donc qu’ils ont besoin d’une sorte de mentorat ou d’un tuteur qui doit être présent tout le temps, ou du moins la plupart du temps.

Et ce que je pense, c’est que tous les codes désordonnés ne sont pas de la dette technique.

Les responsables de l’ingénierie devraient investir dans la construction d’une base de code très sophistiquée en termes de fiabilité et de robustesse, qui mettra la base de code en bac à sable à un niveau tel que vous saurez que le code désordonné n’aura pas d’impact sur la continuité des activités et ne deviendra pas une erreur coûteuse.

Keerthi : Qui est responsable de la dette technique ?

Jana : Je dirais que la personne qui possède ce morceau de code particulier est responsable, mais que la direction est responsable.

Keerthi : Qu’est-ce qui se cache derrière le terme “code propre” ? Insistez sur les avantages qu’elle peut apporter à la qualité des produits et à l’entreprise en général.

Jana : J’ai quelques attentes concernant la propreté du code :

1. Maintenabilité – Le système doit être suffisamment simple pour être compris par toute personne qui l’utilise nouvellement.
2. Un code propre est un code qui fonctionne dans un environnement de production 24 heures sur 24, 7 jours sur 7, avec un minimum de problèmes.
3. Un code propre garantit toujours une piste d’audit appropriée en cas de problème.
4. Tout ce que fait cette base de code doit être exposé sous la forme d’une API. Rien ne doit être massé dans le code sur certains fichiers de propriété ou dans certaines bases de données.
5. Un code propre doit présenter une représentation claire de la logique d’entreprise. Plus important encore, il doit avoir un certain sens de la documentation à plusieurs niveaux.

Pour résumer, si une base de code est construite de manière à ce que les équipes n’aient pas à lutter contre les incendies en production, à effectuer des corrections de dernière minute, à appuyer sur le bouton de publication en retard sur le calendrier ou à souffrir de l’insatisfaction des clients, alors j’appellerais ce code un code propre.

Keerthi : Veuillez partager quelques conseils pour laisser un code plus propre que vous ne l’avez trouvé.

Jana : Leslie B. Lamport, lauréat du prix Turing, dit : ” Si vous voulez faire quelque chose, évidemment… nous sommes tous des machines à introspection et en tant qu’ingénieur ou développeur, si vous voulez résoudre un problème d’ingénierie logicielle, vous devez écrire.

“L’écriture est la façon dont la nature nous dit à quel point notre pensée est nulle. – Leslie Lamport

Si vous n’écrivez pas, c’est que vous ne pensez pas correctement.

Lorsque je parle d’écrire, je ne parle pas d’écrire du code.

Je parle d’écrire quelque chose avant de commencer à écrire du code.

Tout développeur, qu’il écrive une petite fonctionnalité ou qu’il conçoive un grand système complexe, doit compléter son processus de réflexion par des écrits.

L’idée n’est pas de faire ressembler votre cahier des charges à une élégante poésie. Il s’agit de s’assurer que vous n’êtes jamais sans ambiguïté sur ce que vous voulez que le système fasse et sur ce que vous voulez que le programme fasse.

Keerthi : Comment les responsables de l’ingénierie peuvent-ils réunir ces concepts de code propre pour mettre au point un produit irréprochable ?

Jana : Je ne pense pas que nous voulions maintenir une base de code propre et réduire la dette technique pour sortir un “produit impeccable”. Nous le faisons parce que nous voulons améliorer l'”agilité du code”.

Par agilité du code, j’entends : l’équipe a-t-elle la capacité de développer des fonctionnalités dans un laps de temps plus court ?

Serait-il possible de déployer des fonctionnalités granulaires en production tous les jours ou plusieurs fois par jour ?

En tant que responsable de l’ingénierie, vous devriez être en mesure de collecter et d’extraire le contexte de ces processus d’ingénierie, des validations de code ou de toute autre mesure en mettant en place un processus hautement sophistiqué ou en utilisant des plateformes telles que GitHub pour examiner et améliorer en permanence l’agilité du code.

Question pour vous :

Que pensez-vous des sujets abordés dans cette édition de Z to A Pulse ?

Faites-nous part de vos commentaires ou suggestions ci-dessous. Veuillez vous “abonner” pour recevoir les prochaines éditions mettant en lumière certains des sujets les plus passionnants dans le domaine de l’excellence en matière d’ingénierie.

Merci de votre lecture !

Lisez la suite si vous êtes intéressé :

1. HORUS: Un livre de règles d’ingénierie que Zuci suit pour rassembler des concepts de code propre.
2. Le mois de l’homme mythique: Essais sur le génie logiciel
3. Penser et écrire, avec Leslie Lamport