blog/2025
1
Fork 0
Code Issues Activity

Initial commit

Browse Source
This commit is contained in:
Richard Dern
2025-03-28 12:57:37 +01:00
commit ed9ddcfdc8
1841 changed files with 42303 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

89
content/interets/informatique/2023/02/10/faire-du-developpement-un-artisanat/index.md Normal file
View File

@@ -0,0 +1,89 @@
---
date: '2023-02-10'
title: Faire du développement un artisanat
---
## Une histoire qui se répète
### L'industrie du métal
Je ne peux qu'imaginer l'enthousiasme du premier forgeron qui s'aperçu que, chauffant le métal, il pouvait lui donner toutes sortes de formes.
Il devait savoir qu'il allait changer la vie de ses congénères, en leur fournissant des outils pour faciliter leur travail, des fournitures pour améliorer le confort de la vie quotidienne, des protections contre les dangers.
Ce savoir s'est largement diffusé et, avec cette diffusion, il s'est enrichi des essais de tous les autres humains qui ont été séduits par cette voie.
L'industrialisation de la forge a entraîné une modification des techniques et des objectifs de production.
L'or, le platine, le fer, d'abord martelés à froid pour produire des bijoux, ont ensuite été chauffés pour faciliter leur travail.
Une facilitation qui a permis de produire d'autres objets, et notamment, des armes.
Alors quand les grandes guerres antiques ont éclatés, l'industrie du métal a changé.
De plus en plus de forges, de forgerons et de fours à métaux étaient nécessaires pour suivre la cadence imposée par les champs de bataille.
De rares forgerons ne prirent pas part à cette frénésie, préférant continuer à travailler des bijoux ou des objets du quotidien, avec des outils obsolètes au regard de l'industrie martiale.
La pénibilité de leur travail fut accrue, l'intérêt pour leurs productions fut réduit, car moins compétitifs que les industries métalliques de masse des grandes cités humaines.
Le forgeron devint tout à la fois le métier le plus essentiel de la chose martiale, et un métier d'artisanat dans les campagnes.
### Le ferrage
Autre travailleur bouleversé par l'industrie, subsistant toutefois encore aujourd'hui sous la forme d'un artisanat, mais autrefois essentiel au bon fonctionnement de la civilisation humaine : le maréchal-ferrant.
À une époque, pas si lointaine (moins de 200 ans), où le cheval était encore le moyen de transport de personnes le plus utilisé, empruntant toutes sortes de routes, boueuses ou pavées, c'est le maréchal-ferrant qui s'assurait de l'entretien de nos fidèles montures, et les rendait capable de traverser les terrains par lesquels on souhaitait passer.
Mais avec l'avènement des véhicules motorisés, permettant de transporter des charges plus lourdes sur de plus longues distances, beaucoup plus rapidement et sur une grande variétés de terrains, le métier devint obsolète.
On comptait déjà 250 000 automobiles sur les "routes" en 1907, et plus de 300 millions en 1975.
Devant un tel succès, le cheval a été relégué à un animal agricole, ou de loisir pour citadins en manque de nature.
Le métier de maréchal-ferrant est alors devenu un artisanat.
Une poignée de gens sont encore capables de le faire, mais ils le font avec passion et rigueur.
Une passion et une rigueur peut-être absentes chez la plupart des fabriquant automobiles...
### La pierre
Dernier exemple pour illustrer mon postulat : le travail de la pierre.
Qui réalise encore des sculptures en pierre, sinon les artistes et les artisans ?
Sans même parler de l'industrie lithique qui a précédé l'Âge du Fer, parlons du Moyen-Âge, où la production de pierre de maçonnerie a été la plus importante dans l'histoire de la civilisation humaine.
Tout le monde voulait de la pierre : pour les cathédrales, les palais royaux, mais aussi en ville, et même pour des demeures plus modestes.
Le Moyen-Âge, et dans certains cas même avant, fut à l'origine des plus belles et des plus robustes constructions en pierre.
Le travail de la pierre avait atteint un niveau de précision tel qu'encore aujourd'hui, on se demande parfois comme ils ont fait.
Constatons nos difficultés à comprendre comment les Pyramides ont été érigées, ou comment le béton romain durcirait avec le temps.
Aujourd'hui, nous employons d'autres matériaux de construction, tels que les briques, les parpaings, le bois.
Des matériaux faciles à produire en d'énormes quantités, peu chers, dont l'aspect esthétique importe peu puisqu'ils seront toujours cachés derrière un parement, et finalement impersonnels.
Des matériaux qui, certes, ont d'autres qualités, notamment en terme d'isolation.
Des qualités face auxquelles la pierre peut difficilement rivaliser.
Alors, très vite, le métier de tailleur de pierre n'était plus le métier le plus important de son industrie d'origine.
C'est devenu un artisan, qu'on appelle pour des projets spécifiques, nécessitant des connaissances spécifiques, une rigueur perdue, un talent particulier.
## Vers l'artisanat du développement
Je crois que nous avons atteint ce point où le métier de développeur en est là.
Nous sommes des millions à exercer ce métier, et nous sommes beaucoup à nous penser en fin de course.
Je vois beaucoup de témoignages sur Internet, en ce moment, de développeur se pensant en fin de carrière.
Des développeurs qui, comme moi, ont commencé quand il y avait tout à faire.
Quand les projets avaient du sens, parce que l'industrie naissait.
Mais aujourd'hui, l'industrie du développement est à son paroxysme.
Les applications sont tout à la fois disponibles en quantité ahurissante et pauvres d'intérêt.
Les projets apportant une réelle plus-value sont peu nombreux, et survivent, parfois difficilement.
Comme le forgeron, le maréchal-ferrant et le tailleur de pierre en leur temps, nous constatons que notre métier n'a plus la même valeur qu'auparavant.
Nous voyons l'industrie s'en être emparé, l'avoir transformé pour des usages hostiles aux utilisateurs, et nous ne voulons plus en être des contributeurs actifs.
Nous sommes en quête de sens à notre propre métier, celui auquel nous avons dédié nos vies, celui qui nous a donné nos lettres de noblesse.
Alors, nous devons nous préparer, pour que "développeur" devienne un métier d'artisanat, plutôt qu'un métier oublié.
Un artisanat comme ceux que j'ai mentionné dans cet article : auréolé de sentiments positifs, inspirant la rigueur, le travail d'exception, personnel, reconnaissable.
Nous n'échapperons pas à l'industrialisation ; nous y sommes même déjà confrontés puisque nous sommes déjà en quête de sens dans nos carrières professionnelles.
Ceux qui resteront ancrés dans l'industrialisation devront en embrasser les principes de production impersonnels, fades, peu attrayant et sans valeur ajoutée mais attirant de gros volumes de clients.
Les autres disparaîtront (changeront de carrière) ou deviendront artisans.
Nous sommes dans cette époque charnière, où l'industrie est à l'affût d'une technologie qui va profondément changer le métier.
On le voit dès qu'une Intelligence Artificielle remue un peu : les poids lourds de l'industrie sont sur le qui-vive, se lancent - parfois avec pertes et fracas - et espèrent une transformation radicale et inattendue, comme essayant de violer la sérendipité pour faire avancer les choses plus vite, et mettant en danger le métier de développeur au profit de solutions moins coûteuses, voire sans aucune maintenance.
Mais le danger n'est pas là, ce n'est qu'une transformation de la société qui s'est déjà vue par le passé.
Le danger, c'est de ne pas anticiper cette transformation.
La réponse à cette anticipation ne peut être qu'individuelle : ferez-vous le choix de changer de carrière, ou de transformer le métier de développeur en artisanat, comme tant d'autres professions ont réussi à le faire ?

