PHP a 20 ans !

8 juin 2015 php

Le 8 juin 1995, il y a 20 ans aujourd’hui, Rasmus Lerdorf annonçait la version 1.0 de ce qui s’appelait à l’époque Personal Home Page Tools, ou PHP Tools.

Il s’agissait alors uniquement d’un ensemble de binaires CGI écrits en C, résolument orientés « Web », puisqu’ils permettaient dès cette première version de créer des formulaires et de réutiliser plus tard les informations saisies, de mettre en place des compteurs d’accès, de suivre des logs, … Ce mail d’annonce faisait même explicitement référence à la facilité de mise en place d’un livre d’or apportée par ces outils !

Pour vous donner une idée de la taille réduite de PHP à cette époque, voici la liste des 18 fichiers composant la distribution de PHP 1.0.8 :

$ tree php-108
php-108
├── common.c
├── common.h
├── config.h
├── error.c
├── html_common.h
├── License
├── Makefile
├── phpf.c
├── phpl.c
├── phplmon.c
├── phplview.c
├── post.c
├── post.h
├── README
├── subvar.c
├── version.h
├── wm.c
└── wm.h

0 directories, 18 files

Vous pouvez comparer avec le contenu actuel de la branche master ;-)


Après plusieurs ré-écritures et changements de noms, PHP/FI (pour « Forms Interpreter ») a été introduit en avril 1996 : d’un ensemble d’outils, PHP avait commencé à évoluer vers un véritable langage de programmation, avec support de plusieurs bases de données, des cookies, la possibilité pour l’utilisateur de définir des fonctions, …

PHP/FI 2.0 est sortie en novembre 1997, alors qu’une nouvelle ré-écriture du moteur d’analyse était déjà en cours — la version 2.0 est d’ailleurs la seule version stable de PHP/FI qui ait été publiée !

L’écriture de code PHP/FI commençait déjà plus ou moins à ressembler à ce que l’on connait de PHP aujourd’hui, même si tout n’était pas encore fixé. Pour les curieux, le manuel de PHP/FI 2.0 est toujours disponible : PHP/FI Version 2.0 ; et voici le code d’un des exemples qui était fourni avec PHP 2.0 :

<?
    msqlsethost("localhost");
    $name = "bob";    
    $result = msql($database,"select * from table where firstname='$name'");
    $num = msql_numrows($result);
    echo "$num records found!<p>";
    $i=0;
    while($i<$num);
        echo msql_result($result,$i,"fullname");
        echo "<br>";
        echo msql_result($result,$i,"address");
        echo "<br>";
        $i++;
    endwhile;
>


En 1997, Andi Gutmans et Zeev Suraski ont commencé à travailler sur une ré-écriture complète de l’analyseur. Leur collaboration avec Rasmus Lerdorf, visant à la fois à améliorer le moteur et à profiter des nombreux utilisateurs existant de PHP/FI, mena à une nouvelle version du langage : PHP 3 — avec au passage un changement de nom, PHP signifiant désormais « PHP: Hypertext Preprocessor ».

Au delà de sa syntaxe, un des avantages majeurs de PHP 3.0, publié en juin 1998, fût son mécanisme d’extensions : en complément des modules intégrés à la distribution de base du langage, de nombreux autres ont pu être développés, permettant réellement à PHP d’agir comme glue entre plusieurs composants.

Il me semble que les tous premiers scripts que j’ai écrit en PHP étaient sous PHP 3, pendant mes années lycée, d’ailleurs !


PHP 3.0 venait à peine de sortir qu’une nouvelle ré-écriture du moteur fût lancée. Elle mena au Zend Engine, sur lequel s’appuyait PHP 4.0, publié en mai 2000.

Cette version apportait une amélioration conséquente des performances, ainsi que le support de nombreux serveurs web ou des fonctionnalités comme la gestion des sessions HTTP.

C’est avec PHP 4 que j’ai réellement commencé à développer pour le Web. C’est d’ailleurs aussi la version de PHP que j’ai commencé à utiliser dans le cadre de mes études !


Après une longue phase de développements, qui va sans doute de pair avec le fait que PHP 4 était déjà largement utilisé, PHP 5.0 a été publiée en juillet 2004.

Cette version, basée sur Zend Engine 2, a notamment introduit un nouveau modèle objet1 et a été suivie en plus de 10 ans par six versions mineures apportant nombreuses améliorations au langage.

D’une certaine manière, c’est avec PHP 5 et ses différents versions mineures que PHP est passé du statut de langage amateur à celui de langage permettant de réaliser des développements professionnels d’applications de grande envergure — avec le niveau de qualité que l’on est en mesure d’attendre en 2015. Bien sûr, les efforts poussés par l’ensemble de la communauté, que ce soit en termes de bonnes pratiques ou de composants open-source de qualité, n’y sont pas pour rien !

