mardi 4 décembre 2012

freeblogware.org devient gdelamarre.com

J'ai changé aujourd'hui le nom de domaine associé à ce blog.

Le nom originel, freeblogware, reflétait une intention (créer un moteur de blog) qui n'a jamais été réalisée, et depuis ... quelques années maintenant, il me paraissait toujours plus ridicule. Simplement, je ne trouvais pas autre chose.

Pour finir, j'ai choisi la simplicité, et accordé le nom du blog à celui de la plupart de mes comptes en lignes (Twitter, GTalk, SlideShare et quelques centaines d'autres). Faute d'être créatif, ce nouveau domaine assure au moins un peu de cohérence et peut-être plus de lisibilité dans mes communications :)

Debrief PHP Tour Nantes 2012


Me voilà dans le train*, enfin en route pour retourner chez moi. Je dis "enfin", mais d'un autre côté, je dois dire que je n'étais pas plus pressé que ça de quitter ce "petit monde" du PHP français francophone. 

Cette édition a offert aux visiteurs toutes les qualités que l'on connaît aux événements organisés par l'AFUP : une logistique impeccable, des membres stables qui assurent la continuité, et de nouvelles têtes qui viennent apporter de nouvelles perspectives, toujours bienvenues pour assurer la vitalité de l'association et de son action.

Les promesses du programme ont été tenues, comme à l'habitude ! Les présentations ont couvert des sujets variés, tant techniques que métiers (et pour une fois, nous parlons de notre métier, celui du développement, et plus généralement de l'IT). 

La récente sortie de Zend Framework 2 (Septembre 2012) a motivé Matthew Weier O'Phiney (lead développeur du projet) et Zeev Suraski (CTO de Zend Technologies) a faire le trajet depuis, respectivement, les Etats-Unis et Israël pour venir présenter au public les dernières évolutions de leurs solutions. Ce qui confirme, il serait dommage de ne pas le souligner, le sérieux de l'image de l'AFUP, de ses membres et des visiteurs des événements qu'elle organise aux yeux des acteurs majeurs du techno-système PHP.

Il serait bien sûr trop long de citer tout le monde - le site du PHP Tour vous permettra de consulter a posteriori le programme, et une recherche sur Twitter (#phptour) vous donnera accès aux nombreux commentaires réalisés en direct des différentes sessions.

Je tenais cependant à renouveler mes remerciements aux nombreux visiteurs qui sont venus assister à la conférence que j'ai présentée avec mon collègue Christophe Massin sur le thème de la montée en compétence des développeurs et des équipes. La planification d'une seconde session de cette conférence pour répondre à l'intérêt porté par les visiteurs sur ce thème nous démontre la pertinence de notre démarche professionnelle, et nous ne pouvons que nous en réjouir. Pour ceux qui n'ont pas pu se rendre au PHP Tour, nous avons mis en ligne sur Slide Share une version plus complète des slides.

Enfin, merci à tous les bénévoles de l'AFUP pour leur efficacité dans l'organisation de l'événement, leur accueil et leur "dévouement à la cause" ;) N'oublions pas d'ailleurs de mentionner la nouvelle mouture du site aperophp.net qui a été dévoilée durant le PHP Tour !

Rendez-vous est pris en Juin pour le prochain Forum PHP à Paris !

* évidemment, j'ai publié ce billet quelques jours après sa rédaction, faute de wifi dans le train :(

lundi 1 octobre 2012

PHP Tour 2012 à Nantes : programme en ligne !

Ce rapide billet pour signaler la publication du programme complet du PHP Tour 2012 qui se déroulera à Nantes les 29 et 30 Novembre 2012.

Outre que j'ai le plaisir (et le privilège) d'avoir été sélectionné pour co-présenter, avec mon collègue Christophe Massin, une conférence sur le thème de la montée en compétence des équipes internes, je me réjouis de constater que les conférences liées aux meilleures pratiques (intégration continue, tests unitaires, revues de code, etc.) seront largement représentées, en plus bien sûr de présentations sur le thème principal de cette édition, l'Open Data.

Mais je préfère vous laisser vous faire une idée par vous même sur le site officiel du PHP Tour.

Juste un dernier mot pour rappeler que pour la troisième fois consécutive, VA Consulting est sponsor des événements d'envergure nationale et internationale organisé par l'AFUP, que je remercie au passage pour tous ces efforts déployés pour favoriser la diffusion et le soutien du technosystème PHP !

mardi 10 juillet 2012

Gérer la hiérarchie dans une équipe de développement

Le débat initié récemment sur ce blog concernant la place du développeur a ouvert, au travers des commentaires, une question complémentaire à la fois plus vaste mais tout aussi importante : comment gérer l'évolution de carrière de chacun et, par extension, la hiérarchie dans une équipe ?

Il est à la mode de contester l'idée que la hiérarchie est nécessaire pour organiser une équipe. Je ne souscris pas à cette mode. Pour expliquer ma position, je veux d'abord revenir sur l'idée même de hiérarchie. Souvent, on considère que gravir les échelons de l'organisation d'une société donne droit à plus de "pouvoir" (notez les guillemets…). Cette idée, je la rejette également, tout en étant conscient que c'est effectivement comme cela que ça se passe, dans le faits, le plus souvent. 

De mon point de vue, appuyé par l'expérience (il ne s'agit pas là de pure spéculation intellectuelle, ni de posture éthique), la hiérarchie est nécessaire dans une équipe, car des décisions doivent être prises pour que les choses avancent. Et les décisions ne peuvent pas toujours être prises de manière collégiale. Aussi, je considère qu'évoluer dans une hiérarchie ne conduit pas à exercer plus de pouvoir, mais à assumer plus de responsabilités.

