Industrialisation PHP

Un projet sans développeur ?

Bien sûr, difficile d'imaginer un projet informatique sans développeur. Même bien conçu et bien supporté, il est difficile de se passer de celui qui produit le code, et convertit les objectifs fonctionnels en instructions PHP. Le titre de ce billet est provocateur. Il ne s'agit pas de s'en passer  totalement : même les générateurs de code doivent être programmés par quelqu'un....

Pourtant, il y a un bon nombre de tâches qui échoient, faute d'autre interlocuteur, aux développeurs. Par exemple quand il faut déployer (qui connait l'application?), quand il faut tester (idem), quand il faut suivre la qualité d'application des conventions de code (qui va relire ce fatras?), quand il faut diagnostiquer un bug (Si ca plante, y'a que lui pour avoir l'explication).

Par défaut, tout cela revient directement jusqu'à celui qui a produit le code, car c'est lui qui détient ultimement la connaissance. Cela signifie qu'il devient rapidement un passage obligé pour nombre de phase de vie de l'entreprise, alors même que le code a quitté son giron depuis longtemps. Or, il n'est pas toujours possible de retrouver le développeur, pour de multiples raisons (affectation à une nouvelle mission, démission, mort, vacances, calendrier chargé...)

C'est ici que savoir se passer du ou des développeurs se révèle une pratique indispensable. Si les équipes d'administration doivent faire l'installation durant la nuit, un script de déploiement automatique permettra de le faire sans interroger l'auteur du code. Et cela sera même critique dans le cas où l'intervention se fait en urgence : montée en charge subite, retour en arriève de version, etc.

On peut assurer de nombreuses tâches comme ceci :

• tests unitaires automatiques (phpunit alltests.php)
• analyse statique (pmd)
• déploiement (phing, capistrano)

Dans ces situations, même en l'absence de développeur, on peut vérifier la qualité du projet, obtenir un diagnostic de la situation ou installer une nouvelle machine. Certes, les tests unitaires ne couvriront surement pas toutes les situations, mais ils permettront de vérifier les situations les plus simples, et même par une personne étrangère au projet ou non-technique.

Du point de vue individuel, c'est aussi une phase importante dans le cycle de vie du projet. Quand on travaille sur du code dans un projet, il est important de savoir s'en séparer, de couper le cordon ombilical. Si on est le seul à maîtriser une application, on devient indispensable, et on risque aussi de finir enchaîné à des corrections et évolutions infinies.

À chaque fois que j'ajoute une nouvelle fonctionnalité, je me demande à moi-même : comment mes utilisateurs pourront-ils faire des modifications sans passer par moi? Fouiller toute l'application? Faut-il manipuler du code? Lire une documentation? Changer une configuration ? Moins j'obstruerai la progression, mieux cela sera pour eux.

Et pour moi aussi. Car je ne compte pas rester toute ma vie sur le même projet.