[:fr]La parole est aux speakers : Frédéric Hardy (AFUP Day 2019 Lyon)[:]
[: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
Quel est le rapport entre TCP, UDP et la programmation orientée objet ?La programmation orientée objet doit permettre la conception de programmes fiables, évolutifs, facilement et rapidement, à l’aide de briques de code réutilisables. Pourtant, il est rare de pouvoir réutiliser du code orienté objet dans un contexte différent de celui pour lequel il a été conçu. De plus, parvenir à faire collaborer des objets qui ne sont pas issus du même écosystème n’est pas forcément trivial. Les programmes ont pris de l’embonpoint en termes de quantité de code et de complexité, et ils sont donc dans la plupart des cas très gourmands en ressources intellectuelles et techniques pour leur conception et leur mise en œuvre. De plus, ils deviennent souvent rapidement difficiles à faire évoluer, et leur fiabilité est incertaine et délicate à maintenir sur la durée, si tant est qu’elle soit suffisante dès leur première mise en production. Le constat est donc cruel : la programmation orientée n’a pas tenu ses promesses ! Quoique… l’Homme a une tendance naturelle à accuser l’outil plutôt que la façon dont il l’utilise. Et si nous laissions le bénéfice du doute à la programmation orientée objet durant cette conférence et que nous en profitions pour remettre en cause la façon dont nous l’appréhendons?? En réalisant un parallèle entre les protocoles de communication UDP et TCP à la base d’Internet et la façon dont nous écrivons du code orienté objet actuellement, j’espère vous faire douter de vous-même et à nouveau vous faire croire aux promesses d’Alan Kay ! |
SupInfo 17/05/2019 09:20-10:00 |
Ces dernières années on a souvent parlé de DDD, microservices ou d’architecture hexagonales. Tu vas nous parler de POO, TCP, UDP : des principes qui ont des dizaines d’années d’existence. Penses-tu que ce retour à la base est le meilleur moyen de garantir la simplicité ?
L’objectif derrière le fait de mettre en relation ces concepts est d’apporter un éclairage différent sur la POO par rapport aux pratiques actuelles.
En tant que développeurs, nous avons tous pour objectif de produire facilement et rapidement du code qui répond aux besoins des clients ou des utilisateurs et qui soit simple à maintenir et à faire évoluer.
Et pour y parvenir, nous avons à notre disposition tout un tas de recettes de cuisine ou d’outils qui s’appellent TDD, DDD, architecture hexagonale, design pattern, « if less programming », « object calisthenics », SOLID, et il y en a beaucoup d’autres.
Pourtant, malgré cette pléthore de bonnes pratiques et de recommandations, dans les faits, la plupart du temps, cet objectif n’est que partiellement atteint.
Un jour ou l’autre, nous sommes dans l’impossibilité de faire évoluer le code simplement, et nous sommes alors obligés de produire de la dette technique qu’il faudra rembourser à plus ou moins long terme.
Et comme la dette appelle la dette, elle va donc rendre plus compliquée la maintenance du code et rendre plus complexe son évolution.
Or, la POO a été conçue justement pour répondre à cette problématique, et non pour la provoquer.
C’est en cherchant à comprendre l’origine de ce paradoxe et en revenant à ces origines que je me suis aperçu que nous faisons de la POO, mais que nous ne la comprenons pas réellement.
Nous utilisons la POO pour développer des programmes qui sont une suite d’appel de fonction, alors qu’elle est censée permettre la conception d’un protocole de communication et de l’implémenter.
C’est pour illustrer cela que j’utilise TCP et UDP dans cette conférence, mais je n’en dirais pas plus maintenant.
Si vous voulez savoir exactement ce que j’entends par là et si ce « retour à la base » permet effectivement de « garantir la simplicité », il faudra venir à ma conférence 😉
Tu donnes souvent des formations à des développeuses et développeurs qui débutent dans le métier. Vois-tu un gap important entre ce que nous apprenons à l’école et ce qui est utile en entreprise, notamment au niveau de l’approche de la programmation (orientée objet) ? S’il y en a un comment pouvons nous le réduire ?
De mon point de vue, le gap est malheureusement très important entre ce qui est enseigné dans les écoles et ce qui est réellement utile en entreprise.
Je vais me répéter, mais ce qui est utile à une entreprise, c’est que les développeurs soient en mesure de produire rapidement et facilement du code qui répond aux besoins et qui puisse évoluer à moindre coût.
La POO est l’un des moyens de parvenir à ce résultat, surtout si elle est combinée avec tout ce qui est relatif à la qualité logicielle.
Or, l’un et l’autre ne sont pas enseignés correctement dans les écoles, voir même ne le sont pas du tout en ce qui concerne les tests ou l’industrialisation du code.
Les notions d’abstraction, d’encapsulation, de polymorphisme ou de messages semblent ne pas être abordées durant les cursus de formation.
Quant aux tests, ils sont au mieux la cinquième roue du carrosse puisqu’ils sont la plupart du temps abordés en fin de cursus, alors qu’ils devraient être la première chose enseignée et que tout le reste devrait en découler.
Alors, comment pouvons-nous réduire ce gap ?
C’est une excellente question.
À titre individuel, outre le fait que je suis toujours disponible pour apporter mon soutien à mes collègues sur ces thématiques lorsqu’ils en expriment l’envie, je fais des conférences et je produis du code que je libère ensuite sur GitHub pour illustrer mon propos.
Mon employeur, Norsys, a fait le choix d’envoyer en formation pendant 10 jours les développeurs qui viennent d’être embauchés, ce qui leur permet de revoir sur une forme ludique les fondamentaux du web, les concepts fondamentaux de la POO ainsi que ce qui est relatif à la qualité logicielle et à la sécurité des développements.
Nous semons des graines, et nous espérons les voir germer, pousser, grandir et semer à leur tour d’autres graines.
Cela fonctionne, mais à une très petite échelle parce que nos moyens sont forcément limités.
Pour démultiplier l’effet, il faudrait revoir en profondeur la façon dont la POO et la programmation en général sont enseignées, avec notamment une mise en avant de la qualité logicielle.
Malheureusement, je n’ai pas l’impression que nous en prenions le chemin et j’avoue ne pas avoir de solution qui permettrait de faire évoluer significativement la situation.
As-tu déjà eu l’occasion de t’initier à la programmation fonctionnelle? Si oui, lui trouves-tu des avantages comparé à la POO?
Tu ouvres la porte à un troll absolument énorme, parce que j’ai effectivement fait un peu de programmation fonctionnelle, mais je n’y ai pas accroché.
L’approche fonctionnelle semble être trop « mathématique » pour mon cerveau et je peine systématiquement lorsque je m’y essaie, d’autant que je n’ai pas l’utilité dans mon quotidien et que je ne la pratique donc pas régulièrement.
À contrario, je fais de la POO quasiment tous les jours depuis maintenant 19 ans.
Mon avis est donc par nature totalement biaisé et au risque de décevoir, je vais donc laisser le troll dehors en m’abstenant de faire une comparaison entre la programmation fonctionnelle et la POO.
Par contre, je peux dire que la plupart des développeurs que je connais qui font de la programmation fonctionnelle s’y sont mis parce que de leur point de vue, la POO n’a pas tenu ses promesses, puisqu’elle ne leur permettait pas de produire un code simple à maintenir et à faire évoluer.
Ils ont donc vu dans la programmation fonctionnelle une planche de salut.
Est-ce qu’ils ont fait le bon choix ? C’est à eux de répondre à cette question.
D’ailleurs, je trouverais très intéressant que quelqu’un propose un retour d’expérience à ce sujet lors d’un événement AFUP.
Une conférence présentée par
Frédéric HARDY |
Frédéric Hardy utilise PHP professionnellement depuis seize ans. Architecte logiciel, administrateur système, infographiste ergonome, consultant et formateur, il aime la programmation orientée objet, UNIX, les méthodes agiles, la facilitation graphique, les discussions intéressantes ainsi que la bonne cuisine et la bière. Il est de plus le créateur de atoum, un framework de test unitaire simple, moderne et intuitif pour PHP. |
Autres interviews
- [:fr]La parole est aux speakers : Aleth Gueguen (AFUP Day 2019 Rennes)[:]
- [:fr]La parole est aux speakers : Yvonnick Frin et Benjamin Cavy (AFUP Day 2019 Rennes)[:]
- [:fr]La parole est aux speakers : Kévin Dunglas (AFUP Day 2019 Lille)[:]
- [:fr]La parole est aux speakers : Sarah Haïm-Lubczanski (AFUP Day 2019 Rennes)[:]
- [:fr]La parole est aux speakers : Maxime Huran (AFUP Day 2019 Lille)[:]
- [:fr]La parole est aux speakers : Gaël Crispyn (AFUP Day 2019 Lille)[:]
- [:fr]La parole est aux speakers : Benoit Jacquemont (AFUP Day 2019 Rennes)[:]
- [:fr]La parole est aux speakers : Rodrigue Villetard (AFUP Day 2019 Lille)[:]
- [:fr]La parole est aux speakers : Lætitia Avrot (AFUP Day 2019 Lyon)[:]
- [:fr]La parole est aux speakers : Fabien Féat (AFUP Day 2019 Rennes)[:]
- [:fr]La parole est aux speakers : Samuel Roze (AFUP Day 2019 Lille)[:]
- [:fr]La parole est aux speakers : Antoine Deprez et Brice Taillardat (AFUP Day 2019 Rennes)[:]
- [:fr]La parole est aux speakers : Stéphane Hulard (AFUP Day 2019 Lyon)[:]
- [:fr]La parole est aux speakers : Kévin Verschaeve (AFUP Day 2019 Lille)[:]
- [:fr]La parole est aux speakers : Gabriel Pillet (AFUP Day 2019 Lyon)[:]
- [:fr]La parole est aux speakers : Grégoire Hébert (AFUP Day 2019 Lille)[:]
- [:fr]La parole est aux speakers : Vincent Lainé (AFUP Day 2019 Rennes)[:]
- [:fr]La parole est aux speakers : Freek Van Der Herten (AFUP Day 2019 Lille)[:]
- [:fr]La parole est aux speakers : Julien Deniau (AFUP Day 2019 Lyon)[:]
- [:fr]La parole est aux speakers : Frédéric Bouchery (AFUP Day 2019 Rennes)[:]
- [:fr]La parole est aux speakers : Julien Pauli (AFUP Day 2019 Lille)[:]
- [:fr]La parole est aux speakers : Alex Rock (AFUP Day 2019 Lyon)[:]
- [:fr]La parole est aux speakers : Damien Alexandre (AFUP Day 2019 Rennes)[:]