PHP 5 a d’ailleurs été la première version de PHP que j’ai utilisée dans un contexte professionnel (en 2006). Pour mon premier gros projet, une des questions qui s’étaient posées à son lancement était même « faut-il rester sur PHP 4 ou se lancer sur PHP 5 ? » !


Aujourd’hui, après une tentative « PHP 6 » ratée il y a plusieurs années et une activité assez intense sur 2014 et début 2015, PHP 7.0 est en cours de stabilisation et on peut raisonnablement espérer une publication en fin d’année !

Cette version apportera à nouveau un gain important en termes de performances, ainsi qu’une nouvelle série d’améliorations et d’évolutions. Je vous encourage vivement à les découvrir et à tester vos applications sous PHP 7 dès maintenant !


En tout cas, aujourd’hui est le jour parfait pour dire « Bon Anniversaire ! » et « Merci ! » à PHP et à sa communauté !



  1. Un véritable modèle objet, diraient certains ? 

Développeur : plus que du 9h-18h !

3 juin 2015 travail

Je me souviens d’une conversation, il y a plusieurs années de cela, alors que je ne travaillais pas encore depuis bien longtemps, avec un chef qui faisait remarquer que les développeurs ne bossaient pas depuis chez eux, puisqu’ils avaient des PCs fixes1.

Avec un peu de recul, j’ai noté que les développeurs que j’avais autour de moi tenaient leurs horaires — et pour certains, faisaient nettement plus d’heures que ce qui aurait été dicté par la raison. En ne considérant que le nombre d’heures passées au bureau2, ils n’avaient donc rien à se reprocher3.

Mais ce qui n’était vu de personne, hormis d’une partie de leurs collègues eux-aussi développeurs, c’était le temps investi, souvent le soir et/ou le week-end, en veille technique !


Pour donner un exemple précis avec des données quantifiées : une année, j’avais pris deux semaines de vacances pour Noël. Au début de ces deux semaines, j’avais 4894 articles à lire dans mon ReadItLater. À la fin des vacances, j’avais vidé ma liste d’articles à lire5 et j’avais donc dépilé de l’ordre de 500 articles en deux semaines (puisque, sur cette durée, j’en ai aussi lu qui n’étaient pas dans cette liste au départ).

En comptant une moyenne de cinq minutes par article6, ça représente environ 40 heures de veille (soit une semaine de travail) étalées sur deux semaines.

En approchant les choses différemment : si vous passez une demi-heure à dépiler vos flux RSS en buvant votre café en vous levant le matin et une autre demi-heure à expérimenter quelques bouts de code sur votre temps de pause midi, ça fait une heure par jour — soit cinq heures par semaine et 20 heures par mois. Autrement dit, à raisons de deux demi-heures par jour, vous en êtes déjà à cinq à six semaines de veille par an7 — soit plus que le compte de base de congés payés !


Souvent, pour une entreprise, à court terme, ce qui semble rapporter de l’argent (ou, du moins, ce qui est visible et facilement mesurable) est le temps passé au bureau par les développeurs8, à travailler sur les projets fixés par celle-ci. C’est normal, après tout : c’est la plus grosse partie du métier de développeur tel qu’il est vu par beaucoup de non-techniciens.

Toutefois, ces 35 à 40 heures hebdomadaires sont nettement complétées, pour de nombreux développeurs, par d’autres activités — qui sont elles-aussi en rapport avec leur métier9 : veille technique, lecture d’articles, de blogs et de livres, participation à des conférences (dans le public ou en tant que conférenciers), rencontre d’autres développeurs à des événements communautaires, …

