AFUP AFUP Day 2020 Baromètre Planète PHP

La parole est aux speakers : Thomas DUTRION

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 n'es pas un {framework} developpeur !

Quand on leur demande leur métier, beaucoup de développeurs et développeuses ont tendance à s'associer au framework X ou Y, souvent dev Symfony ou Laravel en ce moment. Cette tendance, conduite et amplifiée par les offres d'emploi et les différentes formations, est nuisible à notre profession. Être un bon développeur ou développeuse, c'est aussi accepter que la valeur que l'on crée n'est pas liée à notre outil, mais bien à nos connaissances et capacités. Dans cette présentation, nous reviendrons à la base, en parlant d'intéropérabilité et de développement framework agnostic. Quelles pratiques d'ingéniérie logicielle retrouve-t-on communément, comment implémenter les principes que vous connaissez ou que vous pouvez trouver dans la littérature à votre framework favori ? En se basant sur des exemples de Symfony et Laravel, nous allons parcourir différents exemples et voir que notre code métier peut très largement survivre notre framework ! Amateurs de Rapid Application Development, attention, ce talk peut vous donner des boutons !

Manufacture des Tabacs
15/05/2020
16:50-17:30

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 ?

Le speaker

Thomas DUTRION
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

En poursuivant votre navigation sur ce site, vous acceptez l’utilisation des cookies pour améliorer votre navigation. plus d'infos

1. Qu’est-ce qu’un cookie?

Un Cookie est un petit fichier texte enregistré sur votre terminal (ordinateur, tablette, smartphone, etc.), à l’occasion de la consultation d’un service en ligne grâce à votre logiciel de navigation. Il permet à son émetteur d’identifier le terminal dans lequel il est enregistré, pendant la durée de validité ou d’enregistrement du Cookie. Lors de la consultation de notre site Internet, des informations relatives à la navigation de votre terminal sont susceptibles d'être enregistrées dans ces fichiers dits "Cookies". Ces derniers sont installés sur votre terminal, sous réserve des choix que vous auriez exprimés concernant les Cookies et que vous pouvez modifier à tout moment.

2. A quoi servent les cookies émis sur notre site ?

Seul l’émetteur d’un cookie est susceptible de lire ou de modifier les informations qui y sont contenues.
Les cookies utilisés sur notre site permettent :

3. Vos choix concernant les cookies

Vous disposez de différents moyens pour gérer les cookies. Tout paramétrage que vous pouvez entreprendre sera susceptible de modifier votre navigation sur notre site et sur Internet en général et vos conditions d'accès à certains services de notre site nécessitant l'utilisation de cookies. Vous pouvez à tout moment exprimer et modifier vos souhaits en matière de cookies, par les moyens décrits ci-dessous. L'accord sur les cookies L'enregistrement d'un cookie dans un terminal est essentiellement subordonné à la volonté de l'utilisateur du terminal, que celui-ci peut exprimer et modifier à tout moment et gratuitement à travers les choix qui lui sont offerts par son logiciel de navigation. Si vous avez accepté dans votre logiciel de navigation l'enregistrement de cookies dans votre terminal, les cookies intégrés dans les pages et contenus que vous avez consultés pourront être stockés temporairement dans un espace dédié de votre terminal. Ils y seront lisibles uniquement par leur émetteur.

Le refus des cookies Si vous refusez l'enregistrement de cookies dans votre terminal, ou si vous supprimez ceux qui y sont enregistrés, vous ne pourrez plus bénéficier d'un certain nombre de fonctionnalités qui sont néanmoins nécessaires pour naviguer dans certains espaces de notre site. Tel serait le cas si vous tentiez d'accéder à votre compte ou à votre abonnement qui nécessite de vous identifier. Tel serait également le cas lorsque nous, ou nos prestataires, ne pourrions pas reconnaître, à des fins de compatibilité technique, le type de navigateur utilisé par votre terminal, ses paramètres de langue et d'affichage ou le pays depuis lequel votre terminal semble connecté à Internet. Le cas échéant, nous déclinons toute responsabilité pour les conséquences liées au fonctionnement dégradé de nos services résultant de l'impossibilité pour nous d'enregistrer ou de consulter les cookies nécessaires à leur fonctionnement et que vous auriez refusés ou supprimés. Les choix offerts par votre logiciel de navigation Vous pouvez configurer votre logiciel de navigation de manière à ce que des cookies soient enregistrés dans votre terminal ou, au contraire, qu'ils soient rejetés, soit systématiquement, soit selon leur émetteur. Vous pouvez également configurer votre logiciel de navigation de manière à ce que l'acceptation ou le refus des cookies vous soient proposés ponctuellement, avant qu'un cookie soit susceptible d'être enregistré dans votre terminal. Pour la gestion des cookies et de vos choix, la configuration de chaque navigateur est différente. Elle est décrite dans le menu d'aide de votre navigateur, qui vous permettra de savoir de quelle manière modifier vos souhaits en matière de cookies. Selon votre navigateur, consultez le lien ci-dessous pour configurer votre navigateur et refuser les cookies :