7 habitudes simples des ingénieurs du top 1 %

• « Comment les codeurs d’élite parviennent à être meilleurs que les autres »

Être un ingénieur, pas un codeur (Be an engineer, not a coder)

• L’ingénierie consiste à résoudre des problèmes
• Les meilleurs ingénieurs considèrent le code comme un moyen d’atteindre un objectif
• Écrire du code est plaisant, mais écrire du code sans objectif n’a pas de sens. Le code sert plutôt à concevoir des solutions pour les utilisateurs
• Le code recherche la créativité ! La créativité naît souvent des contraintes. En ajoutant la « contrainte » d’un problème clair à résoudre, l’ingénieur gagne la liberté d’explorer et de construire une solution de la manière qu’il juge la plus adaptée
• Les meilleurs ingénieurs sont centrés sur le produit et, avant tout, sur la résolution de problèmes pour des personnes, ce qui mène naturellement au point suivant

Écrire du code pour les humains, pas pour l’ordinateur (Code for the human, not the computer)

« N’importe quel imbécile peut écrire du code qu’un ordinateur comprend. Les bons programmeurs écrivent du code que les humains peuvent comprendre. » — Martin Fowler

• Le code n’est pas seulement destiné à l’ordinateur, mais aussi aux humains
• Le code est destiné aux ingénieurs de la même équipe qui le liront, le maintiendront et construiront par-dessus
• Le code est destiné aux utilisateurs, qu’il s’agisse d’un jeune enfant utilisant un téléphone, d’un développeur appelant une API, ou de vous-même
• Les meilleurs ingénieurs ont toujours évalué la valeur du code pour l’ensemble de ses utilisateurs
• Si le code ne satisfaisait ne serait-ce qu’un seul de ses publics, il n’allait pas en production

Se détacher du code lui-même (Detach from the code itself)

• Les excellents ingénieurs ne s’attachent pas au code en tant que tel
• Ils n’ont pas peur de supprimer un code terminé à 90 % et de recommencer si le résultat final peut être globalement meilleur
• Ils accueillent activement les retours, parce que le code n’est pas quelque chose de personnel
• Le code n’est pas parfait. Personne ne s’intéresse à un code parfait. Ce qui compte, c’est un code qui produit un impact
• La meilleure manière d’apprendre à ne pas s’attacher à son code est de « réaliser que dans 20 ans, la majeure partie de votre code sera probablement devenue de la dette technique, ne sera plus utilisée ou aura été réécrite »

Utiliser des standards cohérents (Use consistent standards)

• Lors de l’écriture du code, respecter des standards cohérents et un style de code uniforme
• Maintenir cette cohérence permet à votre futur vous-même comme à vos coéquipiers de lire et comprendre plus facilement le code
• Utiliser un guide de style cohérent facilite aussi la montée en charge de l’équipe comme de la codebase
  • C’est ainsi que des entreprises comme Meta ou Google déploient rapidement d’importants volumes de code sans se retrouver, avec le temps, incapables de lire ou de maintenir leur codebase
• Toutes les entreprises très performantes ont intériorisé les guides de style, en connaissent les bénéfices et les appliquent autant que possible
  • Google a open source une partie de ses guides de style
  • Meta dispose d’un guide de style C++ dans certaines de ses publications open source
• Astuce : configurer un linter pour le formatage au service de votre équipe vaut clairement le temps investi

Écrire un code simple (Write simple code)

• Tous les ingénieurs d’élite que je connais ont peut-être produit un code complexe à concevoir, mais au final facile à lire et à comprendre
• La meilleure manière que j’ai trouvée pour le dire est que leur code était « esthétiquement satisfaisant »
• Leur code est propre, structuré et logique (clean, organized, and logical)
• Chaque décision prise dans le code avait du sens, et quand ce n’était pas le cas, elle était bien documentée dans le code
• Une bonne manière d’écrire un code propre est de suivre des principes comme SOLID. Ils ont d’abord été conçus en pensant à l’OOP (programmation orientée objet), mais peuvent s’étendre à la programmation en général
  • Single Responsibility : une classe ne doit avoir qu’une seule responsabilité
  • Open-Closed : les objets logiciels (classes, modules, etc.) doivent être ouverts à l’extension mais fermés à la modification afin de produire un code prévisible et maintenable
  • Liskov Substitution : les sous-types doivent pouvoir remplacer le type de base sans affecter la justesse du programme
  • Interface Segregation : le code ne doit pas dépendre d’interfaces gigantesques dont il n’utilise pas tout. À la place, il faut permettre aux packages d’inclure et d’importer des interfaces plus petites et spécifiques
  • Dependency Inversion : les modules de haut niveau ne doivent pas dépendre des modules de bas niveau ; les deux doivent dépendre d’abstractions afin de favoriser une conception plus flexible et découplée du système
• On peut prendre comme exemple le naming : de bons noms n’ont rien de magique, mais permettent de distinguer clairement les choses, avec des noms de fonctions explicites et des variables faciles à comprendre

Ne pas laisser place aux surprises (Don’t allow surprises)

• Le code ne doit pas produire de résultats inattendus. Cela est possible en suivant des principes de code et en écrivant des tests adaptés
• Un bon code est prévisible
• Les tests renforcent la clarté et la prévisibilité du code, et donnent confiance. Grâce à d’excellents tests automatisés, une équipe peut modifier le code sans craindre de casser des éléments invisibles
• Quelques types de tests
  • Tests unitaires pour des composants individuels et des fonctions isolées
  • Tests d’intégration pour les interactions entre plusieurs composants
  • Tests end-to-end pour évaluer le fonctionnement du système complet du point de vue de l’utilisateur
