jeudi 18 octobre 2018

Et si nous utilisions mal nos outils ?

Dans l’un de ces récents billets, Damien exprime sa défiance vis-à-vis de ce qu’il appelle la généralité spéculative, c’est-à-dire le fait de concevoir son code dans le but d’anticiper la résolution de problèmes éventuels, car cela implique la construction d’usine à gaz et donc la contraction d’une dette technique sans raison factuelle.

En tant qu’adepte de l’agilité, je suis sensible à ce discours, puisque l’un des buts des méthodes agiles est notamment de permettre la résolution d’un problème réel avec une solution apportant un maximum de valeur ajoutée, et il serait donc logique que je n’aie aucune réserve par rapport aux idées portées Damien.

Cependant, ce n’est pas le cas.

En effet, dans un contexte agile, afin de pouvoir pivoter afin de résoudre un problème avec un maximum d’efficacité, il y a des prérequis humains et techniques indispensables qui doivent avoir été mis en place en amont.

Humainement parlant, la communication au sein de l’équipe et de l’entreprise qui l’accueille doit être efficace, l’équipe doit disposer rapidement des moyens nécessaires pour atteindre ses objectifs, les responsabilités doivent y être partagées, les rôles clairement déterminés, et elle doit exploiter correctement le feedback qui doit bien évidemment être collecté afin que l’amélioration continue devienne une réalité, et cette liste est loin d’être exhaustive.

Et techniquement parlant, les développeurs doivent être en mesure de faire évoluer leur code rapidement, de faire des expérimentations et de revenir en arrière à moindre coût, tout en garantissant qu’il répond toujours aux besoins du client.

En clair, l’équipe doit disposer des outils et des moyens nécessaires non pas pour anticiper un avenir par nature incertain, mais pour pouvoir s’y adapter.

Or, la production d’un code suffisamment générique est à ma connaissance le seul moyen dont dispose un développeur pour que son code puisse être adapté au changement par lui-même ou quelqu’un d’autre.

Écrire du code générique n’est donc pas à mon avis une mauvaise pratique, bien au contraire, d’autant que la programmation orientée objet a précisément été conçue pour cela : permettre la création à moindre coût à tout point de vue d’un code facile à maintenir, à faire évoluer et réutilisable.

Par conséquent, écrire du code générique ne devrait pas être un problème pour un développeur pratiquant la programmation orientée objet (je ne me prononce pas pour les autres paradigmes…), puisqu’il dispose du meilleur outil disponible à ce jour pour cela.

Alors pourquoi est-ce que c’est considéré comme une mauvaise pratique ? Ou, formulé autrement, comment est-il possible qu’écrire du code générique à l’aide d’un paradigme censé le permettre simplement et facilement semble être une tâche insurmontable, la chose à ne surtout pas faire ?

Le paradoxe semble insurmontable, mais j’ai une explication qui risque de faire mal à votre ego si vous pratiquez la programmation orientée objet : la plupart des développeurs ne savent pas utiliser ce paradigme correctement, ce qui les empêche d’en exploiter le plein potentiel !

En effet, nous faisons pour la plupart d’entre nous de la programmation procédurale déguisée en programmation orientée objet.

Au lieu de faire communiquer ensemble des objets, nous manipulons des structures de données qui se font passer pour des objets, à grand renfort de conditions qui nous permettent de prendre des décisions en fonction des données contenues dans ces structures.

Et le plus paradoxal n’est pas que nous ne parvenions pas à utiliser le paradigme de la programmation orientée objet pour concevoir du code générique alors qu’il a été conçu pour cela.

Le plus paradoxal est que nous savons que nous ne l’utilisons pas correctement, que nous cherchons des solutions pour le faire, mais que ces solutions ne sont que des pis-aller et des recettes de cuisine.

Ainsi, nous dressons des catalogues de patrons de conception censés nous permettre de répondre correctement à la grande majorité des problématiques que nous rencontrons et nous créons des acronymes tels que SOLID pour évangéliser des bonnes pratiques censées nous permettre de comprendre ce qu’est un « bon » code objet, nous lançons des mouvements tels que le « if less programming » ou le « east oriented programming », nous répétons à l’envi qu’il faut privilégier la composition et restreindre fortement l’utilisation de l’héritage, nous expliquons ce qu’est l’encapsulation ou le polymorphisme, nous crachons sur les « getter/setter », etc.

Nous disons beaucoup… et nous faisons finalement peu (un peu comme pour le climat, d’ailleurs…).

