Je vais commencer doucement, avec certainement le code le plus (in) utile que j’ai pu voir jusqu’à maintenant :

if (0) {
/* beaucoup de code très compliqué */
}

J’ai une affection très particulière avec l’extrait suivant, que je trouve très mignon :

try { return true; }
catch (exception $ exception) {
/* beaucoup de code très compliqué */
}

Je poursuivrais avec un grand classique qu’il est possible de retrouver dans quasi tous les langages supportant cette structure :

switch ($ value) {
   case/*… */:
      break ;

   default:
      /*… */
      break; // extrémement utile voir indispensable…
}

Il arrive également que je tombe sur des choses de ce genre :

sprintf("'%s'", (string) $element);

Et dernièrement, j'ai lu ceci :

function handle ($ foo = null) {if ($foo === null) return parent::handle() else return parent::handle($foo);}

Bref, je trouve des perles, la liste est encore longue, et il serait possible d’en rire pendant très longtemps (et j’avoue que je ne m’en prive pas), sauf qu’au final ça n’apporte pas grand-chose.

En effet, à un moment ou un autre, indépendamment du langage et des outils que nous utilisons, nous faisons tous plus ou moins de la merde.

Elle colle plus ou moins à la cuvette et sent plus ou moins fort en fonction de nos compétences et de notre expérience (et ce n’est pas forcément celle du plus inexpérimenté qui est la plus nauséabonde), mais ça reste de la merde.

Et si nous sommes souvent totalement responsables du merdier que nous laissons derrière nous, parfois, ce n’est pas le cas.

Parfois, cette merde peut être le résultat de l’infection de votre commercial ou de votre supérieur par des agents pathogènes extérieurs encore plus puissants que ceux de la gastro-entérite et qui les poussent à vous imposer des délais impossibles à tenir et vous oblige donc à rogner sur la qualité en faisant les choses à l’arrache.

Parfois, le code dont vous avez la charge a des années d’existence et il est le fruit du travail de plusieurs développeurs qui ont laissé leur quota de merde dans le code.

Et vous êtes obligé de l’accepter, car vous ne voulez pas ou vous ne pouvez pas tirer la chasse.

Alors, que faire pour éviter cela ?

Je n’ai pas LA réponse à cette question, car il faudra de toute façon que la chasse soit tirée un jour ou l’autre, mais je peux par contre vous dire qu’il vaut mieux le faire le plus rapidement possible.

Car plus vous attendez pour le faire, plus la merde s’incruste dans la cuvette et plus elle sera difficile à enlever.

Le nettoyage vous prendra donc de plus en plus de temps et vous coûtera donc de plus en plus cher.

Et dans le pire des cas, à un moment, la merde submergera l’intégralité de votre code et compromettra très sérieusement son bon fonctionnement et sa maintenance.

Le plus raisonnable est donc de nettoyer la merde au plus tôt, ou, pour utiliser un vocabulaire un peu moins fleuri, de réduire la dette technique de votre code le plus rapidement possible.

Et pour cela, je vous recommande deux chose : effectuez des revues de code régulières et écrivez des tests unitaires ou fonctionnels exécutables par la machine (et souvenez-vous que les tests fonctionnels sont complémentaires des tests unitaires, et non exclusifs).

Les revues de code vous permettront en effet de détecter au plus tôt les problèmes dans votre code et donc de les corriger pour un coût minime vu qu’ils n’auront pas encore eu de conséquences.

Les tests vous permettront quant à eux de vérifier facilement que les corrections effectuées sur le code à la suite d’une revues de code n’ont pas altéré significativement son fonctionnement.

En effet, si grâce à eux vous ne pourrez peut-être pas détecter tous les problèmes, vous pourrez cependant être certain que le code corrigé se comporte toujours de la même façon dans le cadre des tests (et uniquement dans ce cadre et avoir de tels tests ne vous dispensent donc pas d’effectuer des tests manuels).

De plus, comme ils sont exécutés par la machine, ils sont réalisés exhaustivement et surtout bien plus efficacement que s’ils étaient effectués par l’Humain, ce qui permet de valider le fonctionnement du code également à moindre coût.

Alors, si vous souhaitez suivre mes conseils, je vous recommande l’'excellente conférence de Jean-Marc Fontaine concernant les revues de code, ainsi que Crew qui vous simplifiera le processus si vous utilisez Git pour gérer votre dépôt de codet.

Et en ce qui concerne la mise en œuvre de tests unitaires ou fonctionnels, je vous recommande de vous intéressez à des outils tels qu’atoum, PHPUnit ou Behat ainsi qu’à des outils d’intégration continue tels que Jenkins ou Travis.