PHPPRO - Tag - equipe

Don't reinvent the wheel ... invent the car !

Olivier Hoareau — Sat, 20 Mar 2010 23:57:00 +0000

Vous avez déjà croisé des projets / équipes qui décident d'utiliser le dernier framework en vogue ? oui, certainement.
Par contre avez-vous déjà croisé des projets / équipes qui décident d'en changer (de framework) car ils se rendent compte que le choix n'est plus forcément pertinent ou le plus meilleur ? moi, non, pourtant c'est bien connu le la version parfaite d'un framework sur tous les sujets et ad vitam eternam n'existe pas...

J'entends souvent :

nous on fait du MVC
nous on fait du design pattern
nous on utilise des adapters
nous on utilise des couches d'abstraction
nous on utilise certains composant du framework X
...
nous <whatever the generic term you want here>

Mais quand on creuse, on se rend compte qu'il fallait plutôt entendre :

"nous notre application est fortement couplée au / motorisée par le framework X"
"nous on utilise l'implémentation MVC du framework X"
"nous on utilise certaines implémentations de certains designs patterns proposés par le framework X"
"nous on aimerait bien utiliser le composant XYZ du framework X mais on sait pas comment ca pourrait nous être utile concrètement"
"nous on comprend pas tout dans le framework X mais il parait que c'est bien alors on l'utilise"
"nous on utilise le mécanisme d'abstraction du composant W du framework X"
"nous on met notre code dans un fichier Controller.php en utilisant les helpers et les vues du framework X"
...
nous <whatever the framework-specific implementation you want here>

Et les 40 lignes de code dans la méthode indexAction() ca vous rappelle quelque chose ?
Et les X heures / jours / semaines passés à se demander quand et comment on va faire pour migrer tout notre code application de la version 1.5.3 du framework X vers la toute nouvelle version 2.0.0 qui déchire et qui n'est plus totalement compatible sur bien des aspects mais tout le monde dit qu'il faut l'utiliser, ca ne vous rappelle pas quelque chose ?
Et la complexité intrinsèque de l'architecture et design patterns des composants du framework X que vous vous "obligez" à utiliser parce que tout le monde dit que maintenant c'est comme et c'est pas autrement en PHP, ca ne vous rappelle pas quelque chose ? Vous êtes certainement comme moi, développeur, fier de montrer que je utiliser la nouvelle version du dernier framework à la mode sur mon projet. Mais pour les 10 autres projets sur lesquels mes collègues travaillent, tout le monde ne sera peut être pas aussi enthousiaste de perdre 1 semaine ou 2 semaine de développement pour réécrire tous les "controller" et retranscrire tous les "formulaires" avec le dernier composant à la mode...

Plus concrètement mon point de vue est le suivant :

"re-" développer ce que d'autres on déjà développé, rendu mature et éprouvé, c'est bof
les designs patterns c'est bien
les frameworks c'est (presque) bien aussi

mais :

utiliser un design pattern sans le comprendre c'est moins bien
utiliser un framework sans comprendre les "problématiques" sous-jacentes auquel il répond c'est encore moins bien (j'ai pas dit "c'est mal", mais j'aurais pu...)
insérer 5 (ou 10, 50 ou 100 ...) lignes de code "spécifique framework X" pour implémenter un composant XYZ du framework X sans le cloisonner en dehors de votre code applicatif / métier ... ca c'est mal !

Pourquoi être "trop / très" couplé avec un framework c'est mal ? (d'après moi)

"Moi, oui, je mélange les choux et les carottes"

Un framework c'est souvent technique, votre logique applicative elle est souvent plutôt métier / fonctionnelle, le framework évoluera il faudra faire un effort pour savoir quel ligne concerne le framework et quelle ligne concerne de la logique métier invariante, cela peut être long

"Moi, oui, j'ai peur de monter de version de framework"

Un framework c'est souvent imparfait, en perpétuel évolution (surtout les Open Source, pour notre grand bonheur), donc souvent 3 mois après avoir implémenté la dernière version, une nouvelle version sort et vous êtes tiraillé entre migrer au bout de 6-9 mois vers cette version ou ... tout réécrire votre application en v2 ! Pourquoi attendre 6-9 mois ? Pourquoi réécrire la logique métier de l'application alors qu'en 6-9 mois votre fonctionnel / métier n'a pas forcément évolué tant que ça, lui ?

