[:fr]La parole est aux speakers : Thomas DUTRION[:]

[:fr]Jusqu’à l’AFUP Day 2020, 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

Tu es impliqué dans l’organisation de conférences comme ScotlandPHP qui a lieu à Edinburgh. Pourrais-tu nous présenter l’événement et nous parler de son organisation ?

En effet, j’ai eu la chance de pouvoir passer quelques années en Écosse qui est un pays merveilleux et plein de ressources et de dynamisme. Assez rapidement, je me suis rapproché d’EdPUG (le groupe PHP d’Edinburgh), qui existait depuis longtemps, et j’ai pu profiter de cette mini-communauté de 7-8 personnes. Cherchant à m’impliquer et voyant le manque de besoin à Edinburgh, j’ai finalement trouvé ma place aux côtés de Mike qui a fondé GlasgowPHP, Danny qui a ensuite ouvert AberdeenPHP et enfin Iain qui a créé DundeePHP. Me déplaçant à chaque meetup sauf Aberdeen (plus difficile d’accès), j’ai pu rencontrer l’intégralité de la communauté, et notamment Paul, ancien organisateur de WhiskyWeb, avec qui nous avons décidé de lancer le projet de conférence.
Nous sommes maintenant 5 organisateurs pour la conférence, dont deux qui organisent Dundee et Aberdeen, et fêtons cette année notre 5ème édition (avec une surprise pour les attendees) !
Pour ceux qui ne connaissent pas la conférence, nous essayons de garder une petite taille (150-200 personnes), avec des speakers experts dans leur domaine et basé sur les retours d’expérience le plus possible. La petite taille permet une ambiance familiale et facilite le contact individuel avec les speakers et sponsors. Nous faisons aussi tous les ans un Ghost Tour dans Edinburgh pour permettre à tout le monde de découvrir cette ville magnifique !

Que penses-tu du PHP-FIG et de son impact (ou non) grâce aux PSR sur l’interopérabilité entre frameworks ?

Conceptuellement le PHP-FIG est pour moi une des meilleures choses dont la communauté PHP dispose. Permettre une interopérabilité, c’est donner la chance aux développeurs et développeuses de ne pas se coincer avec un code non maintenu, car le changement d’implémentation est sensé être grandement facilité. Les interfaces proposées permettent aussi de réduire en théorie les dépendances, par exemple si je veux faire du Symfony PSR-7 Bridge et du Guzzle dans le même projet, je vais pouvoir choisir de le faire soit avec la bibliothèque de Tobias Nyholm, soit avec Diactoros, soit avec les deux (ce qui serait dommage mais malheureusement courant car les développeurs·euses suivent des fois les documentations sans réfléchir…).
Pour moi, le rôle du développeur·euse n’est pas de coder, mais de comprendre une problématique métier et de la résoudre avec du code. Le PHP-FIG, tout comme les designs patterns, ou encore les principes de développement exposés dans la littérature, permettent de faciliter la vie des développeurs·euses en garantissant des implémentations standard, légères et ciblées qu’il faut ensuite composer en forme de solution au problème.
Ce que l’on peut cependant déplorer à l’heure actuelle, c’est le manque de support de certaines recommandations, pour des raisons diverses et variées allant de l’égo au marketing, en passant par des raisons tout à fait valables aussi. Je pense malheureusement que c’est dans l’essence du travail de ce groupe, car standardiser réduit le vendor locking. On ne peut qu’espérer que les gros projets, notamment Symfony et Laravel, reviennent un jour dans ce groupe. En tout cas bravo à tous les participants du PHP-FIG, tous les développeurs ne sont pas capable de supporter ce niveau de discussions politiques, je sais que personnellement je ne suis pas équipé pour !

Nous voyons parfois des membres de notre communauté dont les CVs sont rejetés par de nombreuses entreprises parce qu’ils ne mentionnent pas « symfony » ni « Laravel », malgré parfois plusieurs années d’expérience en PHP, avec ou sans framework « maison ». Est-ce que se présenter en tant que « développeur·euse {framework} » n’est pas aussi une façon de rassurer son intervenant, parfois insuffisamment au courant de nos métiers ?