Certains m'ont objecté que pour être en mesure de faire face à ces responsabilités, il est indispensable d'avoir le contrôle de la situation, et donc le pouvoir, ne serait-ce que de prendre les décisions que l'on juge nécessaires pour mener à bien sa mission. Mon désaccord sur ce point est… subtil. Je pense que ce que l'on qualifie couramment de pouvoir devrait être considéré différemment : pour moi, c'est d'autorité dont on a besoin, laquelle doit être naturelle et légitime pour s'exercer pleinement. Je précise, pour éviter les quiproquos que j'entends autorité dans le sens de référence, et non pas dans son acception coercitive.

Le pouvoir confié arbitrairement à un membre de l'équipe, au prétexte qu'il serait directement lié à sa position dans l'organisation, ne sera pas, ou alors difficilement, accepté par ceux qui sont placés en-dessous (sur l'échelle des responsabilités). En effet, si l'on a pas confiance en la personne supposée assumer la responsabilité de la mission dans laquelle on est engagé, le risque est grand de contester voire même de refuser ses décisions. Avec des conséquences énormes sur le succès de l'équipe. 

Une autorité exercée sans légitimité provoque d'abord la frustration. Et la frustration dégrade considérablement la cohésion de l'équipe. Partant du principe que tous les membres de l'équipe ont une importance égale (chacun est indispensable à la réussite de tous), négliger sa cohésion est sans doute la pire erreur qu'un manager puisse commettre.

Aussi, au fur et à mesure que l'équipe s'agrandit, et que de nouvelles responsabilités sont identifiées, il faut trouver la bonne personne à qui confier cette responsabilité. Sur quelle critère ? Le plus important est sans doute la confiance. Pas seulement celle que le manager à dans le candidat qui lui semble être le mieux placé, mais aussi et surtout la confiance qu'ont ses collègues en ce candidat. C'est la confiance qui assurera la légitimité, et la légitimité qui à son tour assurera l'autorité. Et c'est enfin l'autorité qui garantira qu'une responsabilité sera prise en charge dans les meilleures conditions.

Parmi les dilemmes cornéliens auxquels le manager peut être confronté, il y a celui de l'ancienneté. Un membre de l'équipe doit-il se voir confier des responsabilités au seul titre de son ancienneté ? Théoriquement, non, bien sûr. Seules les compétences devraient guider une telle décision. Mais avec le risque là encore de frustrer ce membre de l'équipe si on lui préfère un plus jeune, ou un collègue arrivé après lui dans l'équipe. C'est ce qui explique que l'on préconise parfois de préférer solliciter quelqu'un de l'extérieur, dont on aura (un peu) moins de mal à expliquer qu'il est plus qualifié pour le job et que c'est pour ça qu'on le fait rejoindre l'équipe. 