Tout ce temps, aujourd’hui, n’est que trop rarement valorisé. Alors que sans ce réel investissement réalisé par les développeurs qui aiment tant leur métier10, bien des projets et des équipes n’avanceraient pas comme ils le font aujourd’hui !



  1. Sous-entendu : PCs fixes que les développeurs ne pouvaient pas emporter chez eux pour travailler, contrairement à lui avec son portable. 

  2. Et le nombre d’heures passées au bureau est, dans certaines entreprises, le moyen utilisé pour déterminer si un développeur fait correctement son travail. 

  3. Ça me rappelle un peu la fois où je quittais le bureau aux environs de 19h et où un chef (qui n’avait aucun lien hiérarchique avec moi !) m’avait fait “tu as pris ton après-midi ?”. Ceux d’entre vous qui me connaissent suffisamment savent que j’ai tendance à prendre un peu trop de remarques au premier degré (mes collègues actuels ont fort gentiment créé un panneau “SARCASM” pour moi, alors que ça ne faisait encore que quelques jours que j’avais été embauché…) et pourront sans mal imaginer la tronche que j’ai tirée… 

  4. Oui, j’avais noté combien d’articles j’avais : j’étais curieux de voir si j’allais arriver au bout et en combien de temps — et j’ai gardé ce nombre sous le coude, en pensant à cet article que j’allais peut-être écrire un jour. 

  5. Ça remonte à plus de trois ans… Et depuis, je n’ai jamais réussi à revenir à 0 article à lire ;-( 

  6. Je n’ai pas tout chronométré : certains articles longs ont été lu en profondeur et d’autres ont été diagonalisés très rapidement — je compte donc entre 1 minute et 15 minutes par article, soit une moyenne qu’on doit pouvoir caser aux environs de cinq minutes. 

  7. Et vous noterez que je n’ai pas compté de temps sur les week-ends ;-) 

  8. entre 9h et 18h, ou plus, pour ceux qui n’auraient pas réalisé que pousser les équipes à l’épuisement ne produit rien de bon sur le long terme ! 

  9. Et beaucoup de ces activités constituent une forme d’auto-formation, dont l’employeur bénéficie forcément ! 

  10. C’est peut-être une partie du problème : avoir un métier qui est également, sous certaines formes, une passion ! 

Moi, 30 ans, développeur — et je n'ai pas raté ma vie !

11 mai 2015 travail

J’ai débarqué dans le monde du travail par une belle matinée1 de janvier 2006 — lundi 30 — pour le premier jour de mon stage de fin de master.

Les étoiles plein les yeux, quand mes nouveaux collègues me demandaient ce que je voulais faire ensuite, je répondais, bien évidemment, « je veux devenir chef de projet ». Après tout, même si les nuits blanches passées à coder sur les années précédentes m’avaient laissé de très bons souvenirs2, nombreux étaient ceux qui sortaient de l’école3 en voulant évoluer — et ce rapidement !

À la fin de mon stage, j’ai été embauché. Étrangement, après avoir fréquenté un peu le monde du travail et vu ce à quoi mes collègues occupaient de leurs journées, cela faisait quelques mois que je n’avais plus dit que je voulais devenir chef de projet : même si je n’avais pas vraiment bossé avec les technos les plus cool4, construire quelque chose était tellement fun ! Bien plus que remplir des .doc ou des .xls ou négocier des quarts de journées avec le client5 !


Plusieurs années se sont écoulées, je suis tour à tour devenu « ingénieur concepteur et développeur », « expert technique », « architecte », « développeur senior »6. Et je suis maintenant « développeur ».

En parallèle, j’ai changé plusieurs fois d’employeur, partant d’une SSII de 2000+ employés pour arriver dans une startup où j’ai une quinzaine de collègues, en passant par un éditeur regroupant une cinquantaine de personnes — chaque entreprise accordant moins d’importance aux titres, et plus d’importance aux réalisations, que la précédente.

D’ailleurs, voila plusieurs années que, travaillant en méthodes agiles, le terme de « chef de projet » ne fait plus partie de mon quotidien : l’idée de chef a été remplacée par des rôles différents7 (scrum master, product owner, développeur, …), tous collègues au même niveau hiérarchique, constituant une équipe qui vise à mener ses projets à bien8 !


Mais si évoluer n’est pas nécessairement devenir chef de projet — ce qui, d’une certaine manière, revient à changer de métier — dans les trois ans qui suivent le début de sa vie professionnelle, comment est-ce que ça se passe ?

Peut-être que évoluer, c’est aussi savoir tirer profit de son expérience ? Pour être plus efficace dans son travail, pour avoir une vision à plus long terme de ses projets, pour mettre en place des architectures ou du code plus maintenable, pour être là pour ses collègues… Et pour, finalement, aider l’ensemble de son équipe à évoluer ?

Peut-être que, en fait, ce n’est pas non plus avoir un titre pompeux sur sa carte de visite ou son CV ?


Vous vous souvenez quand, au moment de « si à 50 ans on n’a pas une Rolex, c’est qu’on a raté sa vie », on disait « si à 30 ans tu es encore développeur, c’est que tu as raté ta vie » ? Déjà en 2009, ça faisait quelque peu sourire…

Aujourd’hui, je fais un métier qui me plait, je vais au travail tous les jours en sifflotant et sans traîner des pieds, je bosse dans une boîte sympa, j’ai des collègues que j’apprécie — et même si je ne suis pas chef comme j’aurais dû l’être si j’avais écouté les autres il y a dix ans… C’est ce qui compte, non ?