Je vais essayer de ne pas spoiler ma présentation, mais en effet. Derrière ce titre provocateur, j’évoque ce point avant de me lancer dans le contenu technique, car c’est en effet une des bases de réflexion qui m’a amené sur ce sujet. De part mon travail de CTO, je rencontre pas mal de clients qui cherchent maintenant des ingénieurs logiciels, ou même des développeurs·euses PHP, mais c’est vrai essentiellement sur le marché parisien. Pour des profils plus junior, il est nécessaire d’avoir le nom d’au moins un framework. Cependant, je recommande de ne pas l’utiliser dans le titre, mais le mettre en valeur directement dans les premières lignes, pourquoi pas en commençant le CV avec les expériences directement si l’on en a suffisamment.
Personnellement je suis Zend Framework Certified Architect (Zend Framework 2), et je pense que si j’avais défini mon titre pendant un temps, j’aurais pû être développeur Zend Framework, ce qui me rendrait aujourd’hui invendable, et encore pire d’ici quelques années quand Laminas sera vraiment connu et que ZF aura fini de disparaître.
Je dirais donc comme d’habitude en informatique : « ça dépend du contexte ». Ceci étant, il faut en effet nécessairement avoir les noms des frameworks dans le CV, mais savoir aussi s’en distancer pour ne pas rester bloqué. Et bien sûr, faire la part des choses entre ce qui devrait être et ce qui est, mais ça j’en parle aussi dans ma présentation !

Il fut un temps où nous n’étions que de « simples » développeurs·euses. Maintenant, il y a des fronts, des backs, des mobiles, des leads, des architectes, des full-stacks. Pourquoi avons-nous tendance aujourd’hui à vouloir « étiqueter » les développeurs·euses et les considérer comme {Framework} dev, etc.

Je pense que pour répondre à cette question, il faut séparer différents groupes, et supprimer des légendes. Déjà, le développeur·euse fullstack qui maîtrise les domaines n’existe pas, simplement parce qu’il n’y a que 24h par jour. Dans les années 2000, tout était simple, et il était possible de faire de bout en bout car les technologies étaient moins nombreuses et plus simples, maintenant c’est un choix stratégique qui doit être fait par la direction de l’entreprise. Les besoins aussi ont changé, et personne n’aurait eu l’idée de faire certains gros systèmes actuels à l’époque (par exemple, les problèmes de notifications sur smartphone et de responsive design n’avaient pas raison d’être à ce moment là).
Deux stratégies s’opposent donc selon les besoins définis : soit on veut quelques personnes, fullstack, interchangeables, et lors du départ ou de l’ajout d’une personne la complexité de changement est mitigée par le reste de l’équipe en place, soit on choisit la spécialisation, et là les choses sont probablement livrées plus vite, mais les changements d’équipe sont plus complexe. Ajoutons à ça le très grand nombre de technologies, la difficulté pour certain·e·s à changer de syntaxe, et on se retrouve à privilégier la cohérence avec l’état de notre projet à l’instant T (production plus rapide à court terme) sur l’évolution du projet à long terme.
Pour moi, malgré le titre de ma conférence, les deux stratégies se valent encore une fois, tout dépend du contexte, et dans un contexte où le recrutement est difficile et où il faut que les fonctionnalités aient un time to market le plus court possible, je ne vois pas comment on pourrait ne pas « spécialiser » les offres. Je pense cependant qu’en dehors du cadre de recrutement, il ne faut pas être dogmatique et vraiment trouver des alternatives qui garantissent pérennité, rapidité, et faible coût, mais tout ça on en discutera ensemble sur place le 15 mai n’est-ce pas ?

Une conférence présentée par

Thomas DUTRION

Développeur web depuis environ 10 ans, Thomas s'est spécialisé dans la qualité de code et la programmation orientée objet. CTO chez Darkmira, consultant et développeur web freelance et enseignant en école d'informatique en alternance, Thomas s'intéresse désormais plus particulièrement aux implémentations dans des contextes professionnels et à la transmission de connaissances. Vous pourrez aussi le croiser à l'occasion des User Groups PHP en Écosse et de la conférence annuelle ScotlandPHP qu'il co-organise, du Darkmira Tour Brasil ou encore de l'antenne AFUP Lorraine dans lesquels il s'investit au quotidien.

Autres interviews

[:]