5 Étapes pour Coder pour le Prochain Développeur

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

Kent Beck sur les bons programmeurs :

N’importe quel idiot 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 finalement 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 trace laissée par l’auteur, commentaires, nommage verbeux et cohérence, est immensément utile aux prochains développeurs.

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’isolement, le motif de la porte est implémenté. Maintenant cela semble évident, 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 c’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 une façon élégante de résoudre ces problèmes. Les développeurs créent aussi leurs propres motifs en résolvant des problèmes qu’ils rencontrent régulièrement. Bien qu’ils ne publient pas de livre, si vous regardez d’assez 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 pensée d’un algorithme, vous obtenez un aperçu de l’implémentation de l’autre développeur. Beaucoup d’entre nous ont l’inclination à 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’est pas.

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

Voici 5 conseils pour laisser des traces aux prochains développeurs

1. Motifs
Utilisez des motifs connus, créez vos propres motifs. Respectez un paradigme cohérent dans tout le code. Par exemple, n’ayez pas 3 approches 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 les suppositions. Chaque fois qu’un motif logiciel spécifique est rencontré, il devrait être supposé qu’il se comporte de manière similaire aux autres instances du motif.

Le code incohérent est un cauchemar, imaginez lire un livre avec chaque mot signifiant 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é contre laquelle il est évalué, vous pouvez supposer que c’est vraiment 3 heures. En réalité nous ne savons pas. Nous faisons une supposition.

Dans le second exemple, nous définissons 3 à une variable appelée ‘feedInterval’. L’intention est clairement énoncé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 définir la variable est que nous pouvons maintenant changer l’intervalle d’alimentation sans changer la logique.

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

4. Commentaires
Les commentaires sont une épée à 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 arrive quand les suppositions ne sont pas évidentes ou que le code sort de l’ordinaire.

5. Coder Simple
Dans mon opinion professionnelle, é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 pensée pour la rendre simple. Mais cela en vaut la peine à la fin parce qu’une fois que vous y arrivez, vous pouvez déplacer des montagnes.

La complexité vient sous de nombreuses formes, dont certaines incluent : la protection contre l’obsolescence, les implémentations trop complexes, trop d’abstraction, les grandes classes et les grandes méthodes.

Pour plus d’informations sur l’écriture de code simple et propre, voir le livre d’Uncle Bob Clean Code 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.