Mais rarement nous cherchons à comprendre pourquoi il est nécessaire de faire tout cela, rarement nous cherchons à comprendre ce qu’est la programmation orientée objet, rarement nous  remettons fondamentalement en cause nos pratiques et nos connaissances.

À décharge, il faut bien dire qu’il n’est pas simple pour un développeur de remettre en cause l’ensemble de ses connaissances, surtout lorsque tout le monde fait de même, et je suis bien placé pour le savoir, puisque je l’ai fait il y a 5 ans.

Or, ce n’est pas parce que tout le monde fait la même chose de la même façon que c’est forcément ce qu’il faut faire pour obtenir le meilleur résultat.

De plus, les langages de programmation « orientés objet » n’aident pas, car ils sont pour la plupart basés sur des habitudes de syntaxe et des algorithmes issus du paradigme procédural.

Pourtant, pour celui qui a le courage d’entreprendre cette démarche et qui prend le temps de le faire, il devient possible d’écrire du code générique naturellement, ainsi que les tests associés.

Car vous pouvez très bien remplacer le concept de code générique par celui des tests dans le billet de Damien sans en changer le sens fondamental.

En effet, si je résume son article en une phrase, elle pourrait être :

Écrire du code générique, tout le monde voudrait le faire, mais ceux qui essayent ne savent pas le faire correctement, ce qui met la merde dans les projets, donc il ne faut pas écrire de code générique.

Maintenant, est-ce que vous voyez une grosse différence avec cela :

Écrire des tests, tout le monde voudrait le faire, mais ceux qui essayent ne savent pas le faire correctement, ce qui met la merde dans les projets, donc il ne faut pas écrire de tests.

J’avoue caricaturer quelque peu, mais je trouve que c’est tout de même assez proche de la réalité.

Et c’est la raison pour laquelle aujourd’hui, les tests sont l’exception et non la règle dans la plupart des projets informatiques et que des propositions commerciales sont faites avec à peine 1 % du budget alloué aux tests (quand il y a un budget alloué pour eux), avec tout ce que cela implique en termes d’insatisfaction, aussi bien chez les développeurs que chez les clients !

Et l’un dans l’autre, c’est aussi pour cela que nous avons des applications très gourmandes en mémoire par rapport aux services qu’elles rendent ce qui provoque la rédaction de ce type de billet d’humeur.

Alors la question est (un peu comme pour le climat, d’ailleurs…) : qu’allez-vous faire pour que cela change ?

Continuer à mal utiliser vos outils, ou bien faire en sorte de les utiliser correctement pour produire du code de qualité ?

jeudi 4 octobre 2018

Soyez le changement que vous voulez voir dans le code !

Chez Norsys, l’un de mes rôles est d’être formateur au sein de « l’école du développeur », un cursus de formation qui est suivi par les nouveaux arrivants.

Concrètement, ils partent dans un premier temps 5 jours à Lille au siège du groupe pour apprendre les bases théoriques que nous pensons nécessaires pour qu’ils soient de « bons » développeurs au sens « Norsys » du terme.

Et dans un second temps, la plupart du temps dans la foulée de la session lilloise, je reçois sur Lyon ceux qui font du PHP pour une session de travaux pratiques de 5 jours pour leur faire toucher du doigt ce qu’implique être un « bon » développeur aujourd’hui, toujours au sens « Norsys » du terme.

Je ne vais pas vous expliquer dans le détail ce qu’est pour Norsys un « bon développeur », car pour comprendre mon message, vous avez uniquement besoin de savoir qu’à la suite de cette formation, je reçois souvent des messages qui peuvent, en caricaturant à peine, se résumer à :

Mon projet, c’est le gros bordel, la dette technique est phénoménale, il n’y a aucune communication au sein de l’équipe, d’ailleurs, il n’y a pas d’équipe ni de tests ni de spécifications, par contre, il y a de la duplication de code partout, l’architecture est aux abonnés absents, il n’y a pas de vision ou alors elle change d’un jour à l’autre, les algorithmes sont inefficaces, l’intégration continue n’existe pas, et puis… tu te rends compte qu’ils travaillent encore avec SVN ???? Je n’ai pas signé pour ça !

Lire la suite

mardi 27 février 2018

À propos des mocks

J’ai découvert les mocks (ou les bouchons, en français) en 2005, lorsque j’ai commencé à m’intéresser très sérieusement aux tests.