"Moi, je suis certifié framework X, je sais bien l'utiliser, je connais tous les composants, et je développe toutes mes applis avec"

Et votre collègue aussi il connait aussi "parfaitement" ce truc si génial ? Et lui aussi il sait "bien" l'utiliser ? Et lui aussi il a compris tous les concepts complexes de patterns qui y sont implémentés ? Non ? Donc il a besoin de vous ? Oui ! Bravo, vous avez trouvé un moyen de ne pas vous faire virer, par contre pour ce qui est de la maintenabilité (i.e. par quelqu'un qui n'a pas vos connaissances), la simplicité (pour quelqu'un qui veut aller droit à la solution technique la plus simple pour répondre aux besoins) c'est peut être moins rose...

"Moi je fais des DAO et j'ai une couche d'abstraction de la base de données avec modélisation de mes tables en classe..."

Et si votre source de données changent et vous fusionnez 2 tables en une ou scinder 1 table en 2 ? Si vous décidez de stocker via l'appel de webservices plutôt que dans une base locale ? Si vous changez de moteur de base de données (mysql => oracle, sqlite => mysql, mysql => sql server...), vous êtes sûr que votre couche d'abstraction sera si parfaite que ça ? Nous c'est vrai, à vous ca ne vous arrivera pas tout ça...

"Moi, j'utilise a fond les composants du framework X, de toute façon il est bien fait, ca ne peut qu'être bon pour moi"

Pensez-vous sincèrement que ce soit la qualité du framework ou la qualité de "l'usage" que vous en avez qui garantira maintenabilité / évolutivité / robustesse / performance / ... ? Personnellement, je ne parierai pas QUE sur la qualité du framework...

Pour conclure, je dirais que les frameworks c'est bien, mais maîtriser l'usage que l'on a des frameworks et être conscient que l'ON DEVELOPPE DU CODE pour mettre en vie le framework c'est beaucoup mieux... De nos jours, il n'est plus question de "réinventer" la façon d'implémenter tel ou tel design pattern (i.e. "la roue / the wheel" dans mon analogie) mais plutôt d'"inventer" le code applicatif et la façon dont tout ça va se mettre en jeu pour rendre une application fonctionnelle ET UTILE (i.e. "la voiture / the car"), ne perdez pas de vue, que comme des ingrédients et ustensiles pour faire un gâteau en cuisine, un framework reste un socle / outil / matériel, mais la réussite finale du gâteau (i.e. de l'appli) dépend du cuisinier (le développeur) et de sa capacité à être rigoureux, organisé, méthododiques, homogène, rationnel...

Les frameworks, c'est bon ! mangez-en, mais sans que ça se voit !

Session "Oui ! PHP est industriel !" au forum PHP 2009 @Paris

Olivier Hoareau — Tue, 17 Nov 2009 11:33:00 +0000

Le forum PHP 2009 de Paris s'est déroulé la semaine dernière, je vous livre le support de session que nous avons utilisé avec Damien Seguy à l'occasion de la présentation de notre session sur l'industrialisation en PHP.

AFUP Forum PHP 2009 : Oui ! PHP est industriel !

View more presentations from PHPPRO.

Grâce à PHPTV, Vous pouvez aussi écouter le podcast de la session !

Que vous ayez participé à la session ou non, vos retours / remarques / critiques sont les bienvenues !

PHP : Une plateforme industrialisable au service de l'Agilité

Olivier Hoareau — Mon, 28 Sep 2009 19:51:00 +0100

Je publie sur slideshare une version refactorée d'une présentation draft que j'avais réalisé il y a quelques mois pour l'Université du S.I avant de préférer avec Damien Seguy une version plus light... Au programme, PHP et Agilité, encore et toujours ;)

PHP : Une Technologie Au Service De L'Agilité

View more presentations from PHPPRO.

Vu que je n'ai jamais joué cette présentation pour l'instant, vos critiques et remarques sont, encore et toujours, les bienvenus !

PS : c'est vraiment pas mal : [...], me suis bien éclaté aujourd'hui ;-)

Olivier Hoareau — Tue, 22 Sep 2009 18:14:00 +0100

