PHPPRO

Commentaires récents

• 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?

• JP:

  j'aime bien cette idée de revue partielle de code, je suis cependant un peu réticent à l'idée de laisser le développeur choisir quel fragment de code sélectionner, craignant un peu la dissimulation du code "baclé" et l'envoi d'un code nettoyé, surtout si la personne relisant ce code est un n+1... Je préfère l'idée d'un envoi d'une liste des fonctionnalités développées et une revue de code "au hasard" ou d'instinct sur les fonctionnalités critiques.

  L'idée de la revue croisée est une bonne alternative, (j'en avais discuté avec Damien Seguy lors d'une formation), bien encadrée, elle permet de créer une émulsion entre les développeurs.

• jacko972:

  Bonjour,

  j'ai trouvé le slide excellent. cela correspond pile poil à ce que j'aimerai mettre en place dans mon entreprise.
  ce n'est pas facile mais j'y crois dur comme fer.
  est-ce que tu as quelques conseils sur la manière de procéder ?
  merci d'avances

• Olivier Hoareau:

  @jacko972: envoie moi un email sur contact at phppro point fr en me décrivant ton contexte, tes problématiques et tes questions