J’avoue qu’à l’époque, je n’y ai vu qu’une couche de complexité qui n’apportait pas une réelle valeur ajoutée, et j’ai gardé cette opinion pendant longtemps, même si ponctuellement, j’y ai vu un réel intérêt.

Et puis j’ai commencé à m’intéresser à ce qu’était réellement la programmation orientée objet, et j’ai alors totalement changé d’avis à propos des bouchons.

Je ne peux aujourd’hui plus du tout m’en passer et je les mets en œuvre systématiquement pour simuler les dépendances de mon code.

Pourquoi est-ce que je vous explique tout cela ?

Lire la suite

lundi 8 janvier 2018

Les outils sont-ils la solution à nos problèmes ?

Frédéric Menou a écrit un très bon article à propos de la programmation fonctionnel et d’Haskell, dans lequel il décrit notamment les raisons qui l’ont amené à apprendre ce paradigme et ce langage.

Je n’ai pas d’avis sur son choix d’Haskell pour son activité, car je ne connais pas ce langage et encore moins son métier.

Par contre, je connais relativement bien la problématique qui l’a mené vers cette solution, car j’ai rencontré exactement la même.

En effet, si je résume (certainement très grossièrement) sa démarche, Frédéric s’est tourné vers Haskell essentiellement parce qu’il cherche à écrire le moins de bogues possible lorsqu’il code, et il pense que le formalisme offert par le langage lui permet d’y parvenir, tout en améliorant la communication avec l’ensemble des parties prenantes dans un développement informatique.

Lire la suite

mercredi 25 octobre 2017

Je serais au forum PHP 2017 !

Grâce à Norsys, je serais une nouvelle fois au forum PHP qui débutera demain, et en compagnie de 6 collègues.

J’y serais en « presque » simple visiteur, puisque je me contenterais d’y présenter un « lightning talk » de 5 minutes à propos du RGPD, ce qui va me laisser du temps pour profiter pleinement de l’événement.

Je me suis donc mitonné un programme aux petits oignons, car je trouve la sélection de conférences effectuée par l’AFUP est très attrayante.

Lire la suite

lundi 6 mars 2017

Combien de temps pour préparer une conférence (ou peindre la Joconde) ?

J’ai écrit ce billet à la suite d’une demande de Pascal et de la discussion qui s'en est suivie avec Éric.

Je fais des conférences depuis plus de 10 ans.

J’ai toujours passé énormément de temps à les préparer, et si je regarde dans le rétroviseur, je dirais que j’y passe de plus en plus de temps, car je suis de plus en plus exigeant avec moi-même.

Aujourd’hui, je pense que je mets en moyenne une dizaine de jours pour formaliser un sujet sur lequel j’ai déjà à minima au moins une vague idée de la façon dont je veux faire passer mon message, ce qui comprend :

  1. La création du plan ;
  2. La création des diapositives correspondantes avec en commentaire le texte correspondant qui sera utilisé pour la mise en ligne de la conférence ;
  3. La recherche des éléments multimédia permettant de transporter le plus rapidement possible l’idée ;
  4. Les répétitions.

Cependant, ce temps ne tient absolument pas compte du temps de maturation du sujet, à partir du moment où j’en ai eu l’idée jusqu’aux prémisses de sa formalisation.

Lire la suite

vendredi 16 décembre 2016

Nous ne sommes pas que du code

Dois-je faire du libre, avoir un compte sur Github et passer mes soirées et mes week-ends à coder dans le dernier langage à la mode pour pouvoir être reconnu comme un passionné de la programmation, comme faisant partie des meilleurs développeurs au monde, et donc pour être digne d’être embauché ?

Celui qui pose implicitement cette question est Ezekiel Buchheit, et il est Software Dev Engineer II, d’après son compte linkedin.

Il travaille aux USA, chez Amazon, et d’après son parcours, il est l’équivalent de ce que l’on appelle un développeur senior en France.

Et je ne sais pas ce que cette question provoque comme réaction chez vous, mais dans mon cas, son existence me fait peur.

Pourquoi ?

Lire la suite

mardi 22 novembre 2016

Rencontre d’un troisième type

32.jpg

Lorsque j’ai dit dans ma conférence au dernier forum PHP que nos rencontres nous rendent unique, c’est parce que j’en suis persuadé, car je l’ai vécu.

J’ai aujourd’hui un peu plus de 40 ans, et je ne serais pas celui que je suis et je ne ferais pas ce que je fais de la façon dont je le fais si je n’avais pas croisé au cours de ces années un certain nombre de personnes qui m’ont apporté une part d’eux-mêmes ou des valeurs qui sont venues se mettre en symbiose avec les miennes.