Je peux donc, aujourd’hui9, affirmer fièrement : j’ai 30 ans, je suis développeur, je n’ai pas raté ma vie !



  1. Je dis belle matinée, mais je ne saurais plus me rappeler du temps qu’il faisait ; je sais juste qu’il y avait de la neige en fin de semaine, je me souviens être resté coincé dans un train pendant deux heures à cause de ça le vendredi. Quoi qu’il en soit, j’attendais la fin de mes études avec une certaine impatience : je voulais faire quelque chose d’utile — donc, c’était une bonne journée ! 

  2. Les week-ends et autres nuits blanches passés à jouer à Starcraft en LAN avec les collègues (un des avantages d’habiter dans une résidence quasi-étudiante pas loin du campus) sont un autre excellent souvenir ;-) 

  3. Quand la normalité semble être « devenir chef de projet » et qu’on ne connait pas grand chose au monde du travail ou aux différents métiers et ce qu’ils représentent exactement, le plus facile et le plus prudent est de s’orienter sur ce discours normal… 

  4. J’ai passé les 2/3 de mon stage sur de l’ASP pas NET, avant de passer sur du .NET 1.x et un tout petit peu de .NET 2 — 2006, hein ;-) 

  5. Oui, je simplifie beaucoup le rôle du chef de projet ! Rappelez-vous que ça ne faisait que quelques mois que je bossais ; et pas vraiment sur des gros projets. Finalement, je ne connaissais rien du métier de « chef de projet », si ce n’est qu’il y avait « chef » dedans, je crois… 

  6. J’ai bien eu du mal à l’expliquer à la médecin du travail, le coup du développeur sénior. Je continue à me demander si elle a saisit de quoi il s’agissait, d’ailleurs : en récupérant le papier après, j’ai vu qu’elle avait écrit « développeur séniors ». Qu’a-t-elle cru que je faisais comme métier ? 

  7. Ca m’a fait tout drôle lorsque j’ai assisté à une réunion de plannification pour la première fois, de voir que ce n’était pas le chef de projet (inexistant, pour cette équipe ! Alors qu’il était souvent tout puissant dans l’équipe que j’avais quitté deux semaines plus tôt !) qui décidait combien de temps devait être alloué à une tâche, mais bel et bien les développeurs, responsables de son implémentation, à qui on faisait confiance pour estimer le temps nécessaire ! 

  8. Même si on l’oublie parfois, mener nos projets à bien est ce pour quoi nous sommes généralement employés ;-). Cela signifie produire des logiciels qui répondent aux besoins des clients, en un temps (qui peut être un des besoins) acceptable, avec des contraintes de coût et de rentabilité (idem), tout en arrivant à quelque chose de maintenable, idéalement en s’étant fait plaisir au passage — une équation parfois complexe ! 

  9. Bien sûr, libre à moi de changer complètement d’avis (ou de métier) demain. Ou l’année prochaine. Ou dans 10 ans ;-) 

La prod est tombée !!!

5 mai 2015 travail, histoire

Aujourd’hui, je vais raconter quatre histoires : quatre cas où la prod est tombée, avec à chaque fois un contexte et des réactions différentes.


Histoire n°1

Cette première histoire commence de manière assez classique1 : le client passe un coup de téléphone au chef pour lui signaler que la prod est tombée et qu’il faudrait investiguer au plus vite.

Le chef se tourne vers son développeur, lui signale le problème et demande « qu’est-ce que je peux faire pour toi ? ». Le développeur répond que son chef peut commencer par « gérer le client » et qu’au besoin, il lui fera signe, en fonction des résultats de ses recherches.

Le développeur a résolu le problème assez rapidement. Le chef a répondu au client qui est venu aux nouvelles une ou deux fois entre-temps.

Point fort : le développeur a pu faire son boulot en paix, efficacement, sans que personne ne le dérange. En cas de problème, il pouvait appeler à l’aide ou demander des renseignements complémentaires.


Histoire n°2

La seconde histoire correspond à la mise en production d’un site grand-public, qui s’est déroulée un week-end. Au moment de valider le système de paiement utilisé par l’application, l’équipe s’est rendue compte que celui-ci ne fonctionnait pas2 — et après prise de renseignements, impossible de l’activer avant le lundi (et bien sûr, impossible de décaler de deux jours la mise en production).

Après discussion entre le développeur expérimenté et le développeur qui avait initialement branché le système de paiement dans l’application, ainsi que le chef et le client, il a été décidé de mettre en place une solution de contournement3.

