Les Framework d'entreprise, c'est un peu comme les boites de chocolats : on ne sait jamais sur quoi on va tomber. Contrairement à la boite de chocolats qui peut vous rendre malade pendant un ou deux jours, l'indigestion de Framework d'entreprise peut vous gâcher la vie pendant bien plus longtemps. Personnellement je considère que lorsque de tels Framework sont bien ficelés et gérés par un service technique efficace, capitaliser sur l'expérience et les bonnes idées des développeurs est une excellente chose.
Nous partageons donc aujourd'hui la souffrance d'un développeur qui souhaite rester anonyme (et on le comprend). Travaillant dans une grande SSII française, il a le plaisir de développer avec un Framework PHP fait maison des projets pour des grands groupes français. Pour présenter le Framework, il nous propose des exemples de méthodes dans les divers modules du Framework : la couche présentation, l'accès aux données, la partie utilitaire, sans oublier bien sûr la sécurité.
Pour la partie accès aux données, le développeur peut s'appuyer sur une couche d'abstraction performante. Plus besoins de réviser son SQL ou de copier coller de longues fonctions pour charger manuellement le contenu d'un objet. Non, vraiment, le Framework s'occupe de tout :
/**
* @return string
* @param string $table Nom de la table
* @desc permet de recuperer l'id du de la prochaine séquence associée à la table
*/
function getNextId($table)
{
return true;
}
La partie présentation est très puissante elle aussi, elle simplifie grandement l'écriture des pages web (dont je vous laisse imaginer la tête) :
/**
* @return string
* @desc permet d'afficher le bas du tableau servant à afficher les informations (erreur, résultat d'une requête...).
*/
function getFooter()
{
return "</TABLE><br />";
}
Comme tout Framework qui se respecte, on a évidemment des classes utilitaires qui effectuent des tâches aussi utiles que complexes ...
function variable($valeur) {
return "\$".$valeur;
}
Enfin, la couche sécurité. Parce que pour les clients utilisant le Framework, rien n'est trop sécurisé, on a des fonctions de vérifications très poussées. La preuve? Et bien cette merveilleuse parade contre les injections SQL :
/**
* @return string
* @param string $value Chaîne de caractère
* @desc Nettoyage des cotes pour les requêtes SQL
*/
function stringToSql($value) {
return $value;
}
Notre contributeur anonyme ajoute :
Il était très fréquent de voir des décalages entre la documentation, l'utilisation et le code source des méthodes du Framework. Par exemple, je voulais utiliser la méthode getValuesFromCache qui selon la doc acceptait 3 arguments, avant de me rendre compte qu'elle était utilisée ailleurs avec 5 arguments ... tout en étant déclarée avec seulement 4 !
Au bout d'un moment plus personne n'utilisait la documentation, de toute façon rendue inutile puisqu'il n'y a pas un Framework spécifique, mais autant de Frameworks que de versions d'installés. En effet, aussi incroyable que cela puisse paraître, ce machin n'est pas versionné. Impossible de trouver un dépôt centralisant les dernières mises à jour. Dans ces conditions, l'installation du Framework pour un nouveau projet est tout bonnement hallucinante:
- Récupérer les sources d'un autre projet client existant, avec un dump de la base de données.
- "Nettoyer" le code des développements spécifiques à l'ancien projet
- "Nettoyer" la base de données des données de l'ancien projet, en prenant soin de ne pas trop en enlever sinon ça ne marche plus...
Les étapes 2 et 3 peuvent facilement s'étaler sur toute la durée du nouveau projet, je vous laisse imaginer le calvaire pour le développeur.
Je me souviens d'une formation au Framework dispensée par un ancien développeur... après trois jours il en est venu à faire quelques confidences : "ça fait quatre ans que je travaille sur cet outil, mais je ne comprends pas encore tout, loin de là..."
Contrairement au formateur, notre ami semble lui avoir tout compris : il ouvre grand ses ailes pour s'envoler vers de plus verts paturages ...