5 étapes pour coder pour le prochain développeur

La plupart d’entre nous ne pensons probablement pas au développeur qui maintiendra notre code. Jusqu’à récemment, je ne l’ai pas considéré non plus. Je n’ai jamais intentionnellement écrit du code obscur, mais je n’ai jamais laissé de miettes de pain.

Kent Beck sur les bons programmeurs :

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

Douglas Crockford sur les bons programmes informatiques :

Tout se résume à la communication et aux structures que vous utilisez pour faciliter cette communication. Le langage humain et les langages informatiques fonctionnent très différemment à bien des égards, mais en fin de compte, je juge un bon programme informatique par sa capacité à communiquer avec un humain qui lit ce programme. À ce niveau, ils ne sont pas si différents.

Découvrir le but et l’intention est difficile même dans le code le mieux écrit. Toute miette de pain laissée par l’auteur, les commentaires, les noms verbeux et la cohérence, sont immensément utiles aux développeurs suivants.

Je commence par chercher des motifs. Les motifs peuvent être trouvés dans de nombreux endroits, y compris les noms de variables, la disposition des classes et la structure du projet. Une fois identifiés, les motifs sont des aperçus de l’intention du développeur précédent et aident à comprendre le code.

Qu’est-ce qu’un motif ? Un motif est une solution répétable à un problème récurrent. Considérez une porte. Quand un espace doit permettre aux gens d’entrer et de sortir tout en maintenant l’isolation, le motif de la porte est implémenté. Cela semble évident maintenant, mais à un moment donné, ce ne l’était pas. Quelqu’un a créé le motif de la porte qui incluait la poignée de porte, les charnières et le placement de ces composants. Entrez dans n’importe quelle maison et vous pouvez identifier n’importe quelle porte et ses composants. Les styles et les couleurs peuvent être différents, mais les composants sont les mêmes. Le logiciel est pareil.

Il existe des motifs logiciels connus pour les problèmes logiciels courants. En 1995, Design Patterns: Elements of Reusable Object-Oriented Software a été publié décrivant les motifs logiciels courants. Ce livre décrit les problèmes courants rencontrés dans la plupart des applications logicielles et offrait un moyen élégant de résoudre ces problèmes. Les développeurs créent également leurs propres motifs en résolvant les problèmes qu’ils rencontrent régulièrement. Bien qu’ils ne publient pas de livre, si vous regardez de près, vous pouvez les identifier.

Parfois, il est difficile d’identifier les motifs. Cela rend la compréhension du code difficile. Quand vous vous trouvez dans cette situation, inspectez le code, voyez comment il est utilisé. Commencez une réécriture. Demandez-vous, comment accompliriez-vous le même résultat. Souvent, en parcourant le processus de réflexion d’un algorithme, vous gagnez une compréhension de l’implémentation de l’autre développeur. Beaucoup d’entre nous avons l’inclination de réécrire ce que nous ne comprenons pas. Résistez à cette envie ! L’implémentation existante a été testée au combat et la vôtre ne l’a pas.

Certains codes sont juste vexants, contactez un collègue — une deuxième paire d’yeux aide toujours. Parcourez le code ensemble. Vous serez surpris de ce que vous deux trouverez.

Voici 5 conseils pour laisser des miettes de pain aux développeurs suivants

1. Motifs
Utilisez des motifs connus, créez vos propres motifs. Restez fidèle à un paradigme cohérent dans tout le code. Par exemple, n’ayez pas 3 approches différentes pour l’accès aux données.

2. Cohérence
C’est de loin l’aspect le plus important du codage. Rien n’est plus frustrant que de trouver du code incohérent. La cohérence permet de faire des hypothèses. Chaque fois qu’un motif logiciel spécifique est rencontré, il devrait être supposé qu’il se comporte de la même manière que les autres instances du motif.

Le code incohérent est un cauchemar, imaginez lire un livre où chaque mot signifie quelque chose de différent, y compris le même mot à différents endroits. Vous devriez chercher chaque mot et dépenser de grandes quantités d’énergie mentale pour découvrir l’intention. C’est frustrant, fastidieux et douloureux. Vous deviendrez fou ! Ne faites pas cela au prochain développeur.

3. Nommage verbeux
C’est votre langage. Ce sont les mots de votre histoire. Tissez-les bien.

Cela inclut les noms de classes, les noms de méthodes, les noms de variables, les noms de projets et les noms de propriétés.

À ne pas faire :

if(monkey.HoursSinceLastMeal > 3)
{
    FeedMonkey();
}

À faire :

int feedInterval = 3;

if(monkey.HoursSinceLastMeal > feedInterval)
{
    FeedMonkey();
}

Le premier exemple a 3 codé en dur dans l’instruction if. Ce code est syntaxiquement correct, mais l’intention du nombre 3 ne vous dit rien. En regardant la propriété évaluée, vous pouvez déduire que c’est vraiment 3 heures. En réalité, nous ne savons pas. Nous faisons une hypothèse.

Dans le deuxième exemple, nous définissons 3 à une variable appelée ‘feedInterval’. L’intention est clairement indiquée dans le nom de la variable. S’il s’est écoulé 3 heures depuis le dernier repas, il est temps de nourrir le singe. Un effet secondaire de la définition de la variable est que nous pouvons maintenant modifier l’intervalle d’alimentation sans modifier la logique.

C’est un exemple artificiel, dans un grand logiciel, ce type de code s’auto-documente et aidera le prochain développeur à comprendre le code.

4. Commentaires
Les commentaires sont une arme à double tranchant. Trop de commentaires augmente les coûts de maintenance, pas assez laisse les développeurs incertains sur le fonctionnement du code. Une règle générale est de commenter quand le développeur moyen ne comprendra pas le code. Cela se produit quand les hypothèses ne sont pas évidentes ou que le code est hors de l’ordinaire.

5. Coder simplement
À mon avis professionnel, écrire du code complexe est la plus grande folie parmi les développeurs.

Steve Jobs sur la simplicité :

Simple peut être plus difficile que complexe : vous devez travailler dur pour clarifier votre réflexion pour la rendre simple. Mais cela en vaut la peine à la fin car une fois que vous y arrivez, vous pouvez soulever des montagnes.

La complexité se présente sous de nombreuses formes, dont certaines incluent : la prévention de l’avenir, les implémentations excessivement complexes, trop d’abstraction, les grandes classes et les grandes méthodes.

Pour plus d’informations sur l’écriture de code simple et propre, consultez le livre Clean Code d’Uncle Bob et Code Simplicity de Max Kanat-Alexander

Conclusion

Lire du code est difficile. Avec quelques étapes simples, vous pouvez vous assurer que le prochain développeur comprendra votre code.