Comment écrire un « bon code patrimonial »
Voici quelques points de départ rapides pour écrire un bon code patrimonial. Le code est beaucoup plus facile à écrire qu’à lire, et la meilleure façon de résoudre les problèmes est de ne pas les créer.
Écrire moins de code
Moins de code = moins de potentiel pour les bogues = moins à maintenir = moins de « mauvais héritage ».
Écrire moins de code pourrait être considéré comme la façon la plus importante d’améliorer le code en général. Le principe DRY peut être considéré comme un corollaire naturel et un moyen primaire d’écrire moins et d’obtenir plus.
Éviter // TODO et // FIXME
Écrire // TODO ou // FIXME devrait être considéré comme un drapeau rouge et une odeur de code.
Si nous traduisons ces commentaires dans leurs significations réelles, alors « TODO » se traduit par « créer une dette technique » et « FIXME » se traduit par « j’écris intentionnellement un bug ».
Il peut y avoir de rares exceptions où le report d’une solution l’emporte sur les avantages de la résoudre maintenant, mais en général, TODO et FIXME devraient être maintenus au minimum.
Préférer les idiomes établis à l’avant-garde
Cela peut sembler contradictoire… utiliser des technologies de pointe saignantes rend le code plus « nouveau », non ? Eh bien, oui, mais cela crée aussi le potentiel de devenir obsolète plus rapidement.
Il donne également aux nouveaux programmeurs un temps plus difficile à comprendre les choses. Si le code est écrit en utilisant des idiomes et des cadres établis, il est probablement plus facile à lire et a une meilleure chance de fonctionner plus longtemps dans le futur.
Toujours laisser le code dans un meilleur état que vous l’avez trouvé
Cela peut sembler contredire le « pas de réécriture » mentionné au début, cependant, l’amélioration continue et le refactoring sont différents de faire une réécriture significative.
Essayer de prendre l’habitude d’améliorer les choses progressivement et de manière incrémentale. Parfois, un gros remaniement ou une réécriture est véritablement nécessaire, mais la valeur commerciale de cela doit être soigneusement pesée par rapport à d’autres priorités.
Continuez à vous améliorer en tant que programmeur
Lisez des livres, lisez des articles de blog, lisez le code des autres, réfléchissez soigneusement aux pratiques de conception et de programmation. Réfléchissez consciemment à votre code et pensez aux moyens de l’améliorer.
Plutôt que de blâmer le programmeur précédent pour avoir laissé un mauvais héritage, assurez-vous de ne pas devenir le programmeur qui en crée un nouveau.