167
content/interets/informatique/2023/02/14/rant-le-son-numerique-c-est-de-la-merde/index.md Normal file
View File

@@ -0,0 +1,167 @@
---
date: '2023-02-14'
title: 'Rant : Le son numérique, c''est de la merde'
---
Je crois que rien en informatique et dans les technos audio/vidéo ne m'a plus pris la tête que le son.
## La galère du 5.1
J'ai toujours choisi mon matériel audio/vidéo en fonction de son support du son multi-canal.
La stéréo, c'est bien pour la musique, mais moi, je veux du 5.1 pour mes films.
Je dispose de deux kits Logitech : le z5500 et le z906.
Ils prennent en entrée de l'optique, des jacks, du RCA, bref, la totale.
Je suis donc censé avoir du choix, et je suis donc censé sortir du 5.1 assez facilement.
La façon la plus sûre de sortir du **vrai** 5.1, c'est sous Windows ou GNU-Linux en passant par un câble triple-jack.
Là, on est à peu près certain que le son n'est *altéré* (transformé en 5.1 à partir d'un signal stéréo) ni par le système d'exploitation, ni par l'ampli (le décodeur - à moins de sélectionner explicitement l'option de spatialisation).
Dans tous les autres cas de figure, il est plus ou moins impossible de savoir si le son entendu est le son "d'origine" (tel que fourni par le média source) ou un son modifié par le système ou par l'ampli.
Typiquement, j'ai une source dont je sais que l'audio est en DTS mais l'ampli me la détecte comme du Dolby : le signal a été altéré par l'un des périphériques entre les deux, soit le téléviseur, soit la platine blu-ray, l'Apple TV, etc.
## Faudrait se mettre d'accord
Par exemple, depuis que je me suis équipé du z5500 il y a à peu près vingt ans, tout le monde disait que la fibre optique (toslink) c'était le top.
Aujourd'hui, je lis un peu partout que SPDIF/Toslink ne peut pas sortir autre chose que du stéréo.
Et puis, j'avoue que je ne comprends toujours pas comment un câble optique ne peut pas supporter un son en 5.1 sans compression.
D'après la [Wikipédia](https://fr.wikipedia.org/wiki/TOSLINK), un câble toslink peut supporter 250Mb/s.
Il y a sans doute une explication mais ça me gonfle de la chercher, là.
J'en ai ma claque de lire tout et son contraire, et de ne pas trouver de réponse ferme et définitive, et au-delà de ça, j'en ai ma claque des gens qui répondent n'importe quoi pour ne pas passer pour des abrutis.
Si du côté des ordinateurs sous Windows et GNU-Linux on peut trouver une solution satisfaisante (le triple-jack), tout le reste est franchement daubé du cul.
En ce qui concerne mon Mac Mini M1, il ne dispose comme sortie son que d'un unique connecteur jack pour un casque.
Apple prévoit deux scénarios :
- soit vous passez par un DAC externe (comme un ampli audio/vidéo) qui va extraire le son de la sortie HDMI ("t'as les moyens de te payer un Apple, donc t'as les moyens de te payer un DAC")
- soit vous passez par le sans-fil, par exemple via une Apple TV, ce qui ne fait que décaler le problème, ou par un HomePod, ce qui élimine le problème en oblitérant le postulat initial : "on s'en tape du 5.1, la spatialisation maison est vachement plus mieux tu vas voir" (en gros ce que font tous les constructeurs, pas qu'Apple)
Sauf que je ne passe pas par le HDMI pour la vidéo mais par l'USB-C, et que je n'ai pas spécialement envie de m'installer un ampli A/V dans mon bureau.
Du coup, la faute à qui ? Apple pour ne pas fournir de sortie audio exploitable ou Logitech pour ne pas proposer une entrée HDMI sur ses enceintes ?
## C'est la faute des TV
Mais le plus gros foutage de gueule vient du reste des périphériques A/V avec en première ligne les téléviseurs.
Non, je ne veux pas de votre DTS proprio custom qui essaye de produire du x.y (généralement 7.1 mais certains font plus exotique), peu importe le signal d'entrée.
Je veux le signal multicanal d'origine du média, je veux que ce soit l'ampli qui se débrouille avec.
C'est pas compliqué pourtant, c'est juste une suite de bits !
Vous me direz, "t'as qu'à aller dans les réglages".
OK.
C'est quoi la différence entre PCM, Passthrough, Bitstream ?
Vous allez me donner une réponse, et un autre internaute m'en donnera une autre, un troisième me dira d'aller sur Wikipédia, un quatrième me dira d'aller sur un forum A/V.
Bref, c'est le bordel, personne ne s'en sort et comme la terminologie change d'un constructeur à l'autre, personne ne se comprend.
[Exemple](https://www.samsung.com/us/support/answer/ANS00085244/) tiré de chez Samsung (fabricant de ma TV) :
> **PCM**: This stands for “pulse-code modulation.” Use this setting if the external device you've connected to the HDMI port has already processed the sound, and **you just want it to come out of your TV's speakers**.
>
> Note: **This changes the signal to 2.0 PCM as it passes through the TV**. If you select PCM even though you have a home theater system or soundbar connected, the sound system will only receive 2.0 channel sound and the result will not be multi-channel surround sound, even if the sound system is capable of multi-channel PCM audio.
>
> **Bitstream**: Use this setting if **you plan to have audio processed by a home theater system** or soundbar, after passing through the TV. This setting is required in order for a home theater system or soundbar to be able to offer multi-channel surround sound from other devices connected to the TV, if it is capable of it.
>
> Note: If you select Bitstream, but do not have a home theater system or soundbar connected, then **the TV will process the audio in addition to outputting it**. This can often result in reduced volume or other loss in audio quality. We recommend to select PCM when using the TV's speakers.
J'ai mis en gras ce qui m'interpelle.
Donc en gros, la TV altère le signal, peu importe le réglage.
Comment elle détecte si j'ai un ampli A/V derrière ?
C'est de la merde.
La seule réponse valable ici, c'est d'éviter les intermédiaires : brancher son ampli au plus près de la source A/V.
Rien de très original je vous l'accorde.
Ou sinon, utiliser la sortie ARC de la TV, donc du HDMI, donc obligé d'avoir un ampli A/V derrière ou un extracteur audio (voir ci-dessous).
Sauf que là encore, je lis des absurdités (toujours sur la même page de Samsung) :
> **PCM**: This setting is only recommended to use if your sound system experiences issues on higher settings (meaning the system may not be compatible with Dolby), or if it is the only option available for the content you are currently displaying on the TV. **This setting will only output the left and right channels** (2.0) and is not capable of multi-channel surround sound.
>
> **Dolby Digital**: This provides a multi-channel audio experience, up to 5.1 channels of sound. **It is compressed enough that it can be used with an optical cable**. Use this setting in order to enjoy multi-channel surround sound from sound systems that are capable of 5.1 processing.
Donc, soit j'ai du stéréo, soit du Dolby Digital.
Et si je veux le DTS de l'audio d'origine ?
La solution serait donc de disposer d'un "extracteur audio HDMI".
Ça tombe bien il y en a quelques uns abordables sur Amazon.
Et [j'en ai acheté un](https://www.amazon.fr/dp/B07P8RS62S).
Mais là c'est pareil : comment je peux savoir que le signal qui transite dans cet extracteur n'est pas altéré par cet extracteur avant d'arriver à mes enceintes ?
Typiquement, en mettant une source que je sais de source sûre être en stéréo, et en positionnant le commutateur de l'extracteur sur "5.1", je verrais sur les z5500 que le signal est en Dolby Digital 5.1.
D'où ça vient que le signal soit identifié comme Dolby Digital ?
Le z5500 est censé me l'identifier comme "Stéréo", l'extracteur est censé ignorer mon réglage "5.1" si la source n'est que stéréo.
J'ai aussi essayé le mode "Pass" de mon extracteur, censé envoyer le flux brut aux enceintes.
Sauf que je n'ai que de la stéréo.
Même chose sur ma platine Blu-ray, sauf que je sors en coaxial.
Là aussi, j'ai le choix entre du PCM et du Passthrough.
Et là aussi, j'ai l'impression d'être trompé sur le son.
J'entends la spatialisation.
J'entends du son sur mes six enceintes.
Mais je n'ai pas l'impression d'être enveloppé par le son.
Et puis, il me faut un extracteur supplémentaire pour la platine...
Ne venez pas me dire que le 5.1 de films AAA n'est pas correctement spatialisé.
Ni que les vidéos de test disponibles sur YouTube sont foireuses.
Ou que mon installation est merdique.
C'est juste qu'il est impossible d'avoir confiance dans ce qui est fait du son entre le moment où les données sont lues depuis la source et où elles arrivent dans l'ampli.
## Le 5.1, c'est so 1990, place aux... casques ?
Et la cause est toute trouvée : tout le monde s'en branle du 5.1.
Dès qu'on trouve la représentation d'un salon sur un site web ou dans un magazine, il y a une TV immense, et deux pauvres enceintes autour.
Ou une "barre de son"...
Pas de caisson de basse et encore moins de satellites.
J'ai un autre exemple pour étayer mon hypothèse.
L'idée serait donc de m'équiper d'un DAC, que ce soit pour mon Mac Mini ou pour mon Apple TV.
Il y a plusieurs cas de figure, aucun ne me convient.
Au plus bas de l'échelle, le DAC est une simple carte son externe qui produit un son médiocre.
Faible bande passante, bruit, faible compatibilité matérielle, bref, c'est de la merde.
Au-dessus, on trouve les DAC pour... casques.
Là, il y en a pour toutes les bourses, toutes les gammes sont représentées.
Mais je m'en tape des casques, j'ai des putain d'enceintes 5.1 !
Encore au-dessus, il y a les DAC sans-fil.
On dépasse déjà allègrement les 200 euros, et il m'en faut deux.
Le problème, c'est que quand c'est sans-fil, on a deux problèmes supplémentaires :
- la latence, on s'en tape pour de la musique mais pour le cinéma, c'est la merde
- le débit bluetooth, qui ne permet pas le 5.1...
Et encore au-dessus (à plus de 600 euros), il y a les gros amplis A/V.
Overkill pour mon usage, surtout qu'encore une fois, il m'en faut deux, et que pour mon bureau, je cherche quelque chose de compact.
Rien à foutre d'un pavé de 15 kilos qui me prendrait la moitié de mon bureau...
Pourquoi c'est si difficile de trouver un appareil qui prend en entrée de l'USB (donc, une carte son externe pour un usage PC/Mac) et qui sort directement du triple-jack, comme n'importe quel chipset son de n'importe quelle carte mère pour PC de base à moins de 50€ ?
J'acheterai volontier un appareil de ce type pour une trentaine d'euros.
Et, pourquoi pas, qui prend en entrée de l'USB-C, qui soit vu par l'OS à la fois comme une carte son et comme un moniteur (c'est bien le cas de mon Huawei MateView GT34), qui se contente d'extraire l'audio vers du triple-jack, et relaye le signal vidéo vers une sortie USB-C à laquelle est reliée mon écran ?
70 euros me paraitrait un prix pertinent, surtout que c'est technologiquement faisable : le daisy-chaining est dans les specs de l'USB-C...
Parce que tout le monde s'en fout d'avoir du 5.1.
En fait ce qui m'emmerde dans tout ça, c'est qu'il n'y a pas de solution simple entre la stéréo de base et le home-cinéma qui coûte une blinde, alors que j'ai de très bons amplis et les enceintes qui vont avec, et des sources audio qui sont capables de sortir du multicanal.
C'est entre les deux que c'est la merde et je trouve intolérable de ne rien trouver de convenable pour faire le lien.
Je suis même allé jusqu'à étudier l'installation d'un Raspberry Pi 4 équipé d'un DAC avec sortie triple-jack.
Sauf que là non plus, rien n'est simple.
Je ne vais pas détailler parce que ça me gonfle, rien que pour le coût énergétique de l'ensemble (faire tourner un OS en permanence, avec la maintenance que ça occasionne, tout ça pour avoir du son...)
Bref, pour résumer :
- je veux du 5.1 depuis mon Mac Mini vers mes z906
- je veux du 5.1 depuis mon AppleTV et ma platine blu-ray vers mes z5500
- sans altération ou décodage du signal source : c'est les amplis qui doivent se débrouiller avec le signal en entrée
La solution doit être simple, et elle ne l'est pas.
Ce n'est pas normal.
Remarque : [les gens sont capables de filmer et regarder des vidéos verticales avec leur putain de téléphone](https://www.youtube.com/watch?v=f2picMQC-9E), ça devrait pas m'étonner qu'ils n'écoutent les choses qu'en stéréo...

165
content/interets/informatique/2023/02/16/c-est-quoi-un-bon-developpeur/index.md Normal file
View File

@@ -0,0 +1,165 @@
---
date: '2023-02-16'
title: C'est quoi, un bon développeur ?
---
## Introduction
Je ne vous donne pas les clés pour trouver à coup sûr un boulot.
Ce n'est pas possible, et je n'en ai pas l'ambition.
Par contre, je vous explique comment être un bon dev, par opposition aux mauvais devs, parce que oui, selon moi, le métier du dev est manichéen.
On est attirés soit par l'argent (mauvais devs), soit par l'amour du code (bons devs).
Cet article devrait vous permettre de vous conforter dans l'une ou l'autre de ces catégories.
Il y en aura forcément pour me dire qu'on peut être un bon dev appâté par l'argent et un mauvais dev qui aime pourtant coder, et toutes les variations possibles entre les deux.
À ceux-là je réponds ceci : merde.
J'ai 40 ans, je code depuis que j'ai 5 ans.
J'ai travaillé dans le public, dans le privé, en association, en agence, etc.
Je code par amour du code et par amour du travail bien fait.
Jamais je n'ai choisi le dev pour des prérogatives financières.
Je m'estime être un excellent dev, expérimenté et spécialiste de son sujet (Laravel).
Et je suis attristé d'en être où j'en suis aujourd'hui : sans aucune reconnaissance.
Donc je le répète : cet article n'est pas un guide pour trouver un boulot, c'est une liste d'éléments que j'estime être cruciaux pour quelqu'un qui veut être un bon développeur dans son état d'esprit.
Quelqu'un qui a juste envie de pisser du code ne pourra pas apprécier cet article.
J'ai transmis à quelques devs ces principes au cours du temps.
Il me plait de croire qu'ils les exploitent aujourd'hui et contribuent à donner au métier ses lettres de noblesse.
## Une bonne répartition du temps
Un bon dev réparti son temps de la façon suivante :
- 80% de temps de réflexion en amont
- 20% de temps d'écriture de code en aval
C'est simple, ça se passe des appréciations des recruteurs.
Tout rapport différent, ou en tout cas où le temps de réflexion est inférieur au temps d'écriture, indique une entreprise qui s'en tape de la qualité, et donc hostile aux utilisateurs (et accessoirement, hostile à ses propres devs).
Mais le plus important dans ce rapport est son impact psychologique et la pénibilité du travail du dev (dont personne ne parle jamais alors qu'on est tous en burn-out en ce moment).
Tu préfères coder 2 jours et passer 5 jours à debugguer ta merde, ou passer 5 jours à réflechir et 2 jours à écrire le meilleur code du monde ?
Il y aura toujours des bugs, mais au moins, ils seront challengeants et intéressants à résoudre.
Tout le monde peut pisser du code.
Personne ne peut pisser du code de qualité supérieure.
## Pas de coding-game
Les coding-game, c'est pour les Jacky.
Un bon dev code bien, pas vite.
Les deux sont mutuellement exclusifs.
Si tu fais des coding-games pour le sport mais qu'à côté tu prends ton temps pour les projets importants, tant mieux.
Mais savoir prendre son temps est tout aussi difficile que de résoudre des challenges en temps limité.
Résoudre des coding-games ne fait pas de toi un bon développeur.
Ils font de toi un bon résolveur de problème.
L'étape entre les deux s'appelle le refactoring, et on ne te laisse pas le temps de le faire dans un coding-game.
Surtout qu'en dehors des coding-games, si tu réfléchi bien ton code en amont, tu as moins de refactoring à faire plus tard.
Et moins de refactoring = meilleur qualité de vie pour tous les devs.
## Faire de la veille
En tant que dev, on nous demande de maîtriser des dizaines de technos.
Pas seulement plusieurs langages avec des orientations différentes, mais aussi des outils pas directement liés au code (genre, docker).
C'est chiant de devoir maîtriser ces trucs parce que c'est le marché qui dicte ce qu'on doit maîtriser.
Donc, il est encore plus important de faire de la veille précisément sur ces technos.
Idéalement, tu as un ou plusieurs side-projects, de tout type et de toute taille, et tu t'en sers comme laboratoire pour tester les dernières versions de tes outils et langages préférés.
Le petit plus, c'est que ça remplit ton portfolio.
Si en plus tes side-projects sont partagés avec la communauté, c'est tout bénéf.
## Faire autre chose, de temps en temps
Voir mon article [Apologie de la procrastination](/interets/informatique/2022/02/22/apologie-de-la-procrastination/).
## Écrire du code comme s'il allait être relu (et il le sera)
Je ne suis pas certain que cette phrase n'ait pas déjà été prononcée, au moins sur Internet.
C'est dire à quel point elle est cruciale.
Par "relire du code", on entend trois choses :
- la code-review qui est censée intervenir avant la mise en situation
- le code relu plusieurs semaines/mois/années après son intégration
- le code lu par un nouvel arrivant dans l'entreprise
Ce dernier point est probablement le plus négligé et pourtant il n'est pas moins crucial qu'un nouveau collaborateur soit capable de prendre en main la codebase le plus rapidement possible.
Si le code part dans tous les sens, le nouveau dev aura du mal à prendre ses marques et prendra plus de temps à se mettre au travail.
## Standardiser les process
Le titre bien chiant à lire avec sa sémantique start-up...
Pourtant, utiliser des techniques de développement plus ou moins standardisées permet de rapidement s'approprier le code de quelqu'un d'autre.
Par exemple, pour PHP et Laravel spécifiquement (à ajuster en fonction des langages et frameworks que vous utilisez) :
- Lire les [PSR](https://www.php-fig.org/psr/), c'est les standards les plus importants du langage
- Lire [la doc du framework](https://laravel.com/docs/) avant d'essayer de dev une fonctionnalité, il contient peut-être déjà ce que vous essayez de faire
- Lire la doc du langage qui vous concerne...
"Standardiser les process", ça veut aussi - et surtout - dire de **ne pas réinventer la roue**.
En entreprise, arrêtez de coder des "frameworks maison", personne ne peut les connaître, les maîtriser ou être compétent immédiatement.
Ça veut dire aussi d'utiliser des librairies tierces, et surtout, savoir les choisir (en fonction de leur activité et de la communauté qui est derrière, mais aussi en fonction de sa taille et la façon dont elle est écrite).
Il est crucial d'embrasser des méthodes de travail qui ont fait leurs preuves depuis des dizaines d'années dans le métier :
- [DRY](https://en.wikipedia.org/wiki/Don't_repeat_yourself)
- [KISS](https://en.wikipedia.org/wiki/KISS_principle)
- [SOLID](https://fr.wikipedia.org/wiki/SOLID_%28informatique%29)
- et, dans un autre registre, [Merise](https://fr.wikipedia.org/wiki/Merise_(informatique)), probablement considérée comme obsolète par les startuppers qui ne la connaissent peut être même pas, alors qu'elle est dans les fondations de n'importe quel projet et de n'importe quel framework aujourd'hui
Enfin, et c'est le plus important, ça veut dire utiliser correctement les éléments de langage, en particulier les interfaces, en tout cas en PHP.
Les interfaces sont probablement les outils les plus importants du langage pour structurer son code et permettre à vos composants d'être facilement interchangeables.
## Respecter l'utilisateur final
Bon, là, il faut se faire pousser des couilles et savoir dire "non" quand on te demande de coder un truc que tu sais être hostile à l'utilisateur.
Faire de la veille sur les [dark-patterns](https://fr.wikipedia.org/wiki/Dark_pattern) est important, pas seulement pour refuser de le faire mais aussi pour éviter de tomber dedans sans faire exprès (c'est plus facile qu'on le pense, surtout côté frontend, et surtout quand on touche à la télémétrie).
Respecter l'utilisateur final, c'est faire en sorte que ton application fonctionne comme elle est prévue.
Qu'elle informe l'utilisateur quand elle doit l'informer, et qu'elle ait un comportement logique et intuitif (c'est quoi ce truc de faire des messages d'erreur du genre "Une erreur est survenue, réssayez plus tard", sans même un code d'erreur à remonter ?).
Tu mets tout le monde d'accord quand tu respectes l'utilisateur final : ce dernier parce qu'il est content d'utiliser une application qui fonctionne bien, le service support de ta boîte qui ne se fera pas engueuler à longueur de temps pour rien, et toi parce que ton application sera plus facile à debugguer.
## Aimer ce que tu fais
Si tu codes parce qu'on t'a dit que coder c'était bien payé, passes ton chemin.
Déjà parce que ce n'est pas forcément vrai, mais surtout parce que pour être un bon dev, la motivation principale ne peut pas être l'argent.
Ces remarques sont valables peu importe le métier, plus ou moins.
S'il n'y a que l'argent qui t'attire dans le dev, tu deviendras un mauvais développeur, hostile à l'utilisateur.
C'est une remarque parfaitement censée et éprouvée depuis que le web existe : plus tu es hostile à l'utilisateur, plus tu rapportes de l'argent à ton entreprise.
Ça ne fait pas de toi un bon développeur, ça fait de toi un bon [rabatteur](https://www.linternaute.fr/dictionnaire/fr/definition/rabatteur/).
Sauf qu'un bon développeur qui produit une application de qualité peut rapporter encore plus d'argent à son entreprise, en plus de ne pas entâcher sa renommée.
Et s'il y a une chose qu'une entreprise apprécie encore moins que perdre de l'argent, c'est d'avoir mauvaise presse.
Donc, tu dois coder parce que tu aimes coder.
Parce que tu apprécies la capacité créatrice de l'informatique, écrire des instructions de la meilleure façon possible pour transformer ces instructions en résultat tangible, et fiable.
## Du dev à l'artisan, puis à l'artiste
Si tu aimes ce que tu fais, tu vas entrer dans une boucle vertueuse, où tu vas chercher à produire le code de la meilleure qualité possible.
Tu vas passer (intellectuellement) du simple développeur à [l'artisan](/interets/informatique/2023/02/10/faire-du-developpement-un-artisanat/) quand tu commenceras à rejeter les mauvaises pratiques exercées en entreprise (sauf, évidemment, si tu as la chance de tomber rapidement sur une boîte qui valorise les bonnes pratiques).
Et un jour, longtemps après, tu finiras par être considéré comme un artiste du code par tes pairs.
Pour rester sur le thème de PHP et de Laravel, tu atteindras peut-être le niveau d'un [Taylor Otwell](https://twitter.com/taylorotwell), d'un [Nuno Maduro](https://github.com/nunomaduro/) ou encore d'un [Freek Van Der Herten](https://freek.dev/).
## Conclusion
Il y a mille choses encore à dire sur le sujet, et encore plus si je me focalisais sur ce que devrait être un bon développeur PHP,
mais on a là l'essentiel.
Si tu te reconnais dans cet article, tu es sur la bonne voie.
La voie du bien, celle du bon dev bien dans ses babouches.
Tu ne connaîtras pas forcément le succès (je ne l'ai pas connu), alors à toi de voir ce qui compte le plus pour toi.

26
content/interets/informatique/2023/02/21/vers-un-code-de-deontologie-des-developpeurs/index.md Normal file
View File

@@ -0,0 +1,26 @@
---
date: '2023-02-21'
title: Vers un code de déontologie des développeurs
---
Cela fait depuis quelques temps que je cherche à formaliser un code de déontologie à l'attention des développeurs.
Au moins depuis l'avènement de Google, de la publicité en ligne, et l'émergence des réseaux sociaux, voire depuis le commerce en ligne.
Après une longue et pénible expérience professionnelle dans des milieux variés, après avoir constaté que mon domaine de prédilection n'est pas peuplé que de gentils développeurs qui oeuvrent à améliorer la vie de toute l'humanité, c'est avec amertume, cynisme et un dédain que je ne peux cacher que j'ai fini par écrire (et publier) un article consacré à [la transformation du métier de développeur en artisanat](/interets/informatique/2023/02/10/faire-du-developpement-un-artisanat/) et sur ce qui constitue, selon moi, [un bon développeur](/interets/informatique/2023/02/16/c-est-quoi-un-bon-developpeur/).
La route sera longue pour en arriver là, mais une autre pierre que je peux apporter à l'édifice est la formalisation d'un code de déontologie à l'attention des développeurs.
Dans l'idée, je m'inspire évidemment du [serment d'Hippocrate](https://www.conseil-national.medecin.fr/medecin/devoirs-droits/serment-dhippocrate).
On pourra m'objecter qu'un médecin et un développeur n'ont pas vraiment les mêmes prérogatives.
Pourtant, notre société ne pourrait pas fonctionner sans informatique, et sans des gens qui l'entretiennent, et développent les outils dont elle a besoin.
On pourra m'objecter qu'il n'y a pas besoin de code de déontologie des développeurs.
Que ce n'est pas parce que je l'écris, moi, anonyme parmi les anonymes, qu'il sera reconnu.
Je suis un homme libre.
Libre d'écrire ce code de déontologie.
Vous êtes des gens libres.
Libres de ne pas le suivre.
Je publie ce code de déontologie [sur ma forge logicielle](https://git.dern.ovh/Livres/code-de-deontologie-des-developpeurs) dans un premier temps.
J'aviserai en fonction des retours sur cet article.