[:fr]La parole est aux speakers : Frédéric Bouchery (AFUP Day 2019 Rennes)[:]

Publié le

[:fr]Jusqu’à l’AFUP Day 2019 Lyon, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

PHP Pragmatic Development

On ne va pas se mentir, DDD c'est bien, mais pas franchement facile à appréhender quand on débute. Et c'est bien là tout le problème : il n'y aurait que des développeurs seniors et des architectes sur nos projets, tout irait pour le mieux. Quand on parle d'expérience développeur (DX), il est donc nécessaire de prendre en considération ces jeunes inexpérimentés qui peuvent vite se perdre et enrayer notre belle machinerie.

Héritage, traits, injection de dépendances, agrégation, programmation évènementielle, programmation orienté aspect, etc. faisons le point sur les architectures actuelles en PHP et retrouvons un peu de pragmatisme pour le bien de nos projets et de notre santé mentale.

La Fabrique
17/05/2019
17:05-17:45

De nos jours des architectures comme DDD, CQRS et l’event sourcing sont à la mode. Pour toi, ces patterns de développements permettent-ils réellement d’avoir un gain sur les applicatifs développés ?

CQRS est un pattern d’architecture qui mérite en effet que l’on s’y attarde, car il permet vraiment de découpler des éléments qui sont bien trop souvent mélangés. Il force les développeurs et développeuses à penser différemment et à rendre son application beaucoup plus scalable. Couplé à l’event sourcing, cela permet, entre autres, d’offrir une bonne capacité d’évolution, en permettant plus facilement la reprise de données, qui est toujours une galère quand on veut faire évoluer son modèle. DDD, qui n’est pas une architecture, mais une méthode de conception, vient normalement faciliter le travail dans une architecture CQRS. Le problème dans cette architecture, c’est qu’elle est difficilement mélangeable avec des architectures plus classiques. De plus, si un développeur ou développeuse maîtrise mal certains concepts, il risque facilement de gripper la machine et au final d’en faire une application beaucoup plus difficile à faire évoluer que ce que promettait l’approche initiale. CQRS, c’est génial, ça permet d’avoir des applications plus évolutives et performantes, mais elle peut introduire de la complexité qui nécessite une plus grande expérience si on ne veut pas que le château s’écroule.

Ta conférence sera axée sur le pragmatisme : est-ce qu’à vouloir être trop pragmatique, la qualité du code ne finit pas par en pâtir ?

Être très rigide ne garantit pas d’avoir un code de qualité non plus, et mon expérience montre que c’est même le contraire en raison du phénomène d’essoufflement des développeuses et développeurs.
Être pragmatique dans son approche du développement ne veut pas dire faire n’importe quoi. Développer de façon pragmatique, c’est prendre en considération les bonnes pratiques, l’état de l’art, mais également un autre facteur à mon sens bien trop négligé : l’être humain avec son expérience, ses formations, ses motivations, sa capacité d’attention, sa santé, ses handicaps, etc. Ce facteur humain doit même être privilégié au détriment de certaines bonnes pratiques, qui, je le rappelle, ne sont pas des lois immuables.
Ça nécessite aussi une bonne capacité à voir l’avenir en s’appuyant sur le passé, et aussi à savoir-faire des paris gagnants. En effet, on a tendance, bien trop souvent, à faire des paris perdants : je décide de mettre en place une abstraction de BDD au cas où on serait amené à changer de moteur. Bien trop souvent, on ne change jamais de moteur, du coup, on a fait un pari perdant : on a augmenté la complexité et on s’est coupé de certaines capacités … pour rien. Dans un pari gagnant, je considère qu’on ne migrera pas, et donc on gagne du temps à ne pas le faire. Le jour où il faut vraiment changer de moteur, je devrai tout refaire, tant pis !
Le pragmatisme en développement s’appuie beaucoup aussi sur la simplicité et l’expérience développeur. Mais attention, simplicité ne veut pas dire simpliste. Un code simple sera toujours de meilleure qualité qu’un code complexe que personne ne comprend et ne peut reprendre. Comme le dit mon CTO : le code le plus efficace, c’est celui que l’on n’écrit pas.
Faire simple, c’est garder en tête que les développeuses et développeurs, qui reprendront notre code plus tard, sont des psychopathes sanguinaires qui connaissent notre adresse.

Cela sera ton neuvième talk à une conférence nationale de l’AFUP : aurais-tu des conseils à donner à une personne souhaitant se lancer dans l’exercice ?

Comme dirait le grand Jean-Claude Dusse : oublie que t’as aucune chance, vas-y fonce ! On sait jamais, sur un malentendu ça peut marcher !
Je pense que l’on se pose des barrières qui n’existent pas. On pense que l’on a aucune chance, que l’on n’a rien d’intéressant à raconter et que l’on va se ridiculiser. C’est faux ! On a toujours des choses à raconter. On peut très bien faire une conférence sur la fonction « echo » de PHP. En creusant, il y a beaucoup d’éléments à apporter. Personnellement, je prends beaucoup de plaisir à construire mes présentations, car j’apprends plein de nouvelles choses. C’est d’ailleurs ma motivation première de faire des conférences : apprendre et approfondir un sujet.
Par contre, on ne va pas se mentir, faire une conférence technique à un événement national, c’est s’adresser à des professionnels qui s’attendent à un certain niveau de qualité en regard de ce qu’ils ont payé. Ils ne vont pas tous être bienveillants. Vous devez donc impérativement répéter votre présentation un grand nombre de fois, et il est INDISPENSABLE de le faire devant des gens au moins 2 fois. Vous pouvez également vous filmer, c’est souvent assez révélateur.
Un point très important, votre auditoire doit repartir avec quelque chose, un « call to action » : quand il sort, il doit avoir envie de mettre en place ce que vous avez présenté, remettre en cause ses certitudes, re-écrire tout son code, péter son architecture CRUD, etc.

Une conférence présentée par

Frédéric BOUCHERY
Frédéric BOUCHERY
Team Leader et architecte pour le groupe Figaro-CCMBenchmark, évangéliste PHP qu'il pratique depuis 1999, troll et plongeur subaquatique. Papa des apéroPHP et de 3 enfants. Développeur depuis 1983 en basic, assembleur, C, C++, Pascal, Delphi, Java, ASP, Javascript, PHP, et certainement d'autres. Techno-curieux, sciences addict, coach TEDx junior, adepte de la licorne rose invisible et brasseur amateur. En résumé : tellement de choses à raconter, qu'il ne faut pas lui donner la parole, il risque de ne pas vous la rendre !

Autres interviews

[:]