PHPPRO

Commentaires récents

• jpauli:

  Ah oui je confirme, ne jamais utiliser Exception car PHPUnit lui même les attrape.
  De manière générale utiliser Exception n'est pas correct de toute manière ;-)

  $this->setExpectedException('MonException'); est aussi possible depuis un test.

• stopher:

  Il suffisait d'y penser , merci pour cette info :-)

• Gab:

  Pour les tests d'IHM: selenium
  Pour les session, perso je fais ça avec un petit curl en ligne de commande. Basic, mais aide parfois

• Hugo:

  1/ Ok !
  2/ Ok mais ça c'est de l'utopie ^^
  3/ Ok mais je préfère le commit atomique à chaque modification mineure
  4/ Ok !
  5/ Ok mais pas toujours faisable. La capitalisation du code n'est pas toujours possible en fonction des spécificités de chaque projet.
  6/ Tests fonctionnels ou unitaires ? Dans l'idéal il faudrait les deux :)
  7/ Ok !
  8/ Tu entends quoi par là ?
  9/ 80 c'est presque trop. Dans la plupart des cas, on peut s'en tirer avec une trentaine / cinquantaine de lignes.
  10/ Toujours :)

  Tu as oublié un commandement important :

  11/ Les commentaires PHPDoc tu utiliseras et ton code, intelligemment et efficacement, tu commenteras.

• Bast:

  s/du développeur PHP/du développeur/

• ED.:

  Pareil que Hugo, j'ai tendance à préférer les commits atomique.

  1° C'est plus facile à "revert"
  2° Ca oblige le développeur à travailler sur des micro blocs testés

• Gab:

  Disons que c'est des bonnes pratiques pour tout codeur en général, pas spécialement PHP (du coup ok avec Bast: s/du développeur PHP/du développeur/ )
  et c'est un peu trop orienté TDD: après tout, on est pas OBLIGE d'en faire, non?

• Olivier Hoareau:

  @Gab : on est pas obligé de faire du TDD, par contre les tests unitaires c'est quand même un incontournable si tu veux développer de la qualité. TDD t'apporte la rigueur, la systématisation, la démarche, le cadre, l'assurance, la sérennité... ce serait dommage de passer à côté, non ? ;)

• Gab:

  Ca fait un paquet de temps que je cherchais ce qui me dérangeait dans le TDD, et j'ai enfin trouvé. Pas que je le refuse complètement, mais un truc me turlupinait, et j'ai mis le doigts dessus: quand je développe, j'aime bien tester plein de trucs (méthodes différentes pour faire la même chose). Récemment, par exemple, j'ai utilisé memcache pour cacher mes pages, puis APC, puis re-memcache, et là je mets des smarty dedans (d'où plus besoin de memcache).
  Or, si je passe mon temps à faire du test, je vais tester un truc qui en fait va disparaître au gré de mes idées, d'où frustration et perte de temps.
  Où est la faille?

• Maxence:

  Tu ne veux pas faire une usine à gaz, mais tu t'embarques avec phing, phar et un fichier de config. XML.
  OK, tu n'as qu'un seul script PHP à maintenir, mais par contre tu te retrouves avec X fichiers de config. XML.
  Je pense qu'un script PHP pour chaque couple application/environnement serait une solution plus simple et donc plus efficace.

• Olivier Hoareau:

  Effectivement on aurait pu se passer de Phar et Phing en ayant par exemple 1 fichier de script générique, n fichiers de configuration. Ca m'embête vis a vis du processus de livraison pour mes équipes de production, mais c'est tout a fait faisable et pertinent.

  Par contre, faire 1 script spécifique par couple application/environnement, ca oblige à dupliquer la partie commune (affichage du résultats, code des tests de vérifications...) ce qui multiplie les erreurs possibles et rend plus difficile la maintenance. J'avoue cependant que c'est souvent ce que l'on rencontre dans les projets, car ca reste la solution la plus simple.
  Par contre, qui/quoi garantit que ton / tes scripts de vérification ne contiennent pas d'erreurs et qu'il te dise que la connexion mysql testée est en succès alors que c'est faux ? Il peut être nécessaire d'ajouter des tests unitaires pour vérifier que les tests de santé que tu réalises sont bien implémentés et fonctionnent tel que prévu. Si tu as plusieurs scripts avec du code dupliqué, tu auras des tests dupliqués aussi, ce qui n'est pas optimal et une vraie contrainte pour les développeurs...

  Il existe donc plusieurs méthodes, à choisir en fonction des besoins et des contraintes. De mon côté, tous les développements PHP sont accompagnés de tests unitaires cela à donc un impact sur l'architecture du code et notamment la mutualisation des méthodes/fonctions. D'autre part, j'évolue déjà dans un environnement Phing, la cout de mise en oeuvre est donc limité pour ma part.

  En tout cas merci pour ton retour qui est une critique très intéressante !

   

• Laurentj:

  Aller, j'enfonce le clou : tu dis que le script ne doit pas dépendre d'une bibliothèque. Mais il faut avoir installé l'extension phar sur toutes les becanes pour que ta solution fonctionne !

  ;-)