• Les tests doivent être simples. En lisant un test qui a échoué, on doit pouvoir comprendre facilement ce qui n’a pas fonctionné
• Il est aussi important de savoir ce qu’il ne faut pas tester
  • Par exemple, si l’effort requis pour des tests end-to-end dépasse les bénéfices réels pour le programme, les tests peuvent être remplacés par une documentation soignée, du monitoring et des alertes envoyées aux bonnes personnes (par exemple le propriétaire du code)
  • De même, les tests ne doivent pas vérifier des détails d’implémentation dans le code, comme tester des sélecteurs CSS spécifiques dans du code frontend, ou ne s’appuyer que sur des attributs de données ou sur des tests par capture d’écran

Communiquer souvent (Communicate often)

• Les grands systèmes ne se construisent pas seul. Les grands ingénieurs passent par des revues de conception, demandent du feedback et itèrent continuellement sur les conceptions initiales de leur code
• Chacun a des zones d’ombre dans ses connaissances que d’autres peuvent combler. Un point de vue nouveau aide souvent à rendre le code plus clair ou à proposer une nouvelle approche à laquelle on n’avait pas pensé auparavant
• Les meilleurs ingénieurs n’ont pas peur de prendre le temps de travailler ensemble pour obtenir un meilleur résultat final, et accordent une grande importance à la communication et à la collaboration
• Cela peut être aussi simple qu’envoyer un ping à un coéquipier pour une relecture rapide d’un document, ou ajouter des reviewers à une pull request importante

Coder vite… et lentement (Code fast… and slow)

• Les meilleurs ingénieurs que je connais terminent les projets rapidement, mais codent lentement
• Cela semble étrange, non ?
  • Tous les principes et habitudes ci-dessus ajoutent davantage de temps à la première phase de codage. Mais grâce à eux, l’ingénieur peut faire progresser un projet étape par étape
  • Prendre le temps d’utiliser des standards, de tester correctement, d’appliquer des principes et de communiquer souvent permet, à long terme, de gagner beaucoup plus de temps
• Je l’ai vécu moi-même à l’époque où j’étais stagiaire puis ingénieur junior, et beaucoup d’autres ingénieurs aussi : se précipiter pour avancer de trois pas peut vous faire heurter un obstacle et reculer de cinq

Ne pas suivre les règles aveuglément (Don’t follow rules blindly)

• Les « règles » et « principes » ci-dessus ne sont que des lignes directrices. Tout ne rentre pas parfaitement dans un cadre bien propre
• Parfois, le code que vous écrivez est un carré qui n’entre pas dans un cercle, et ce n’est pas grave
  • Dans ce cas, documentez pourquoi le code a été écrit de cette manière
  • Sinon, quelqu’un comme votre futur vous regardera ce code plus tard et se dira : « Waouh, j’étais idiot à l’époque. Pourquoi cela ne respecte-t-il pas nos standards ? »
  • Cette personne passera alors 20 heures à recoder selon les standards pour arriver à la même conclusion qu’avant
• La réalité du développement logiciel, c’est que tout le code ne peut pas être propre ni suivre parfaitement les règles
• Mais il est possible d’avoir un code cohérent, propre, facile à comprendre, testable et utile
• D’autres schémas que j’ai observés chez les meilleurs ingénieurs
  • Avoir une connaissance métier profonde dans au moins un domaine. Tous les ingénieurs que j’ai suivis sont devenus experts en se concentrant sur un domaine précis — infrastructure frontend, systèmes distribués, UI soignée, etc. — ce qui les a amenés à figurer aujourd’hui parmi les meilleurs dans leur spécialité
  • Savoir se mettre en valeur régulièrement et de manière appropriée. Ces ingénieurs ne se cachaient pas dans des zones peu visibles. Toutes les personnes avec lesquelles ils travaillaient connaissaient leur valeur et leur expertise, grâce à une communication appropriée et à leur participation à des projets à fort impact

[greety]

J’y ai trouvé de très bonnes idées. Merci :)

[geekbini]

C'est un bon article !

[nina514]

La technique est importante, bien sûr, mais cela me rappelle une fois de plus que le plus important est de créer des produits qui apportent réellement quelque chose aux gens !!!

[functor]

Merci pour ce très bon article !

[functor]

En fait, il y a bien 7 habitudes, mais le contenu en liste 9, haha.

[xguru]

J’ai compté moi aussi… mais j’ai l’impression que le tout dernier et le tout premier sont juste le titre ! haha

[saalome]

Waouh, un super texte auquel on adhère presque entièrement haha

[saalome]

L’un des contenus les plus marquants que j’aie vus jusqu’à présent dans ce genre d’articles.

[rsm0503]

C’est un bon texte qui, avec un peu de généralisation, peut être utile à tout le monde.

[kuroneko]

À ce stade, ce n’est plus vraiment un résumé, on dirait plutôt une traduction… Merci beaucoup pour ce résumé.
C’est un article qui vaut la peine d’être relu de temps en temps.

[piriri11]

C’est tellement vrai lol, moi aussi je vais le relire encore et encore.