Retour vers le futur… Nous sommes en Décembre, un client me passe un coup de téléphone, il y a un bug sur un des sites que nous lui avons développé. Le site en question existe depuis 3 ans, il n’y a eu aucune amélioration, le client est autonome dans la gestion de son site. Donc pas de raison particulière de mettre les mains dans le code de temps en temps à autre.

Je récupère des informations sur le bug en question et je me plonge dans le code.

Et là… C’est le drame :

  • Le code n’est presque pas commenté
  • Le développeur qui s’est chargé de la majorité du projet ne fait plus partie de l’équipe
  • Les conventions de code mises en place récemment n’ont rien à voir avec le code de ce projet

Résultat : je vais passer plus de 3h à résoudre ce bug, m’arrachant les cheveux pour comprendre le rôle de certaines variables et fonctions, recodant de 0 certaines étapes de logique étant incapable de trouver correctement l’origine du problème.


Autre situation semblable…

Un stagiaire nous rejoint pour la période estivale, il développe un projet ou commence le développement d’un projet. Le stagiaire est bien suivi au début de son stage, puis de moins en moins, selon qu’on ressent qu’il maitrise les technologies et les conventions définies en interne.

Fin Août, le stagiaire s’en va, le projet n’est pas fini à 100%, disons 80%. Le temps passe un peu, certains dossiers prioritaires nécessitent notre attention. Nous remettons les mains dans le projet développé par le stagiaire début Octobre.

Et là… C’est le drame :

  • Bien que des efforts aient été faits par le stagiaire pour coder proprement au début du stage, la qualité du code s’est déterioré au fil du stage.
  • Le projet est fonctionnel, mais des fonctionnalités clés sont encore manquantes et les fondations du projet sont en réalité bancales

Résultat : un projet qu’on croyait quasiment fini va nécessiter beaucoup plus de temps que prévu pour être fonctionnel. Un temps important devra être consacré pour s’assurer que le projet pourra être maintenu efficacement dans le temps.


J’ai encore 2 ou 3 autres exemples de ce genre dans mon expérience. Avec le temps, nous avons réussi à les corriger, en mettant en place notamment des conventions de code partagées entre tous les développeurs, et en suivant régulièrement le code produit par tous.

Voici donc le message que je fais passer à mes équipes régulièrement :

Arrêter de coder pour soi ! Il faut coder pour son collègue, et pour le soi du futur…

Et il faut donc se poser les bonnes questions :

  • Est ce que mon code est suffisamment clair pour être repris par un de mes collègues ?
  • Est ce que je sais que mon code est tellement complexe, que si un problème survient en mon absence (congés par exemple), il faudra forcément que j’intervienne ?
  • Est ce que je respecte les conventions de code définis pour l’équipe ?
  • Est ce que je ne code pas d’une façon que je suis le seul à « maitriser » ou « comprendre » ?
  • Si je reviens sur ce code dans 1 mois ? 6 mois ? 3 ans ? Vais-je comprendre mon code rapidement ?

Si vous répondez oui à une seule de ces questions, c’est que votre façon de coder doit être améliorée.


Premiers conseils :

Définissez un ensemble de conventions et de bonnes pratiques. En PHP, on retrouve par exemple les PSR, ou des ressources comme PHP the Right Way, qui sont de très bonnes bases pour définir des bonnes pratiques et des conventions de code. Définissez par exemple clairement comment doivent être nommées les variables, les fonctions, les objets. Listez les pratiques qui permettent d’avoir un code clair et lisible d’un développeur à un autre.

De la même manière, vous utilisez sans doute un framework dans vos développements. Les frameworks proposent déjà leurs propres conventions. Il est donc très important de les respecter mais vous pouvez aussi définir et consigner des bonnes pratiques liées à ces outils. Par exemple, au quotidien, nous utilisons le framework PHP CakePHP. Nous avons défini en interne un façon particulière de nommer les variables qui sont transmises des controllers vers les vues. C’est très basique comme exemple, mais de cette manière, toute l’équipe applique le même process.