Mais ça reste délicat bien sûr. Gare dans ce cas à ne pas démoraliser celui qu'on aura laissé "à sa place", car même si on fait souvent ce choix parce que la personne est à la place qui lui est la plus appropriée, il faut quand même trouver des motivations et un objectif personnel. Je reviendrai plus loin sur ce point.

L'ancienneté sur un poste donné, autrement dit l'expérience, ne garantit pas toujours la capacité à assumer des responsabilités autres. C'est là que je boucle la boucle avec le sujet précédent : l'expérience de développeur ne prépare en rien aux responsabilités de responsable de projet, c'est pourquoi on fait rarement évoluer les développeurs vers ce poste, ce qu'ils vivent pourtant le plus souvent comme une frustration.

L'erreur, dans cette situation, vient de ce que les responsabilités dans les équipes sont souvent mal identifiées. Il existe de nombreuses responsabilités que l'on peut dégager à l'intérieur de l'activité de développement, à commencer par l'architecture, mais aussi la qualité (via les tests), ou encore le design de bases de données. Chacune de ces responsabilités peut justifier la création d'un poste dédié, accompagné d'un package plus motivant que celui de "simple" développeur. Ce qui représente je pense le meilleur moyen de satisfaire le désir naturel de chacun de progresser professionnellement sans compromettre la cohésion de l'équipe.

Résumons-nous : la confiance mutuelle est la base de la cohésion de l'équipe. La confiance confère la légitimité nécessaire à exercer une autorité indispensable au bon fonctionnement d'une équipe. Et la confiance est toujours plus facile à accorder à quelqu'un dont on sait qu'il a une réelle maîtrise du sujet qui lui est confié. Alors je propose aux managers d'équipes IT d'être créatifs, de ne pas limiter leur hiérarchie à développeurs/chef de projet, de ne surtout pas mettre les premiers sous l'autorité du second, et de trouver à chacun la place dans la laquelle il se sentira respecté, car légitime, et qui répondra à ses aspirations en terme d'évolution de carrière. 

Pour cela, il ne faut pas hésiter à déléguer des responsabilités bien identifiées, et à créer des postes pour que chacun puisse exercer au mieux ses talents dans l'équipe. C'est ainsi que l'on pourra demander à quelqu'un de rester dans sa partie sans le frustrer. La position  de développeur ne doit pas être un fourre-tout de l'organigramme dans lequel on maintient tous les profils techniques dont on ne comprend pas toujours bien le job, et dont on pense parfois que la seule évolution de carrière consiste à migrer vers le management. 

Le développement est un métier technique, qui offre de multiples spécialisations, et c'est vers ça qu'il faut tendre : il faut former les collaborateurs sur des aspects plus précis du métier pour qu'ils puissent continuer de s'éclater dans leur job, de rendre d'inestimables services aux clients de leur société (pour le service) ou à leur employeur, et tout ça sans vivre la frustration de rester développeur pendant un temps infini, sans avancement ni de responsabilité ni de considération, et surtout, sans perspective !





jeudi 5 juillet 2012

Chef de projet, aboutissement de la carrière d'un développeur ?

Non, cent fois non !!!!!!!!!!!!!!!

Ceci est un cri du coeur... je viens de lire un billet très récent de Fred Hardy sur son blog mageekbox, lequel billet est une réflexion (amère oserais-je préciser) sur l'état du "marché" du développement. Une fois n'est pas coutume, je suis d'accord avec un certain nombre de constats de Frédéric, mais pas avec leur interprétation. Je reviendrai peut-être sur ces divergences ultérieurement, mais d'abord, je voudrais m'insurger contre cette idée parfaitement farfelue qui apparaît à plusieurs reprises dans les nombreux commentaires de ce billet : l'évolution normale, logique et surtout valorisante du statut de développeur serait celui de chef de projet.

Quelle aberration ! De ce que j'ai lu dans les commentaires, il semblerait que l'on fourre cette idée saugrenue dans la tête des futurs développeurs dès leur apprentissage... ceci expliquerait cela.

