[:fr]La parole est aux speakers : Samuel Roze[:]

[:fr]Jusqu’au Forum PHP 2018, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils aborderont lors de leur conférence !

La conférence

Quels sont tes 3 design pattern préférés ?

Je dirais que cela dépend du contexte. Je n’ai pas de design pattern préféré, car ce sont juste des outils que j’utilise en fonction du cas d’utilisation plutôt qu’une liste de designs préférés. Ceci dit, celui que j’utilise le plus c’est le « Décorateur » que je trouve extrêmement puissant et très utile pour ajouter des fonctionnalités à un existant très simple. Typiquement sur une fonctionnalité de « retry » ou de logging: on pourrait l’ajouter à l’aide d’une boucle dans le code existant ou une ligne de code à de l’existant. C’est l’approche la plus simple mais elle n’est clairement pas réutilisable. À la place, on crée un décorateur qui permettrait d’avoir une fonctionnalité « plug-and-play », bien découplée et réutilisable.

Dans le titre de ta conférence tu indiques avoir commencé à aimer les design pattern. Est-ce que cela veut dire que tu ne les aimais pas avant ?

C’est plus ou moins vrai. Le contexte étant que j’ai commencé à développer avant d’aller dans une quelconque école d’informatique. Par conséquent, développer une application (web) n’était de mon point de vue pas très sorcier : pourquoi devrais-je apprendre tous ces aspects théoriques alors que franchement, mes applications marchent très bien sans? C’est un peu comme la philosophie à l’école: j’en voyais pas les applications pratiques.

Qu’est ce qui t’a fait basculer dans la recherche de pratiques « entreprises ready » ? Est-ce qu’il y a eu un déclencheur particulier ?

Je pense qu’il y a au moins 3 types de projets différents: les « expérimentations », que l’on « hack » de manière individuelle et restreinte pour tester une nouvelle technologie, les projets personnels longs termes qui visent à développer un nouveau “produit” et les longs termes qui impliquent un travail en équipe dans l’idée de concevoir un nouveau “concept/produit”, typiquement en entreprise.

Dans le premier cas, ça n’est pas un souci qu’il y ait du copier/coller un peu dans tous les sens et que notre application soit un sac de nœuds, on va probablement l’abandonner dans un coin. Mais si l’on décide de passer à l’étape suivante, dans le deuxième cas, c’est déjà plus contraignant : dans 3 mois, je ne me rappelle pas forcément où j’ai copié/collé ce bout de code pour le logging. Cette logique qui change le niveau d’erreur en fonction du contexte, ou je ne sais quoi d’autre… C’est là que l’on commence à avoir besoin de structure et donc d’utiliser des « patrons » de développement.

Le dernier cas est encore plus compliqué: pour faire en sorte qu’une équipe de développement puisse créer quelque chose sur le long terme il faut de la structure mais aussi une certaine modularité. Il faut pouvoir avoir des points d’extensions bien clairs à différents niveaux de l’application pour que tout le monde n’ait pas besoin d’avoir toute la base de code en tête pour être efficace dans son travail avec un très bon niveau de confiance. Et ces points d’extensions, c’est aussi les « patrons » de développement qui nous donneront de très bons indices!

Gandhi disait « Il ne faut pas souiller son patrimoine en multipliant les erreurs passées », c’est pour ça que je veux parler de ces « vieilles choses » pour que l’on puisse ne pas répéter ces vieilles erreurs de développement, et créer des applications maintenables, avec le moins de bugs possible et valables sur le long terme.

Une conférence présentée par

Samuel ROZE

Passionné par la création et l’innovation, Samuel travailles dans le startup studio Kamet à Londres pour aider chaque startup a donner le meilleur sur le plan technique. Core-team member de Symfony et ApiPlatform, createur de ContinuousPipe et Tolerance il est particulièrement impliqué dans l’open-source.

Autres interviews

[:]