Retours sur la satisfaction d'un développeur.

Récemment j'ai mis en place une pratique un peu particulière pour suivre des développeurs à distance et garder le contact : "La méthode du jour".
Le principe est simple, je leur demande de m'envoyer chaque soir par email un extrait du code développé dans la journée, une méthode de leur choix :

une méthode du code applicatif
une méthode de test
un fragment de méthode
...

L'idée est de faire en sorte, que le lendemain matin, ils aient un feedback extérieur sur leur développement de la veille. Par mes soins (ils pourraient l'envoyer à d'autres développeur d'une autre équipe, ca marcherait aussi pour cet aspect). Un autre aspect intéressant est que je garde le contact avec le code en ne regardant que les échantillons "sélectionnés" par l'équipe (un par jour ET par développeur tout de même).

Au delà de la revue de code technique, je peux capter les humeurs / ressentis / comportements, et proposer mon aide sur des sujets qui peuvent paraître moins triviaux :

isolement d'un développeur
sentiment de non confiance en soi
divergence de pratiques
baisse de la vélocité
...

Je voulais vous faire partager cette pratique qui m'est bénéfique, et qui doit l'être à mes développeurs ;)

La petite citation du jour d'un de mes développeurs illustre bien cet aspect "behind the scene" que l'on peut évaluer au delà de la réalité du code technique :

PS : c'est vraiment pas mal: ..., me suis bien éclaté aujourd'hui :-)

Et vous avez vous d'autres pratiques pour "faire" parler vos développeurs et/ou entretenir des relations de suivi et d'échange à distance avec eux ?

Université du S.I 2009 : Oui ! PHP est industriel !

Olivier Hoareau — Thu, 09 Apr 2009 14:55:00 +0100

Vous connaissez l'Université du Système d'Information ? ou USI !

Organisé par OCTO Technology (Paris), ce séminaire mélange Geek et Boss en proposant 4 thématiques de conférences :

Gouvernance
Technologies
Méthodologies
Usabilité

Côté Technologies, a côté de Java, .NET, Grails, Ruby..., nous aurons cette année ... PHP !

Lors de la prochaine édition, 1 et 2 juillet 2009 à Paris, nous essaierons avec Damien Seguy (Alterway/Nexen) de démontrer que PHP est aujourd'hui une technologie / plateforme / environnement industriel.
Parmi les sujets abordés dans notre session :

Frameworks PHP professionnels
Intégration continue
Environnement de développement
Outillage
Test Driven Development
Tests fonctionnels automatisables
...

Plus d'info sur l'évènement ? Allez voir sur le site !

Venez nombreux !

Les 10 commandements du développeur PHP en entreprise : ma proposition

Olivier Hoareau — Mon, 10 Nov 2008 19:22:00 +0000

Si PHP développeur tu es, ces 10 commandements tu respecteras : ...

Si PHP développeur tu es, ces 10 commandements tu respecteras :

Faire simple ET propre
Développer en TDD : le test d’abord, le code ensuite
Committer sur barre verte (tests en succès)
Respecter des conventions de codage connus en dehors de l'entreprise
Développer 1 fois, Réutiliser plusieurs fois
Tester unitairement toutes les fonctionnalités du coeur de l'application
Utiliser les comparaisons de valeurs ET de types (===, !==)
Réaliser systématiquement des implémentation mocks (bouchons)
Ne pas dépasser plus de 80 lignes aérées et commentées pour une fonction/méthode
Always Have Fun !

Qu'en pensez-vous ?

(TDD = Test Driven Development)

Scrinch : Outil de gestion de projet agile

Olivier Hoareau — Wed, 08 Oct 2008 15:46:00 +0100

Bonjour à tous amis Agilistes,

Que pensez-vous de cette outils pour gérer les projets Agile : ...

Bonjour à tous amis Agilistes,

Que pensez-vous de cet outil pour gérer les projets Agile :

http://social.hortis.ch/2008/09/25/16-octobre-08-mardi-gras-sur-scrinch-outil-de-gestion-de-projet-agile/

Ca ne remplace pas nos bons vieux post-it sur les murs mais cela peut-il avoir une pertinence à vos yeux pour le Product Owner et pour l'équipe.

A vos plumes