Ca fait des années (moi aussi je suis vieux ;)) que je m'interroge sur le fait que des développeurs qui ont encore du lait sur le clavier (2-3 ans d'expérience) proclament et même réclament la responsabilité de chef de projet. Je ne comprenais pas bien d'où leur venait cette idée absurde qu'il leur fallait accumuler de l'expérience sur un métier pour prétendre ensuite à en exercer un autre ! Comme si un serveur de restaurant devait naturellement devenir cuisinier. Non pas qu'il ne le puisse pas, mais simplement son expérience, même si elle est dans un domaine proche, n'a rigoureusement rien à voir.

Car la réalité est celle-ci : un développeur devenu chef de projet, ce n'est pas un développeur qui a réussi, mais au contraire, souvent, un développeur qui a échoué. Soit il s'est trompé en démarrant dans le développement (il n'était pas fait pour ce métier), soit il n'est pas parvenu à exercer convenablement ce métier (et donc il n'était définitivement pas fait pour). Et la confusion vient peut-être du fait que certains chefs de projet ont tendance à penser qu'ils sont également chefs des développeurs, en leur imposant des délais en dépit du bon sens, en faisant preuve d'une autorité artificielle et mal à propos, là où au contraire, ils devraient être à l'écoute et au service des développeurs pour maximiser les chances de succès des projets dont ils ont la responsabilité.

Un développeur produit du code. C'est le fondamental. Le corollaire, c'est qu'il conçoit des applications. Quand il est bon. Et ça, c'est être architecte. Et c'est ça l'aboutissement d'une carrière de développeur. En aucun cas chef de projet. D'autres possibilités s'offrent aux développeurs, comme consultant, formateur ou encore expert technique. Mais toujours pas chef de projet !

Pour résumer la situation, passer du développement à la gestion de projet, c'est une reconversion professionnelle. Rien d'autre. Ces deux métiers n'ont rien en commun, si ce n'est qu'ils évoluent en symbiose, l'un ayant besoin de l'autre. Mais les qualités requises pour exercer l'un et l'autre sont très différentes.

Un développeur doit avoir des qualités d'abstraction, de concentration, de conception, de persévérance  et de compréhension technique là où l'on attend d'un chef de projet qu'il soit parfaitement organisé, capable de communiquer tant avec un client qu'un développeur (c'est leur seul lien !) et de suivre méthodiquement l'évolution d'un projet pour s'assurer qu'elle concorde d'une part avec la planification et d'autre part avec les contraintes dictées soit par le métier, soit par le client, selon les circonstances.

Les développeurs doivent s'ôter de la tête que leur salut passe par l'abandon de la technique (chef de projet, c'est un job du côté management de la force, pas du côté technique) - ou alors, je le répète, c'est qu'ils se sont fourvoyés.

Pour finir, un mot sur les fantasmes salariaux... une société qui paierait à prix d'or un chef de projet et négligerait ses développeurs fait une grosse erreur. Il est beaucoup plus difficile de trouver sur le marché un développeur compétent (fut-il spécialisé sur tel ou tel framework plutôt que globalement expert sur un langage, ping @mageekguy ;)) qu'un chef de projet. D'ailleurs, certaines statistiques démontrent que développeurs et chefs de projet, pour une expérience identique, ont des salaires très similaires, et même à l'avantage du développeur au-delà d'une certaine expérience (d'après une étude du cabinet Hayes et de Cadremploi citée dans un numéro récent du magazine Programmez).

Je jette donc un pavé dans la marre : un développeur mal payé, c'est sans doute qu'il s'est mal vendu (par exemple au mauvais employeur), ou alors qu'il se surestime (désolé de rappeler que l'on est pas développeur senior après 3 ans d'expérience !). Le développement est un métier difficile, qui requiert de nombreuses qualités et beaucoup d'expérience, et quand les deux sont réunis, le profil a de la valeur sur le marché, beaucoup de valeur.

Si vous aimez la technique, poursuivez dans cette voie, les entreprises ont besoin de vous ! En cela je rejoins Frédéric, les bons profils de développeurs se raréfient, et pas parce que certains se sont spécialisés des frameworks, mais parce que trop renoncent ou changent de carrières pour s'orienter, souvent beaucoup trop tôt dans leur carrière, vers le management.

jeudi 14 juin 2012

Debrief du Forum PHP 2012

Je n'ai pas encore trouvé le temps de poster au sujet du Forum PHP de cette année, pour la simple raison que je suis rigoureusement débordé ! Pour cette même raison, je n'ai exceptionnellement pas pu consacrer au Forum autant de temps qu'à l'habitude, n'étant en capacité de m'y rendre que la deuxième journée.

Pour autant, j'ai pu constater qu'une fois encore l'organisation était à la hauteur, et ce bien qu'il n'y ait pas eu d'édition parisienne l'an passé, et que de fait le bureau actuel n'a pas été impliqué dans l'organisation de la précédente édition. Bien sûr, il y a eu la première édition du PHP Tour, qui fut un excellent baptême du feu pour les futurs membres titulaires du bureau, mais l'organisation de l'édition parisienne reste un peu plus problématique, notamment du fait d'un plus grand nombre de participants.

Une mention spéciale doit d'ailleurs être attribuée au choix du lieu, la Cité Universitaire Internationale, qui a accueilli le Forum pour la première fois, dans un cadre vraiment très agréable, nettement plus que ce que n'offre la Cité des Sciences, du moins à mon goût. Le faste quelque peu suranné de certaines salles offrait un contraste charmant avec la thématique du Forum.

Pour ce qui est du contenu des conférences, il me semble avoir été à la hauteur des précédentes éditions, pour autant que j'ai pu en juger (pas toujours facile en tant que membre de l'organisation de suivre les conférences, surtout quand on est là qu'une seule journée), les échos récoltés auprès des visiteurs confirment cependant largement cette impression.

Voilà, je n'ai malheureusement pas grand chose de plus à dire sur cette édition. Il me tarde donc d'être à Nantes pour le prochain PHP Tour, dont je rappelle que l'appel aux conférenciers est ouvert !

Pour finir, je tiens à remercier toute l'équipe pour ces bons moments chaque fois partagés lors des événements Afup, et à adresser mes félicitations au bureau en place pour le travail effectué, et ce dans des conditions qui n'auront pas été les plus simples de l'histoire du Forum (changement de lieu, une édition en moins, etc.). Bravo à tous !

mercredi 9 mai 2012

Zend Studio 9 à 100%... de CPU !

Une petite astuce technique, pour les utilisateurs de Zend Studio 9... vous l'aurez peut-être remarqué, il arrive que ZS9, malgré ses améliorations globales sur les performances, soit totalement handicapé à ce niveau par une consommation maximale de CPU. J'indique 100% dans le titre, mais en réalité, ça peut être beaucoup plus, puisque qu'il s'agit de 100% de chaque Core - nous avons des machines ici annonçant 400% d'occupation pour l'application Zend Studio...

Ou plutôt qui annonçaient, car nous avons trouvé sur le forum Zend une solution sous la forme d'un patch, en attendant qu'elle soit intégré dans une prochaine release. Voici donc la marche à suivre pour retrouver une ZS utilisable confortablement :


1) dans Studio, allez dans "Help" -> "install new software"
2) Renseignez le champ "Work with" avec l'url suivante : http://dl.dropbox.com/u/47740218/ZendStudioFeaturePatchesRepository
3) puis installez le seul patch proposé et redémarrez ZS...