Ces personnes se connaissent parfois (après tout, qui se ressemble s’assemble, et c’est peu de le dire pour certaine), mais parfois elles n’ont absolument aucune relation.

J’ai pu les croiser quotidiennement des années durant… ou bien une seule et unique fois, pendant quelques minutes.

Elles s’appellent Christophe, Élodie, Yannick, Jean-Marc, Fabien, Julien, François… ou Philippe.

Lire la suite

vendredi 18 novembre 2016

À propos du forum PHP 2016

J’ai participé une fois encore au forum PHP cette année. Cependant, cette édition a eu pour moi une saveur particulière, pour plusieurs raisons. Tout d’abord, pour la première fois en presque 10 ans, je n’ai pas participé à l’intégralité de l’événement à cause de contraintes professionnelles. Je  […]

Lire la suite

mercredi 16 novembre 2016

À propos de l’USB-C des nouveaux MacBook Pro

Beaucoup de choses sont dites à propos des ordinateurs portables présentés dernièrement par la firme à la pomme, et notamment qu’ils sont trop chers et trop limités pour un usage professionnel.

Je ne vais pas entrer dans cette polémique, car j’ai mieux à faire de mon temps, et je vais donc me contenter de vous présenter ma réflexion personnelle sur le sujet.

Lorsqu’est sorti l’iMac sans lecteur de disquette, je me suis dit qu’Apple était devenue folle.

Lorsqu’est sorti le premier iPod, je me suis dit qu’Apple était devenue folle.

Lorsqu’est sorti le MacBook sans lecteur optique, je me suis dit qu’Apple était devenue folle.

Lorsqu’est sorti le premier iPhone, je me suis dit qu’Apple était devenue folle.

Lorsqu’est sortie la première version du MacBook Air sans port Ethernet, je me suis dit qu’Apple était devenue folle.

Lorsqu’est sorti l’iPhone 7 sans port « jack », je me suis dit qu’Apple était devenue folle.

Lorsque j'ai regardé les spécifications des nouveaux MacBook Pro, je me suis dit qu’Apple était devenue folle… et puis, j’ai regardé dans le rétroviseur.

Lire la suite

vendredi 23 septembre 2016

Mettre l'Installateur de macOS Sierra sur une clef USB