Il était presque midi, les pizzas sont arrivées à ce moment là et le gros de l’équipe est parti déjeuner en salle de pause, pendant que le développeur restait à son poste, mangeant sa pizza d’une main en gardant le clavier sous l’autre, occupé à dé-brancher un premier système de paiement et à en brancher un autre passant par la solution de contournement retenue.

Point fort : l’équipe (développeurs + chefs + clients) a fait confiance au développeur : il a pu faire son boulot dans de bonnes conditions4, tout en ayant eu du soutien lors de la phase de recherche de solution.


Histoire n°3

Cette troisième histoire commence par un site grand-public tombé, en raison d’un pic de consultations brutal.

Arrive un grand-chef5 qui ordonne aux développeurs de débrancher leurs PC fixes et d’aller dans le bureau des administrateurs système, à l’autre bout du bâtiment — notez qu’il s’agit de PC fixes (donc, il faut vraiment tout débrancher, y compris écran et clavier et souris, trouver un chariot, …). Une fois arrivés à l’autre bout du bâtiment, le grand-chef ordonne de re-brancher le tout (ce qui inclut trouver une ou deux multi-prises, des chaises, de faire de la place sur un bureau, de tout rebrancher et rallumer…).

Une fois les développeurs et administrateurs système laissés entre eux, finalement, chacun des deux développeurs ayant fait le voyage s’est mis en pair avec un administrateur — sans toucher aux PCs qui avaient été déplacés. Une dizaine de minutes après, une piste était trouvée. Quelques minutes supplémentaires et une bidouille temporaire était en place pour corriger le problème au plus vite.

Bien sûr, il a ensuite fallu faire le trajet inverse, en débranchant les PCs (et rendant les chaises et multi-prises à leurs propriétaires dans d’autres bureaux), les re-posant sur le chariot, re-traversant le bâtiment, puis en rebranchant les PCs à l’autre bout, …

Point fort : les développeurs et administrateurs système ont mis en commun leurs compétences respectives (et connaissance de l’application / de la plate-forme l’hébergeant) pour rapidement trouver l’origine du problème et apporter une solution6.

Questions bonus : combien de temps a été perdu avant de vraiment s’attaquer à la résolution du problème ? Et avant de recommencer à bosser ensuite ?


Histoire n°4

Cette quatrième et dernière histoire commence elle aussi de manière assez classique : la prod est tombée, sur un site grand-public, sans raison apparente (pas de pic de consultation majeur), et les développeurs recherchent ce qui pourrait expliquer cette chute.

Le N+37 a été appelé par des gens importants, la pression monte. N+2 décide donc qu’il faut faire une réunion, avec N+1 et le lead-dev du projet. Cette réunion dure un moment, pendant lequel les autres développeurs continuent à fouiller — mais ils ont moins d’expérience que le lead-dev sur ce type de situation, connaissent moins bien que lui les points sensibles de l’application et n’osent pas mettre en œuvre seuls les pistes qui avaient été évoquées avant la réunion. Pendant cette réunion, le lead-dev propose un truc (genre modifier un paramétrage) pour essayer de calmer le feu. Le N+2 est d’accord, mais indique qu’il ne faut pas en parler à N+3.

A l’issue de cette réunion, le lead-dev retourne à son équipe, la proposition technique est mise en place et le site web a l’air de re-fonctionner de manière correcte. Le lead-dev profite de l’accalmie pour aller chercher un café.

Dans la salle de pause, le lead-dev est rejoint par le N+3 qui lui dit « j’ai vu que les graphes munin redescendaient, viens dans mon bureau et dis-moi ce que tu as fait ». N’ayant pas réellement le choix, le lead-dev suit le N+3 et explique la modification apportée (en se disant qu’il ne devrait pas mais n’a pas trop le choix — N+2 avait dit qu’il ne fallait pas que N+3 sache, mais le développeur ne fait pas de politique. Et, en même temps, la proposition en question a rétabli le bon fonctionnement du site, hein).

Après cela, le lead-dev se prend un commentaire du N+2 en mode « je t’avais dit de ne pas en parler à N+3 », suivi de l’interrogation de N+1 « mais tu lui as dit ? »

L’objectif8, après avoir lu cette histoire, est double : déterminer combien de temps a été perdu avant de résoudre le problème… Et estimer l’humeur et le niveau de motivation du lead-dev après cet incident — ainsi que son envie de continuer à bosser là.

Question bonus à laquelle personne n’a su répondre : pourquoi le N+3 a-t-il accès aux graphes de monitoring des serveurs et essaye-t’il de les analyser ? Et surtout, pourquoi est-ce qu’il ne se fie pas à ses équipes, qui ne lui font donc pas non plus confiance en retour ?


Et maintenant ?

Après ces quelques histoires, quelle situation vous convient le mieux, quand la prod est tombée ?