And voilà :)

Normalement, l'usage CPU de Zend Studio devrait redescendre à quelques pourcents, autour de 2 chez moi hors traitements de fond naturellement.

Le post original, c'est par là !

Je précise que nous avons testé la manipulation sur des Mac (MacBook Pro et iMac) jusqu'à présent, et ce chaque fois avec succès... aucune certitude concernant les autres environnements, même si le patch n'est absolument pas spécifique à Mac OS X. Bonne chance :)

mercredi 7 mars 2012

PHP 5.4 : tirer un trait sur le passé ?


Le jeu de mot est un peu facile, je vous le concède. Mais comment ne pas saluer avec enthousiasme la sortie de PHP 5.4 (le 01/03/2012), et de sa plus grosse nouveauté : les traits. Ce concept peu connu dans l'univers PHP, mais qui ne l'est finalement guère plus dans d'autres langages courants va sans doute permettre de repenser en grande partie la conception objet avec PHP dans les mois à venir.

PHP 5.4, une version intermédiaire ou majeure ?

Avant de parler plus concrètement de l'implémentation des traits en PHP, sujet principal de ce billet, je voudrais revenir sur son titre. Si je considère PHP 5.4 comme une évolution majeure du langage, c'est parce qu'enfin des traits ont été tirés (bis repetita...) sur des caractéristiques archaïques du langage, de sorte que certaines des plus mauvaises habitudes de PHP ne sont plus seulement découragées, mais purement et simplement interdites. 

