Cet article est le premier, j’espère, d’une longue série qui traitera des mauvaises pratiques de développement logiciel. Les exemples que je donnerai sont issue de mes expériences professionnelles, sur des projets auxquels j’ai participé.

J’ai eu l’idée de cette série en lisant l’article Les pire bout de code du site jesuisundev.com. J’aimerai donner quelques exemples de mon expérience en tant que développeur Web.

Avec cette série d’article, je veux juste montrer des exemples de mauvaises pratiques, comment les corriger et comment les éviter.
Je ne veux en aucun cas juger les personnes (développeurs, managers, …), ou les choix qui ont mené à ces mauvaises pratiques.

Mauvaise pratique du jour

Dans l’article d’aujourd’hui, j’aimerai parler de ces fichiers que l’on qualifie de fourre-tout. On en trouve dans beaucoup de projets (Web, Logiciel, etc…).

Un fichier fourre-tout est, par définition, un fichier dans lequel on met toutes les scripts (ou fonctions) que l’on n’arrive pas mettre « Autre part » dans le projet. (Oui, oui, vous avez bien vu « autre part » avec des guillemets).

Ce genre de fichiers a tendance a grossir au fur et à mesure du développement du projet donc il est issu.
Les développeurs travaillant dessus, n’ont généralement pas le temps ou l’envie de corriger ce genre de chose.

L’existence de plusieurs fichiers de ce genre dans un même projet est plus rare, mais c’est toujours possible.

L’exemple du jour

Mon exemple du fourre-tout faisait partie d’un site Intranet d’une PME.
Il était basé sur CodeIgniter 2, un framework PHP assez bien pensé.

Ce qu’il faut savoir sur CodeIgniter, c’est qu’il est possible de paramétrer le projet dès la base du développement.
Dans ces paramétrages, il y a le chargements des helpers dans un fichier qui s’appelle autoload.php.
Un helper est, par définition, un fichier PHP qui contient simplement une collection de fonctions dans une catégorie particulière.

Voici une liste d’exemple :

• URL Helpers, pour aider à créer des liens
• Form Helpers pour créer des éléments de formulaire
• Text Helpers, pour exécuter diverses routines de mise en forme de texte
• Cookies Helpers, pour définir et lire des cookies
• File Helpers pour gérer des fichiers
• …

Voici la ligne de code qui charge tous les helpers :

$autoload['helper'] = array('array', 'assets', 'date', 'debug', 'file', 'form', 'googlemaps', 'pagination', 'text', 'security', 'string', 'translate', 'twig', 'upload', 'url');

Dans ce projet d’intranet, le précédent développeur n’avait pas du comprendre complètement ce concept de helper. Il n’avait créé qu’un seul fichier dans lequel il avait mis toutes ses fonctions, de toutes les catégories.

Ce fichier faisait plusieurs milliers de lignes de code.

Mon correctif

Voici la liste de mes correctifs, qui m’a pris a peine 1/2 journée.

Dans ce fichier de plusieurs milliers de lignes de code, un bon tiers était commenté. Je me suis permis de les supprimer, parce que le projet était versionné sous Git.

Dans ce qui restait, j’ai pu diviser les fonctions en plusieurs fichiers (entre 7 et 10). Ce qui faisait, en toute logique, autant de catégories différentes de fonctions.

Cela m’a permis aussi d’enlever beaucoup de code mort, faute d’être appelé par une autre partie du programme.
J’ai même supprimé quelques fonctions inutiles, du genre :

<?php
function e($str) {
    return function_quelconque($str);
}

function_quelconque($str) {
    return htmlentities($str);
}
?>

Tout ce qui restait, étaient donc les fonctions utiles et indispensable.
J’ai même poussé le vice à écrire la documentation de chaque fonctions, pour leur bonne compréhension.

Ce genre d’erreur est facilement évitable. Il suffit d’avoir un minimum de compréhension du projet, et de la technologie utilisée.