Pourquoi critiquer autant PHP ?

by Joris on septembre 6, 2009

Lors de mon stage, j’ai eu l’occasion de discuter un peu avec des collègues qui ne développaient toujours en PHP. Je me demande pourquoi est-ce l’image de PHP n’est pas aussi « bonne » que celle de Java ?

Cette personne m’a fait un retour d’expérience avec PHP :

« Nous avions commencé un projet en utilisant PHP et cela nous convenait parfaitement car le développement a été rapide, simple et efficace. Mais quelques temps après, le client a demandé certaines évolutions que nous n’étions plus en mesure de développer sur notre application sans devoir tout casser… Du coups, pour éviter de perdre trop de temps dans ce basard, nous avons préféré recommencer l’application en Java. »

Pourquoi avoir craché sur PHP alors que Java n’est pas forcément le meilleur de choix en terme de portabilité et de simplicité ?

PHP et les autres langages

Je ne trouve pas PHP plus anarchique que Java ou .Net. PHP permet cette anarchie mais c’est à vous, architectes, de vous former et de savoir utiliser les bonnes méthodes et outils pour commencer le développement d’un projet évolutif, sécurisé et léger.
Des langages comme Java ou .NET sont beaucoup plus stricts dans les notions de paquetages et obligent les développeurs à garder une certaine rigueur… et encore !

Il faut bien le rappeler, dans tous les langages, les développements peuvent être anarchiques donc ceci n’est pas un reproche majeur à tenir en compte. Question de suivi.

PHP offre aujourd’hui la possibilité d’appliquer les principaux design patterns à vos applications ainsi qu’une implémentation objet du langage même si PHP ne sera jamais un langage 100% objet, mais c’est ce qui fait sa force.

Il est certain que PHP n’atteindra jamais la richesse des paquetages disponibles en Java ou .NET mais le peu qu’il y a est déjà plus que suffisant, et sont de très bonne qualité !

Un site Web, une application GTK ou alors un script shell ?

PHP permet de se répandre un peu partout pour vous suivre dans vos envies (comment je fais mon commercial là ^^). Selon vos besoins, il peut s’adapter très aisément à l’environnement d’exécution.
Il peut intervenir à tous les niveaux de votre application :

  • L’exécution de tâches automatisées CRON ;
  • Des simples scripts CLI de maintenance sur votre serveur ;
  • Des scripts de services toujours exécutés en CLI sur votre serveur ;
  • Pour le développement d’une application fenêtrée GTK ;
  • Le développement d’une application Web aussi simple ou complexe soit-elle ;
  • etc.

Avec PHP, vous pouvez lier une application GTK avec un Web service en passant par vos CRON et shell scripts full PHP. Puissant non ?

Intégration de PHP

Et oui, PHP est maintenant présent dans 95% des packs standard d’hébergement. Trop souvent encore disponible en version 4 et 5, les hébergeurs ont bien compris que ce langage serait celui de demain en ce qui concerne les applications Web. Sa souplesse d’intégration ne vaudra jamais celle de Java ou de .NET car mine de rien, l’avantage majeur est sa popularité.

Via le mode CGI, il peut carrément y avoir plusieurs versions de PHP installées sur le même serveur ou même simplement avec Apache en faisant écouter le serveur sur des ports différents (super pratique en phase de dev’) !

Vous utilisez déjà PHP, en version 5.3 ?

Si ça n’est pas le cas, je vous propose de lire un article court mais intéressant sur le gain de performance de la toute dernière version de PHP : Bench PHP 5.2 vs PHP 5.3 par Pascal Martin.

PHP se réserve un bel avenir

Mon but n’est pas de traduire le contenu de cet article mais je vous recommande de le lire. Les points que j’ai estimé manquants ont été écrit ci-dessus (ou pas).

12 comments

« les hébergeurs ont bien compris que ce langage serait celui de demain en ce qui concerne les applications Web. »

C’est déjà le cas ;-)

by Lolly on 06/09/2009 at 16:42. #

« le client a demandé certaines évolutions que nous n’étions plus en mesure de développer sur notre application sans devoir tout casser… »

Je voudrais bien savoir quel genre d’évolutions le client a demandé pour devoir en arriver là… Est-ce réellement dû à une limite de PHP ou à une mauvaise utilisation du langage ?

by Ishiro on 06/09/2009 at 19:01. #

@Ishiro

Je ne sais pas mais je penche plus pour la seconde réponse. Il est certain que lorsqu’un projet est voué à évoluer et qu’aucune phase de conception architecturale n’a été faite, on se décourage très vite lors d’une évolution majeure de la brique abstraite.

by Joris on 06/09/2009 at 19:22. #

Si tu dois tout reprendre à 0 à cause d’évolutions demandées par le client, c’est clairement que tu a mal conçu l’application dès le début.

Ce n’est pas forcément le langage qui est mauvais mais plutôt le développeur.
Ils auraient peut-être du rester en PHP en changeant de têtes.

by Damien on 07/09/2009 at 09:21. #

« Si tu dois tout reprendre à 0 à cause d’évolutions demandées par le client, c’est clairement que tu a mal conçu l’application dès le début. »

Oui, mais peut-être que dans la conception, le choix du langage a été mal fait, tout simplement. PHP ne permet pas de tout faire :D

by Mère Teresa on 07/09/2009 at 10:56. #

« PHP ne permet pas de tout faire »