Trouver une clef USB d'une capacité ≥ à 8 Go ; L'insérer dans un port USB disponible ; Télécharger macOS Sierra à partir de l'App Store ; Ne pas lancer l'installation de macOS Sierra ; Ouvrir un terminal ; Exécuter `sudo /Applications/Install\ macOS\ Sierra.app/Contents/Resources/createinstallmedia  […]

Lire la suite

mardi 21 juin 2016

Alan Kay about object

I've been constantly surprised about how what I called object-oriented and system-oriented got neutered into Abstract Data Types, etc. I think because people wanted to retain the old ways of programming with procedures, assignment statements, and data structures. These don't scale well, but enormous  […]

Lire la suite

mercredi 17 février 2016

C'est l'histoire d'un mec

C'est l'histoire d'un mec qui exécute dans son terminal la commande phpmetrics --report-html=~/metrics src, qui se retrouve en conséquence avec un répertoire ~/ dans son répertoire courant et qui fait donc un rm -rf ~/ pour le supprimer, pour aller ensuite faire une offrande à Steve Jobs pour avoir  […]

Lire la suite

mardi 1 décembre 2015

PHP et ./configure

Aujourd’hui, j’ai fait un brew install (je sais, je suis un dingue) qui a mis à jour la bibliothèque icu, utilisée par l’extension int de PHP.

Du coup, PHP est devenu inutilisable sur mon poste de travail puisque j’obtenais systématiquement la sympathique erreur suivante :

# php -v
dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.55.dylib
Referenced from: /usr/local/bin/php
Reason: image not found
Trace/BPT trap : 5

L’erreur peut semble quelque peu incompréhensible au premier abord, mais l’expérience m’a appris qu’elle veut tout simplement dire que l’exécutable PHP n’est pas capable de localiser la bibliothèque libicui18n.55.dylib à l’emplacement indiqué lors de sa compilation, ce qui est logique vu que brew a supprimé le fichier concerné au profit de libicui18n.56.dylib (et oui, les bibliothèques qui contiennent leur numéro de version dans leur nom sont une plaie).

Lire la suite

vendredi 6 novembre 2015

J'ai oublié de vous dire… #2

J’ai oublié de vous dire que je vais me livrer à un exercice inédit pour moi lors du prochain forum PHP les 23 et 24 novembre 2015.

En effet, l’AFUP, traditionnelle organisatrice de l’événement, me renouvelle à cette occasion sa confiance puisqu’elle a retenu ma proposition de conférence concernant atoum.

Cependant, cette conférence sera très différente de celle que j’ai déjà eu l’occasion de donner à son sujet, puisque contrairement aux précédentes, elle ne se focalisera pas sur l’outil en tant que tel, mais sur ce qu’il s’est passé au cours de son développement depuis sa naissance à aujourd’hui.

Je souhaite en effet parvenir à réaliser au cours de ma conférence ce que l’on pourrait appeler une rétrospective agile du projet de sa naissance à aujourd’hui, en temps réel et avec la participation active du public, dans l’optique de parvenir à définir collectivement les actions à mener pour l’améliorer à tout point de vue.

Lire la suite

jeudi 29 octobre 2015

Chronique sur mon voyage vers l'est, quatrième !

Comme je l’ai annoncé dans mon précédent billet, je viens de donner pour la quatrième fois ma conférence à propos de la programmation orientée objet « vers l’est » dans le cadre de Blend Web Mix.

La forme a légèrement évolué au cours de ces quatre itérations, mais le fond est resté exactement le même et ceux qui n’ont pu y assister pourront donc consulter l’histoire correspondante que j’avais publiée après le PHP Tour luxembourgeois.

Lire la suite

mercredi 28 octobre 2015

J'ai oublié de vous dire… #1

J’ai oublié de vous dire que je donnerais demain une conférence à la Blend Web Mix à propos de la programmation orientée « vers l’est », également connue sous le nom de programmation orientée objet. Cette conférence est la synthèse du (long et difficile) chemin que j’ai parcouru en 18 mois lorsque  […]

Lire la suite

mardi 27 octobre 2015

J'ai un emploi !

Le dernier billet de ce blog a été pendant bien trop longtemps je suis à la recherche d’un emploi.

Je dis bien trop longtemps, car depuis maintenant pratiquement six mois, je travaille pour la société Norsys.

Ceux qui me connaissent, qui prendraient la peine de faire une recherche sur cette entreprise et qui s’arrêteraient aux premiers résultats retournés par leur moteur de recherche favori seront potentiellement surpris de mon choix.

En effet, Norsys est ce que le Syntec Numérique a décidé de pudiquement renommer il y a deux ans Entreprise de Services du Numérique, ou ESN, l’abréviation SSII pour Société de Service en Ingénierie et Informatique étant certainement devenu trop négativement connotée à son goût.

Et ce n’est un secret pour personne, je ne porte vraiment pas ce type de société dans mon cœur, pour tout un tas de raisons dont je suis prêt à débattre autour de plusieurs bières (si c’est vous qui les offrez, parce qu’il me faudra une motivation assez forte pour que j’accepte de me lancer dans ce type de discussion).

Mais alors, pourquoi ai-je décidé de rejoindre cette société, me direz-vous ?

Lire la suite

mercredi 8 avril 2015

Je cherche un emploi !

Je sais bien que cela peut sembler un peu mesquin de sortir ce blog de son sommeil pour faire savoir qu’à la suite d’un licenciement économique, je suis à la recherche d’un travail sur Lyon et ses alentours, mais comme le dit l’adage populaire : aux grands maux, les grands remèdes. Donc, si  […]

Lire la suite

mardi 9 septembre 2014

Spécifiez agile !

Si les livres relatifs à l’agilité du point de vue du développeur sont légion, ceux l’abordant du point de vue fonctionnel sont assez rares.

Or, l’agilité mise avant tout sur la bonne collaboration de toutes les parties prenantes d’un projet pour parvenir à sa concrétisation.

Il est donc primordial que chaque intervenant dispose d’une vision claire des concepts agiles et sache les exploiter au mieux dans son domaine de compétence.

Le livre de Thierry Cros intitulé Spécifiez agile a donc éveillé très fortement ma curiosité lorsque j’ai découvert son existence, à tel point que je me le suis offert en me disant que cela me permettrait peut être de mieux faire passer l’agilité auprès des experts fonctionnels avec lesquels je tentais de travailler à l’époque.

Voici donc ma critique de ce livre qui, je l’espère, permettra à Thierry d’améliorer son ouvrage.

Lire la suite

- page 1 de 96