Si je ne devais prendre qu'un seul exemple, je citerais la suppression de la directive "register_globals" (et de son pendant programmatique import_request_variables()). Ce fameux register_globals, qui automatise l'intialisation de variables globales dans le script d'après les paramètres GET, POST, le contenu des cookies ou encore la session, tout ça dans le désordre le plus complet, est un symbole de la permissivité de PHP. Un symbole très négatif, car l'activation de cette fonctionnalité a conduit en son temps à de nombreux effets de bords et trous de sécurité (notamment combiné à d'autres mauvaises pratiques, comme l'utilisation de variables non-initialisées). Et pourtant, bien que découragé par sa désactivation par défaut depuis PHP 4.1 (!), l'usage du register_globals s'est maintenu pendant de (trop) nombreuses années.

Donc, la rénovation de PHP est en marche ! Il ne s'agit plus de bricoler par-dessus une carcasse vieillissante, mais de véritablement tailler dans la masse, d'amputer les parties malsaines pour améliorer substantiellement le langage.  
Pour résumer, PHP 5.4 est la bonne nouvelle que nous attendions depuis l'abandon du développement de PHP 6. Et même si la timide numérotation des deux dernières versions principales de PHP (5.3 et 5.4) ne le souligne pas suffisamment, ce sont bel et bien des versions majeures, et à ce titre devraient inciter les développeurs à réviser leurs habitudes et leur façon de faire, pour y intégrer ce que PHP leur offre désormais.

Et à ce propos, revenons justement aux traits ! Pour ceux qui parmi vous se sont intéressé tant soit peu au sujet et se sont peut-être interrogé sur l'intérêt concret de cette nouveauté, et pour les autres, ceux qui ne savaient pas que ça existait, et par conséquent ne savent probablement pas ce que c'est, je vous propose d'illustrer leur usage en examinant comment les traits auraient pu améliorer sensiblement la qualité du code de Zend Framework (v1) en se basant sur un exemple précis : la gestion d'options.

Mais avant d'étudier l'impact qu'aurait eu la disponibilité des traits sur le code de Zend Framework, il convient de revenir sur la définition même des traits. De quoi s'agit-il au juste ? Les traits peuvent dans une certaines mesure être comparés aux classes abstraites (impossibilité de les instancier, déclaration de propriétés, écriture de méthodes concrètes), mais avec deux différences notables : d'une part les traits ne sont pas hérités, mais simplement utilisés (mot-clé use), et d'autre part il est possible d'utiliser plusieurs traits dans une même classe concrète (comme si les classes abstraites autorisaient l'héritage multiple).

Pas d'héritage

Le fait que les traits ne nécessitent pas d'héritage permet de maintenir une hiérarchie d'objet qui ne soit pas détournée dans le simple but de la réutilisabilité du code. On décide de les utiliser sur une ou plusieurs classes selon que les méthodes qu'ils exposent seront utiles ou non à cette classe, indépendamment de la nature même des classes qui les utiliseront. De fait, il devient très facile de partager des fonctionnalités identiques entre plusieurs classes sans que celles-ci n'aient le moindre rapport du point de vue conceptuel. A ce titre, les traits sont aisément comparables aux helpers que l'on trouve dans certains frameworks.

Usage de multiples traits

L'absence de lien entre les traits et le mécanisme d'héritage a également facilité la possibilité d'agréger plusieurs traits sur une même classe. Pour PHP, les traits sont considérés comme des fragments de classes (méthodes et propriétés) dont on peut se servir comme briques de base pour fabriquer d'autres classes. De ce fait, le langage offre une grande liberté d'utilisation des méthodes exposées par les traits, en permettant notamment d'en modifier le nom et la visibilité au moment de l'intégration dans une classe concrète (aliasing - mot-clé as), et même de remplacer au run-time une méthode exposée par un trait par une autre méthode, issue d'un autre trait (mot-clé insteadof). 