Je peux le concevoir aisément, mais je voudrais bien avoir ne serait-ce qu’un exemple de ce qu’on ne peut pas faire en PHP d’une part, et qui justifierait la reprise d’un projet à partir de 0 d’autre part.

Ce que je veux dire, c’est que si un module d’une application requiert des besoins auxquels PHP ne peut répondre, il est toujours possible d’utiliser un autre langage pour ce module en particulier… Et ce n’est pas les formats d’échanges qui manquent (XML, JSON…).

by Ishiro on 07/09/2009 at 12:07. #

J’aimerais moi aussi savoir ce qui a été le problème dans ce projet. Pour savoir ce pourquoi PHP n’est pas fait, je te renvoie sur PHPFrance, certains ont développé de véritables argumentaires.
http://www.google.fr/search?hl=fr&q=%22php+n%27est+pas+fait%22+site%3Aphpfrance.com&

by Mère Teresa on 07/09/2009 at 14:11. #

Et pourquoi recommencer tout quand on peut garder ce qui fonctionne

http://files.zend.com/help/Zend-Server-Community-Edition/working_with_the_java_bridge.htm

by Moosh on 11/09/2009 at 11:33. #

Je m’étonne des critiques que l’on fait envers les développeurs dans ces commentaires. Pourquoi dire que les développeurs ont été mauvais et n’ont pas anticipé l’évolution de l’application ? Ce n’est pas un mal. Ce que l’on ne sait pas dans cette histoire, c’est est-ce que l’évolution de l’application avait été déjà abordée avant le début du projet ou bien était-ce un nouveau besoin du client qui est survenu après la livraison de l’application ? Dans le premier cas, les développeurs auraient pu anticiper l’évolution et mettre les décideurs et chefs de projet en garde. Dans l’autre cas, ils n’ont rien à se reprocher de ce côté là puisqu’ils n’étaient pas au courant d’une potentielle évolution et ils ont simplement développer l’application spécifiée.

Savoir anticiper des évolutions c’est bien mais ça passe aussi au second plan. Combien de projets évoluent réellement en si peu de temps ? En général, on demande aux développeurs de développer l’application juste comme l’indiquent les spécifications validées par le client. Pourquoi vouloir commencer à perdre du temps à anticiper des changements et des fonctionnalités qui n’auront certainement pas lieu d’être ? Vouloir trop anticiper, c’est aussi s’éloigner des spécifications et perdre du temps et donc de l’argent. Plus on cherche à anticiper et préparer l’application à des potentielles évolutions incertaines, et plus on perd du temps et de l’argent. Et comme nous le savons tous, en milieu professionnel, le premier nerf de la guerre c’est la rentabilité.

Pour commenter davantage cet article, je dirai que PHP n’est sans doute pas un bon langage en soi et encore moins le plus adapté pour tout. Certes il permet de solutionner la plupart des problématiques du web mais quand il s’agit de résoudre des problématiques plus complexes ou nécessitant des performances plus importantes, alors les développeurs doivent savoir s’orienter vers des solutions adéquates. Par exemple, s’il s’agit de réaliser de lourds traitements en environnement CLI (un traitement de plusieurs milliers d’images par exemple), il sera peut-être plus judicieux de se tourner vers l’écriture de scripts SHELL, Perl, Python ou autres programmes en C.

Pour moi, ce qui fait réellement défaut à PHP c’est son modèle orienté objet qui n’est pas encore suffisamment abouti. Il manque toujours de la surcharge de constructeur et de méthode, ainsi qu’un véritable typage fort (au moins pour les paramètres et valeur de retour des fonctions et méthodes).

Malgré tout, PHP reste un langage très pratique et simple à utiliser. Mais il faut garder en tête qu’il n’y a pas que lui et que la réussite d’un projet se justifie aussi par le choix du / des bons environnements techniques (langages de programmation, machines, web services…).

by Hugo on 11/09/2009 at 13:20. #

@Hugo

Merci pour ton commentaire Hugo, encore une fois ta sagesse l’emportera ;) Vu comment cette histoire m’a été racontée, ce fut un changement non pas prévu en début de projet mais inopiné pendant certaines phases terminales de développement.

Il est certain qu’il n’appartient pas aux développeurs d’anticiper ou du moins de prendre librement cette initiative. C’est aux chefs de projet d’en juger et comme tu le soulignes : le temps, c’est de l’argent.

by Joris on 11/09/2009 at 13:32. #

« # Pour le développement d’une application fenêtrée GTK ; »

Euh… bof :-/ C’est sans doute un des plus mauvais choix pour ce genre de chose, sauf à tenir absolument à utiliser du code existant.

Sans bon support du multithread, on va vite atteindre des limites dans les applis desktop. Python (au hasard… ;-) ) à coté ne souffre pas de ces limitations et permet un plus large choix de biblios graphiques (qt, wx, tk, gtk, etc…).

Et puis si PHP est critiqué c’est qu’il y a beaucoup à critiquer… et qu’à force de critiques ça finira bien par s’améliorer. Et oui, la librairie standard de PHP est un peu anarchique, et ça les développeurs qui utilisent PHP n’y peuvent rien.

by desfrenes on 11/09/2009 at 14:25. #

[...] I had over 23,000 visits and the busiest day was Friday, 11th September 2009 (the day when I posted Pourquoi critiquer autant PHP ? I wrote 89 articles within 10 categories with 102 keywords. There were 284 comments posted while [...]

by Two years of rand(0)-mies « rand(0) on 21/02/2011 at 16:24. #

Leave your comment

Not published