Pour ma part :

  • Être à deux à se mettre sur le problème, en pair (sur la même machine ou non — mais proches l’un de l’autre, pour échanger des idées et savoir ce que l’autre a fouillé ou envisage), permet d’aller plus loin dans l’analyse et de recouper les idées.
  • Mélanger les compétences (« dev » et « ops ») est un gros plus.
  • Et enfin, à mes yeux : le rôle d’un chef dans ce type de situation est de faciliter les choses pour son équipe, en absorbant la pression et en lui permettant de travailler sans être interrompu par des éléments perturbateurs (clients, hiérarchie, chef lui-même) — tout en étant disponible au besoin et en se tenant au courant (par exemple, en étant connecté sur l’outil de messagerie instantanée utilisé par l’équipe, en écoutant ce qu’il se dit — et pas en allant interrompre les développeurs toutes les trois minutes façon « c’est urgent, vous en êtes où ? » !

Et vous, des souvenirs de jours où la prod est tombée ?



  1. Une variante de ce début d’histoire, sur un projet un peu mieux outillé, serait une alerte remontée par le système qui monitore le bon fonctionnement des serveurs et applications de production. Dans ce cas, ce serait le chef qui informerait le client qu’un problème a été identifié et que la recherche de solution est en cours. 

  2. Bien sûr, si le système de paiement avait été validé en mode production à l’avance, plutôt que de considérer que ça marcherait forcément en production puisque ça marchait en test… Voilà une erreur que plusieurs membres de l’équipe n’ont pas refait depuis ! 

  3. Le niveau d’ingéniosité (enfin, de bidouille ^^ mais qui marche !) qu’on peut atteindre dans ce type de situation est assez incroyable ;-) 

  4. Et plusieurs années après, même si sur le coup c’était bien galère, le développeur a gardé un super souvenir de cette journée et de cette pizza ! 

  5. Pour cette histoire n°3, “grand-chef” correspond globalement au N+4 des développeurs. Quelqu’un de haut dans la hiérarchie, donc — à qui le développeur, peut-être encore un peu jeune et manquant d’expérience, ne dit pas “non”. 

  6. Travailler en mettant en commun les compétences des développeurs et des administrateurs système est quelque chose qui semble évident aujourd’hui à beaucoup d’entre nous. Ça ne l’était pas tellement à l’époque — le terme devops était encore loin d’être à la mode. 

  7. Pour cette quatrième histoire, les « N+X » sont relatifs au lead-dev : le N+1 est le chef de projet, le N+2 le directeur de projets web, … Autant N+1 est quelqu’un que les développeurs connaissent bien, autant N+3 est quelqu’un de plus distant, à qui les développeurs n’osent pas dire « non ». 

  8. En relisant cette quatrième histoire, je n’ai pas le sentiment qu’on puisse parler de point fort… Mis à part, bien sûr, le fait qu’une solution ait été trouvée. 

PHP : un langage, des utilisateurs aux besoins très différents

21 avril 2015 php

Il m’arrive régulièrement de discuter de PHP1 et de son évolution avec d’autres développeurs, que ce soit au bureau, lors d’événements communautaires comme les Apéros PHP ou les ForumPHP/PHPTour, ou même plus simplement par mails ou messageries instantanées.

Assez fréquemment, ces développeurs veulent voir le langage (et son écosystème) continuer à mûrir, à se professionnaliser : ils souhaitent du typage statique, des espaces de noms, du type-hinting (ou type-enforcing) sur les paramètres de méthodes ou leur valeur de retour, des générateurs, des annotations intégrées au langage, … Bref, plein de fonctionnalités qui nous — moi y compris — simplifieraient grandement la vie et nous permettraient de tirer le meilleur parti du langage que nous manipulons.

Toutefois, nous oublions souvent que nous ne sommes pas les seuls utilisateurs du langage PHP. Pour moi, en généralisant un peu et simplifiant beaucoup, on pourrait aller jusqu’à distinguer quatre catégories d’utilisateurs de notre langage. Et chacun de ces types d’utilisateurs peut avoir des besoins différents des autres !


Les débutants en programmation (et en PHP)

Une des grandes forces de PHP depuis sa naissance, et sans aucun doute la principale raison de son succès, est que PHP et son écosystème ont pendant longtemps été extrêmement accessibles aux débutants en programmation voulant faire un peu de web.