Attention toutefois à cette souplesse, car si elle peut rendre de grands services, elle peut aussi conduire à des pratiques à la limite de l'obfuscation de code ! Je pense notamment à l'aliasing et à l'usage d'insteadof naturellement.

Comment traiter le cas de la gestion des options dans Zend Framework

De nombreux composants de Zend Framework proposent une gestion d'options, passées sous forme de tableau associatif à l'instanciation, pour faciliter la configuration des instances. Et je trouve ça fort pratique, à tel point qu'il m'arrive régulièrement de recommander de s'en inspirer pour des classes "maison". Mais en même temps, ça fait longtemps que je déplore la multiplicité d'implémentation de ces méthodes de gestion des options. En effet, de même que nous devons écrire nos propres méthode setOptions(), getOption(), etc. dans nos classes propriétaires, on peut constater non sans surprise qu'il existe pas moins de 33 implémentations d'une méthode qui s'appelle setOptions(), dont les principes et prototypes sont très proches sans être identiques.

L'usage d'un trait dans ce cas aurait apporté des bénéfices significatifs à deux populations :

 - aux développeurs du Zend Framework, en leur épargnant l'écriture de 32 méthodes superflues (sans parler des tests unitaires associés !), et en favorisant une certaine standardisation de la gestion d'options. Cette gestion étant réimplémentée dans chaque classe en ayant besoin, et pas toujours par le même contributeur, elle subit les influences des différents auteurs, avec au final des dérives assez importantes dans l'approche.

 - aux développeurs PHP utilisant Zend Framework dans leurs développements, car ils sont les premières victimes du manque de standardisation évoqué dans le point précédent. En effet, chaque fois que l'on trouve une méthode setOptions() dans Zend Framework, même si le rôle de ces différentes méthodes est similaire, il faudra relire la documentation, voire le code source, pour s'assurer du fonctionnement de chacune. Il ne sera pas possible de capitaliser sur la maîtrise "du mécanisme de gestion d'options de Zend Framework" car dans la réalité, il y a jusqu'à 33 mécanismes de gestion d'options différents !

Pour finir, voici en quelques lignes ce qui aurait changé dans le code de Zend Framework si l'on avait pu utiliser les traits au moment de son développement. L'exemple est volontairement basé sur une implémentation minimale de setOptions(), celle de Zend_Navigation_Page, pour des soucis de lisibilité :

Version "officielle" :

abstract class Zend_Navigation_Page extends Zend_Navigation_Container
  /* ... */
  public function setOptions(array $options)
      {
          foreach ($options as $key => $value) {
              $this->set($key, $value);
          }
          return $this;
      }
  /* ... */
}


Version "traitée" en PHP 5.4

trait OptionsHandler {
  public function setOptions(array $options)
      {
          foreach ($options as $key => $value) {
              $this->set($key, $value);
          }
          return $this;
      }
}

abstract class Zend_Navigation_Page extends Zend_Navigation_Container
    use OptionsHandler;
  /* ... */
}

Ces deux écritures sont strictement identiques du point de vue du run-time et de l'appel de la méthode setOptions(). Simplement, en déportant la méthode dans un trait, on lui a assuré une réutilisabilité totale.

Quand on sait qu'il y a des classes aussi différentes que Zend_Translate_Adapter, Zend_Validate_Ip ou encore Zend_Tag_Cloud qui chacune définit une méthode setOptions(), il et évident qu'il aurait été absurde d'un point de vue conceptuel de les faire dériver d'un ancêtre commun, ce qui explique le choix de réimplémenter systématiquement une méthode qui aurait pourtant pu être rendue générique et utilisable par tous ces composants. 

Les traits sont la seule solution à la fois élégante (un minimum de code), sûre (contrôles à la compilation) et performante (contrairement aux helpers, qui utilisent la méthode magique __call, singulièrement lente) de gérer ce problème de conception.

Il me semble que le temps est venu de tirer également un trait sur l'argument de ses détracteurs selon lequel PHP n'est pas pourvu d'un modèle objet digne de ce nom !