Mettez ces bonnes pratiques au propre, dans un document partageable, voir sur un support papier remis à chaque collaborateur.

Commentez votre code. Commentez votre code. Commentez votre code. Utilisez les commentaires pour présenter la réflexion qui a mené au code. Evitez le fameux « je code, je ferais les commentaires après ». Inversez cet ordre. Commencez par commenter. Au lieu de réfléchir dans votre tête, posez la réflexion par écrit, par les commentaires, puis codez tout autour de ces commentaires.

Les commentaires peuvent également servir pour séparer des blocs logiques de code. Je conseille vraiment de ne pas hésiter à en « abuser ». Les développeurs ont trop tendance à être avares en commentaires.

Organisez des revues de code. Pas toujours facile à organiser selon les priorités du quotidien mais ce sont des exercices très intéressants, durant lesquels les développeurs échangent sur leur façon de coder, leurs astuces, des librairies découvertes, de nouvelles bonnes pratiques à mettre en place, etc.

C’est également un temps privilégié durant lesquels certains développeurs vont pouvoir exprimer des problématiques qu’ils rencontrent et ou des idées qu’ils ont pour optimiser les process internes. Alors qu’ils n’auraient parfois pas oser ou pas juger judicieux ou opportun de s’exprimer sur ces sujets dans le quotidien de leurs missions.


Autres pistes :

Deux autres pistes que je pourrais mettre au rayon des pistes « controversées », qui, je le sais d’avance, ne feront pas l’unanimité parmi les développeurs :

Codez en français ! La norme voudrait qu’on code en anglais. Les mots clés dans les langages sont d’ailleurs en anglais : « new », « function », « array », etc. Pour autant, je considère que la programmation demande déjà tellement de ressources intellectuelles que je ne vois pas vraiment l’intérêt de rajouter une couche de complexité en s’éloignant de sa langue maternelle. Alors forcément, ce conseil vaut pour une équipe de développeurs 100% francophones. Dès lors que vous collaborez entre différentes langues, l’anglais doit redevenir la langue utilisée. Parfois, je vois par exemple du code où les fonctions et les variables sont en anglais (« parce qu’on doit coder en anglais ») mais les commentaires sont en français. Du coup on peut s’y perdre facilement ou du moins réaliser un effort intellectuel supplémentaire et inutile pour bien faire le lien entre les différents éléments du code.

Laissez de côté les performances de votre code ! « Par convention, ici, je ne dois pas créer de variables supplémentaires », mais au fond, vous voudriez bien en créer une de plus, pour que votre code soit plus clair. Alors faites le ! Les performances sont une problématique précise de la programmation, qui doit être prise en compte au bon moment. Vous n’avez (à peu près) aucune idée de la performance de votre script tant que celui-ci n’est pas sur le serveur de production, avec des données réelles, et un cas d’usage réel. Donc n’essayez pas de tout optimiser du premier coup. Commencez par créer un code clair et lisible, puis mesurez vos performances. Revenez alors sur votre code si nécessaire, améliorez le, etc. Ce conseil vaut surtout pour les développeurs débutants. Avec l’expérience, vous serez en mesure d’écrire plus rapidement un code optimisé. Mais faites bien attention à ne pas perdre la lisibilité et la compréhension de celui-ci. Il existe aujourd’hui beaucoup d’outils qui permettent d’améliorer les performances dans une phase « post-code » : compression, compilation, mise en cache, optimisation de ressources, etc.


Conclusion

Gardez à l’esprit que le code est un travail d’amélioration continu. Rares sont les développeurs qui codent tout de manière parfaitement optimisée et claire du premier coup. Mais tous les bons développeurs sont capables de prendre du recul sur un code rédigé pour s’assurer que celui-ci est le plus clair, lisible et optimisé possible. Alors soyez un bon développeur 😉


Pour aller plus loin, découvrez ma liste de bonnes pratiques PHP.