Cela se traduit à travers plusieurs points, dont notamment :

  • La gratuité, que ce soit pour de nombreux outils de développement2 ou hébergements3.
  • La facilité d’installation, de configuration et d’exécution :
    • Au niveau du poste de travail — avec, par exemple, des outils comme EasyPHP ou WAMP qui permettent d’installer une stack PHP+MySQL en trois clics sur « suivant », sans même avoir à comprendre comment ça fonctionne4.
    • Au niveau du déploiement : il suffit d’un glisser-déposer dans un client FTP, sans avoir à redémarrer un serveur d’application ou quelqu’autre lourdeur du même type.
    • Et au niveau de l’exécution : il suffit d’appuyer sur F5 pour constater l’effet du code que l’on vient d’écrire ou de déployer !
  • L’existence de nombreux tutoriels5, ainsi que d’une documentation officielle claire et en très grande partie traduite en français.

Pour un débutant, PHP doit être un langage simple : plus le langage se complexifie (par l’ajout de fonctionnalités), plus il devient difficile à prendre en main.

Même si les nouveautés de chaque version ne sont pas obligatoires et qu’il est possible de développer sans les utiliser, elles constituent autant de points qui sont susceptibles de provoquer des moments de confusion et de frustration lors de lecture de tutoriels, d’exemples de code, ou même de documentations.

PHP a été le premier langage orienté web que j’ai appris — l’autre langage que je connaissais à ce moment là est le C, qui n’est pas de bien haut niveau et ne s’encombre pas de certaines lourdeurs modernes6. Si, à l’époque, pour entrer dans PHP, il avait fallu que je me débatte avec les closures, les espaces de noms, les générateurs, composer ou symfony… Je ne sais pas si je ne me serais pas plutôt mis aux CGI7 ^^


Les amateurs

Une partie des débutants se prend au jeu, sans pour autant devenir professionnels comme beaucoup d’entre-nous l’ont fait — et deviennent alors ce que j’appelle des développeurs amateurs. Cette appellation regroupe pour moi ceux dont le développement n’est pas le métier, mais qui en savent assez pour oser mettre en place des scripts ou de petites applications répondant à leurs besoins.

Comme exemple assez marquant, j’avais un collègue il y a quelques années qui était product owner : son métier n’était pas le développement, mais il avait suivi quelques cours de JAVA et PHP à l’école et travaillait dans une entreprise où il côtoyait quotidiennement nombre de développeurs. Il se débrouillait suffisamment bien en PHP pour développer des scripts lui permettant d’automatiser certaines tâches (détection de mise à jour et téléchargement de documentation, parsing de fichiers CSV pour en extraire les valeurs importantes, …) qu’il aurait autrement dû effectuer manuellement. Sans pour autant avoir un compilateur dans la tête, il était capable de comprendre la structure d’une portion de code et ce qu’elle faisait dans les grandes lignes — ce qui facilitait d’autant les échanges avec les développeurs de son équipe !

PHP est à mes yeux un bon langage pour ces amateurs : sa simplicité d’utilisation (cf ce que je disais plus haut pour les débutants), combinée à sa verbosité ainsi qu’à sa souplesse (au niveau du typage, notamment), en font un outil bien adapté aux besoins de personnes qui souhaitent automatiser des tâches, sans que le développement ne soit pour autant leur métier. En contrepartie, cette souplesse peut parfois être à double tranchant, puisqu’elle encourage trop souvent des pratiques de développement peu sûres, notamment au niveau de ce qui est sécurité.

Pour PHP lui-même, le juste-milieu est difficile à trouver pour les développeurs amateurs : ils ont des notions, parfois bonnes, en programmation et sont capables de comprendre des concepts assez avancés — à condition que ceux-ci arrivent graduellement et ne masquent pas la simplicité du langage en le rendant moins accessible.


Les utilisateurs et intégrateurs de logiciels

Ma troisième catégorie de développeurs est composée de ceux qui partent de logiciels existant (assez typiquement, des CMS comme Drupal ou Wordpress) qui répondent au gros de leurs besoins et tirent profit de l’extensibilité de ces outils pour développer des modules complémentaires répondant aux quelques pourcents de leurs besoins qui ne sont pas couverts de base.

En fonction de l’outil choisi, les développements peuvent être assez cadrés, rendant difficile (ou décourageant, ne serait-ce que par leur non-utilisation dans le cœur de l’outil) l’utilisation de certaines fonctionnalités récentes. De plus, des contraintes de compatibilité avec de vieilles versions de PHP peuvent être souhaitées pour les modules qui sont destinés à être diffusés auprès de la communauté.

En fonction de leur niveau d’expérience, des fonctionnalités qu’ils souhaitent développer (faut-il personnaliser beaucoup ou peu ?), ainsi que de leur volonté ou non de diffuser ceux-ci à un large public, les développeurs de modules pour ces logiciels vont avoir tendance à exploiter ou non les fonctionnalités avancées de PHP8.