• Olivier Hoareau:

  De mémoire (à vérifier), un phar est exécutable par PHP même si l'extension Phar n'est pas activé (c'est un des intérêts). Exemple : quand tu installes PHP sur ta machine en local (par exemple sous windows), tu peut ajouter le support de Pear, pour cela tu dois exécuter le fichier go-pear.phar (de mémoire encore) qui fonctionne même si ton installation de php est standard (je ne crois pas qu'avant la version 5.3 l'extension phar soit activée par défaut).

  Depuis la 5.3, l'extension phar en native (de mémoire encore).

  Je pense donc que ca ne pose pas de problème, mais dès que j'ai 5 minutes je teste, si ca ne marche pas je vous le dis.

  Dans l'hypothèse ou ca ne fonctionnerait pas, ton script serait en erreur (il ne se lancerait pas), et tu le verrais tout de suite à son exécution, ce n'est donc pas une erreur silencieuse, et tu peux y remédier tout de suite. Le niveau de criticité me semble donc assez bas à partir du moment ou tu peux ajouter des extensions sur le serveur en fonction des besoins.

  Il est probable, bien que l'extension phar ne soit pas nécessaire pour exécuter un phar, que les extensions de compression le soit tu as compressé ton phar (à vérifier). Mais je ne vois pas l'intérêt de compresser le phar dans notre cas.

• desfrenes:

  Je ne pensais pas qu'en 2009 on pouvait encore se poser cette question. La réponse est assez évidente il me semble.

• orouk:

  Superbe analyse.
  Voilà enfin les bonnes questions qui sont posées.
  Pas la POO pour la POO. Autrement dit tous les Framework ne se valent pas selon mes besoins/projet/compétences/tps mise en oeuvre.

  On peut facilement imaginer utiliser partiellement un framework pour la partie qui nous apporte réellement de la valeur ajoutée. Les modules trop lourds du framework (du point de vue projet) peuvent alors être remplacé par une méthodologie maison potentiellement avec une partie procédurale (pas de tabous) en plus de la POO bien sur inévitable.
  Il faut donc privilégier les framework modulaires

• Sky:

  Les bonnes questions sont posées.
  Je développe plutôt en procédurale, mais depuis quelques temps je passe de plus en plus au POO. J'utilise un Framework POO : Kohana. (une base de Code Igniter, mais uniquement PHP 5 et Objet). Si on souhaite suivre l'évolution de PHP, resté en 100% procédurale revient a une limitation assès déconcertante.

• Cédric:

  Je suis en train d'essayer, mais après avoir installé PHPUnitLaucher et les outils de dev Java, "Run As... Junit test" m'ouvre la console pour me dire "May be port 8888 in used, try another". Ou parfois il ne dit rien.

  J'avoue que je ne sais pas quoi passer à -DphpunitArgs...

• Olivier Hoareau:

  @Cédric: je t'invite à ouvrir un ticket sur http://code.google.com/p/phpunit4eclipse/issues/list, ou à contacter Bertrand Paquet le développeur "bertrand point paquet at gmail point com"

• Tom:

  Heu ... il manque un truc (d'après moi très très important..), à propos des performances?

  Tous mes tests montrent bien que 100% procédure est presque 10fois plus rapide, moins de RAM... que la POO... Et en plus je trouve ça super con de finalement tendre vers la syntaxe Java alors que Php est la base un truc simple!

• Olivier Hoareau:

  @Tom: Bien entendu tu as raison le sujet de la performance est un sujet important qui montre souvent des différences entre l'usage procédural et la programmation objet. Cependant, j'ai l'impression que c'est beaucoup plus lié aux pratiques qu'à la mécanique interne, personnellement j'ai déjà vu des applis procédurale moins véloce que des applis utilisant le paradigme objet, cela dépend plutôt de l'architecture du code et de la façon de le charger. Ce qui est sûr cependant c'est que la programmation objet impose de nombreux artefacts complémentaires pour maîtriser la performance : gestion de l'autoloading, mise en cache, singleton, découpage en couche...

  @all: En complément, je pourrais donner un retour d'expérience personnel : je me sers souvent du procédural pour "introduire" PHP chez mes clients novices, grâce à sa simplicité (syntaxe, algorithmique) cela permet petit à petit au client de se faire la main, et j'introduit dans un second temps la programmation objet, quand cela devient possible.

• Nick:

  Malheureusement, la POO n'est pas accessible à tous.
  Moi le premier, je n'arrive pas à appréhender la POO alors que le procédural ne me pose pas de souci de compréhension.

  Mais développer n'est pas mon métier, juste un petit hobby pour réaliser de petits sites :)