Pour ce public cible, qui compte nombreux professionnels, un langage qui évolue peut faciliter le travail sur le long terme, même si ces évolutions requièrent parfois une passe de formation : celle-ci sera probablement amortie au bout d’un moment. Cela dit, le langage doit rester stable, et ne pas subir une révolution tous les ans !


Les développeurs (PHP) full-time

Le dernier groupe de développeurs que j’ai retenu pour cet article est composé de ceux dont le développement est le métier principal — considérant mon lectorat habituel, il y a de bonnes chances pour que vous soyez dans ce cas.

Pour beaucoup de développeurs à plein temps, chaque nouvelle fonctionnalité, chaque évolution, est susceptible de nous faire gagner du temps ou d’aider à améliorer la qualité de nos projets : manipulant PHP au quotidien, que ce soit dans un contexte pro ou en dehors, le temps investi à expérimenter avec les usages d’une évolution sera rapidement amorti ! C’est par exemple souvent ici que sont regroupés ceux qui voudraient plus de typage statique, plus de type-hinting, ou encore ceux qui regardent avec un certain intérêt les spécificités du langage Hack.

Le plus souvent, les développeurs PHP avec qui je discute d’évolution du langage font partie de ce dernier groupe — et oublient qu’ils ne représentent qu’une (petite) partie des développeurs qui manipulent PHP ! Même si c’est peut-être celle qui a le plus tendance à s’exprimer dans la communauté ?


Et PHP dans tout ça ?

Au milieu de ces quatre types d’utilisateurs, l’évolution de PHP est tiraillée entre des besoins très différents :

  • D’un côté, le langage doit évoluer et continuer à se professionnaliser, pour répondre aux besoins de ceux d’entre nous qui l’utilisent tous les jours, sur des applications importantes, où la maintenabilité et l’évolutivité sont primordiales. Et des très gros progrès ont été fait ces dernières années !
  • Mais, d’un autre côté, le langage doit rester fidèle à son image de facilité et d’accessibilité : sans débutant hier, PHP n’aurait jamais eu la place qu’il a aujourd’hui. Et sans débutant aujourd’hui, PHP ne conservera pas sa place actuelle.

Au-delà des dimensions politiques et de maintenabilité de PHP en lui-même, ces deux points de vue, souvent opposés, se retrouvent fréquemment lors des discussions autour de propositions de fonctionnalités au sein du langage — et sont parfois une explication au fait que certaines évolutions, qui pourraient sembler indispensables à un groupe ou inimaginables à l’autre, passent ou non.



  1. PHP au sens large : le langage et son évolution, l’écosystème applicatif, les frameworks et bibliothèques, les outils, la qualité, … 

  2. Pour développer en PHP, un éditeur de texte suffit — même si, avec le temps et l’expérience, on aura souvent tendance à se tourner vers des environnements plus complets. 

  3. Ça se fait peut-être moins maintenant qu’il y a quelques temps (ça fait un moment que je ne me suis pas posé la question), mais avant, on trouvait des hébergements PHP gratuits un peu partout. 

  4. Comprendre comment une pile serveur web + langage côté serveur + base de données fonctionne est important lorsque l’on souhaite progresser vers du développement plus poussé… Mais est-ce qu’un débutant a réellement besoin de comprendre ces notions dès qu’il se lance ? A mon avis, non : il y a plus intéressant (et plus fun !) à voir avant ! 

  5. J’admets : le problème avec de nombreux tutoriels est qu’ils sont vieux, pas forcément mis à jour avec les bonnes pratiques de développement, parfois bourrés d’erreurs et de références à des fonctions obsolètes ou à des pratiques dépassées (y compris dans des tutoriels récents) — donnant ainsi parfois de mauvaises habitudes aux développeurs débutant qui les suivent souvent aveuglément. 

  6. En fait, lorsque j’ai commencé à apprendre le PHP, ce langage pouvait presque être comparé à du C (en supprimant le gros de la gestion de la mémoire, ce qui simplifiait bien les choses). En particulier, il n’y avait pas, en PHP, d’orientation objet et de tout ce qui va avec ! 

  7. J’ai fait un peu de Perl dans ma jeunesse, et j’aimais beaucoup en écrire (en relire, par contre, c’est autre chose). Si me mettre à PHP avait semblé plus complexe que fouiller l’écriture de CGI en Perl, je ne me serais peut-être pas mis à PHP ! 

  8. J’ai il y a quelques années eu l’occasion de développer plusieurs modules un peu complexes pour Drupal 6 (qui n’était lui-même pas vraiment « orienté objet ») — et je n’ai pas hésité à tirer profit des fonctionnalités avancées du langage.