Blog
Blog | Open | Open | 8073 | 8227 | ❌️
Post | Open | Open | 11252 | 11291 | ❌️
Enhanced tag page (veille) | Open | Open | 8137 | 8176 | ❌️
Tag page pagination (javascript, page 5) | Open | Open | 10084 | 10123 | ❌️
Tag page (lecteur d'écran) | Open | Open | 6166 | 6205 | ❌️
Tags | Open | Open | 27316 | 27359 | ❌️
CV
CV fr | Open | Open | 22361 | 22361 | ✅️
CV fr pdf | Open | Open | 110749 | 110749 | ✅️
CV | Open | Open | 21486 | 21486 | ✅️
CV en pdf | Open | Open | 87268 | 87268 | ✅️
Pages
Page list | Open | Open | 8192 | 8231 | ❌️
About | Open | Open | 3510 | 3510 | ✅️
Misc
Github profile, | Open | Open | 2058 | 2101 | ❌️
Github page, | Open | Open | 10316 | 10355 | ❌️
Photos
Resized Photo (660x) | Open | Open | 32036 | 32036 | ✅️
Resized Photo (200x) | Open | Open | 5438 | 5438 | ✅️
RSS feeds (build date should be updated)
RSS | Open | Open | 58543 | 53554 | ❌️
RSS tag | Open | Open | 44878 | 46302 | ❌️
RSS tag fr | Open | Open | 34783 | 34783 | ❌️
Diffs
Homepage
--- index.html.pretty 2024-03-02 09:57:55.451012631 +0000
+++ ../web/index.html.pretty 2024-03-02 09:57:55.455012611 +0000
@@ -516,6 +516,10 @@
Derniers billets</h2>
<ul>
<li>
+<a href=/post/la-maintenabilite-comme-critere-de-decision/ lang=fr>
+La maintenabilité comme critère de décision</a>
+</li>
+<li>
<a href=/post/utils-helper-sont-sur-un-bateau/ lang=fr>
Utils et helper sont sur un bateau…</a>
</li>
@@ -539,10 +543,6 @@
<a href=/post/ecran-demarrage-session-vim-startify/ lang=fr>
Un écran de démarrage et un gestionnaire de session avec vim-startify</a>
</li>
-<li>
-<a href=/post/livre-l-odyssee-des-genes/ lang=fr>
-L'odyssée des gènes</a>
-</li>
</ul>
</div>
</aside>
Blog
--- index.html.pretty 2024-03-02 09:57:58.670995963 +0000
+++ ../web/posts/index.html.pretty 2024-03-02 09:57:58.674995942 +0000
@@ -55,6 +55,49 @@
<li>
<article lang=fr>
<figure class=post-image>
+<a href=/post/la-maintenabilite-comme-critere-de-decision/ class=post-image>
+<img src=/images/200x/shrug.png alt="Miniature de 'La maintenabilité comme critère de décision'" loading=lazy>
+</a>
+</figure>
+<div class=post-info>
+<h2>
+<a href=/post/la-maintenabilite-comme-critere-de-decision/ >
+La maintenabilité comme critère de décision</a>
+</h2>
+<div class=post-meta>
+<ul class=post-tags>
+<li>
+<a href=/tag/bonnes-pratiques/ class=tag>
+bonnes pratiques</a>
+</li>
+<li>
+<a href=/tag/métier/ class=tag>
+métier</a>
+</li>
+<li>
+<a href=/tag/travail/ class=tag>
+travail</a>
+</li>
+<li>
+<a href=/tag/qualité/ class=tag>
+qualité</a>
+</li>
+<li>
+<a href=/tag/code/ class=tag>
+code</a>
+</li>
+</ul>
+<time datetime=2024-03-02>
+<a href=/post/la-maintenabilite-comme-critere-de-decision/ >
+02 mars 2024</a>
+</time>
+</div>
+</div>
+</article>
+</li>
+<li>
+<article lang=fr>
+<figure class=post-image>
<a href=/post/utils-helper-sont-sur-un-bateau/ class=post-image>
<img src=/images/200x/plouf.jpg alt="Miniature de 'Utils et helper sont sur un bateau…'" loading=lazy>
</a>
@@ -228,41 +271,6 @@
</div>
</article>
</li>
-<li>
-<article lang=fr>
-<figure class=post-image>
-<a href=/post/maximiser-efficacite-developpeurs/ class=post-image>
-<img src=/images/200x/automatisation.jpg alt="Miniature de 'Maximiser l'efficacité des développeur·ses'" loading=lazy>
-</a>
-</figure>
-<div class=post-info>
-<h2>
-<a href=/post/maximiser-efficacite-developpeurs/ >
-Maximiser l'efficacité des développeur·ses</a>
-</h2>
-<div class=post-meta>
-<ul class=post-tags>
-<li>
-<a href=/tag/veille/ class=tag>
-veille</a>
-</li>
-<li>
-<a href=/tag/métier/ class=tag>
-métier</a>
-</li>
-<li>
-<a href=/tag/bonnes-pratiques/ class=tag>
-bonnes pratiques</a>
-</li>
-</ul>
-<time datetime=2021-02-07>
-<a href=/post/maximiser-efficacite-developpeurs/ >
-07 févr. 2021</a>
-</time>
-</div>
-</div>
-</article>
-</li>
</ul>
<ul class=navigation>
<li class=navigation-prev>
@@ -318,6 +326,10 @@
Derniers billets</h2>
<ul>
<li>
+<a href=/post/la-maintenabilite-comme-critere-de-decision/ lang=fr>
+La maintenabilité comme critère de décision</a>
+</li>
+<li>
<a href=/post/utils-helper-sont-sur-un-bateau/ lang=fr>
Utils et helper sont sur un bateau…</a>
</li>
@@ -341,10 +353,6 @@
<a href=/post/ecran-demarrage-session-vim-startify/ lang=fr>
Un écran de démarrage et un gestionnaire de session avec vim-startify</a>
</li>
-<li>
-<a href=/post/livre-l-odyssee-des-genes/ lang=fr>
-L'odyssée des gènes</a>
-</li>
</ul>
</div>
</aside>
Post
--- index.html.pretty 2024-03-02 09:57:59.374992175 +0000
+++ ../web/post/custom-hooks-react/index.html.pretty 2024-03-02 09:57:59.374992175 +0000
@@ -282,6 +282,10 @@
Derniers billets</h2>
<ul>
<li>
+<a href=/post/la-maintenabilite-comme-critere-de-decision/ lang=fr>
+La maintenabilité comme critère de décision</a>
+</li>
+<li>
<a href=/post/utils-helper-sont-sur-un-bateau/ lang=fr>
Utils et helper sont sur un bateau…</a>
</li>
@@ -305,10 +309,6 @@
<a href=/post/ecran-demarrage-session-vim-startify/ lang=fr>
Un écran de démarrage et un gestionnaire de session avec vim-startify</a>
</li>
-<li>
-<a href=/post/livre-l-odyssee-des-genes/ lang=fr>
-L'odyssée des gènes</a>
-</li>
</ul>
</div>
</aside>
Enhanced tag page (veille)
--- index.html.pretty 2024-03-02 09:58:00.298987204 +0000
+++ ../web/tag/veille/index.html.pretty 2024-03-02 09:58:00.302987183 +0000
@@ -344,6 +344,10 @@
Derniers billets</h2>
<ul>
<li>
+<a href=/post/la-maintenabilite-comme-critere-de-decision/ lang=fr>
+La maintenabilité comme critère de décision</a>
+</li>
+<li>
<a href=/post/utils-helper-sont-sur-un-bateau/ lang=fr>
Utils et helper sont sur un bateau…</a>
</li>
@@ -367,10 +371,6 @@
<a href=/post/ecran-demarrage-session-vim-startify/ lang=fr>
Un écran de démarrage et un gestionnaire de session avec vim-startify</a>
</li>
-<li>
-<a href=/post/livre-l-odyssee-des-genes/ lang=fr>
-L'odyssée des gènes</a>
-</li>
</ul>
</div>
</aside>
Tag page pagination (javascript, page 5)
--- index.html.pretty 2024-03-02 09:58:00.942983743 +0000
+++ ../web/tag/javascript/5/index.html.pretty 2024-03-02 09:58:00.946983722 +0000
@@ -502,6 +502,10 @@
Derniers billets</h2>
<ul>
<li>
+<a href=/post/la-maintenabilite-comme-critere-de-decision/ lang=fr>
+La maintenabilité comme critère de décision</a>
+</li>
+<li>
<a href=/post/utils-helper-sont-sur-un-bateau/ lang=fr>
Utils et helper sont sur un bateau…</a>
</li>
@@ -525,10 +529,6 @@
<a href=/post/ecran-demarrage-session-vim-startify/ lang=fr>
Un écran de démarrage et un gestionnaire de session avec vim-startify</a>
</li>
-<li>
-<a href=/post/livre-l-odyssee-des-genes/ lang=fr>
-L'odyssée des gènes</a>
-</li>
</ul>
</div>
</aside>
Tag page (lecteur d'écran)
--- index.html.pretty 2024-03-02 09:58:01.578980321 +0000
+++ "../web/tag/lecteur-d'écran/index.html.pretty" 2024-03-02 09:58:01.582980300 +0000
@@ -227,6 +227,10 @@
Derniers billets</h2>
<ul>
<li>
+<a href=/post/la-maintenabilite-comme-critere-de-decision/ lang=fr>
+La maintenabilité comme critère de décision</a>
+</li>
+<li>
<a href=/post/utils-helper-sont-sur-un-bateau/ lang=fr>
Utils et helper sont sur un bateau…</a>
</li>
@@ -250,10 +254,6 @@
<a href=/post/ecran-demarrage-session-vim-startify/ lang=fr>
Un écran de démarrage et un gestionnaire de session avec vim-startify</a>
</li>
-<li>
-<a href=/post/livre-l-odyssee-des-genes/ lang=fr>
-L'odyssée des gènes</a>
-</li>
</ul>
</div>
</aside>
--- index.html.pretty 2024-03-02 09:58:07.966946720 +0000
+++ ../web/pages/index.html.pretty 2024-03-02 09:58:07.966946720 +0000
@@ -278,6 +278,10 @@
Derniers billets</h2>
<ul>
<li>
+<a href=/post/la-maintenabilite-comme-critere-de-decision/ lang=fr>
+La maintenabilité comme critère de décision</a>
+</li>
+<li>
<a href=/post/utils-helper-sont-sur-un-bateau/ lang=fr>
Utils et helper sont sur un bateau…</a>
</li>
@@ -301,10 +305,6 @@
<a href=/post/ecran-demarrage-session-vim-startify/ lang=fr>
Un écran de démarrage et un gestionnaire de session avec vim-startify</a>
</li>
-<li>
-<a href=/post/livre-l-odyssee-des-genes/ lang=fr>
-L'odyssée des gènes</a>
-</li>
</ul>
</div>
</aside>
Github profile,
--- README.md.pretty 2024-03-02 09:58:09.246940216 +0000
+++ ../web/github/README.md.pretty 2024-03-02 09:58:09.246940216 +0000
@@ -19,11 +19,11 @@
## Les derniers billets ([Flux RSS](https://damien.pobel.fr/rss.xml))
+* [La maintenabilité comme critère de décision](https://damien.pobel.fr/post/la-maintenabilite-comme-critere-de-decision/)
* [Utils et helper sont sur un bateau…](https://damien.pobel.fr/post/utils-helper-sont-sur-un-bateau/)
* [Quelques défis liés à l'édition d'un logiciel destiné à être intégré](https://damien.pobel.fr/post/quelques-defis-editeur-logiciel-integration/)
* [Tests : mon top 8 des anti-patrons les plus agaçants](https://damien.pobel.fr/post/tests-antipatterns-agacants/)
* [Pourquoi utiliser des hooks sur-mesure dans vos composants React](https://damien.pobel.fr/post/custom-hooks-react/)
* [Maximiser l'efficacité des développeur·ses](https://damien.pobel.fr/post/maximiser-efficacite-developpeurs/)
* [Un écran de démarrage et un gestionnaire de session avec vim-startify](https://damien.pobel.fr/post/ecran-demarrage-session-vim-startify/)
-* [L'odyssée des gènes](https://damien.pobel.fr/post/livre-l-odyssee-des-genes/)
Github page,
--- index.html.pretty 2024-03-02 09:58:09.890936945 +0000
+++ ../web/github/page/index.html.pretty 2024-03-02 09:58:09.890936945 +0000
@@ -465,6 +465,10 @@
Derniers billets</h2>
<ul>
<li>
+<a href=/post/la-maintenabilite-comme-critere-de-decision/ lang=fr>
+La maintenabilité comme critère de décision</a>
+</li>
+<li>
<a href=/post/utils-helper-sont-sur-un-bateau/ lang=fr>
Utils et helper sont sur un bateau…</a>
</li>
@@ -488,10 +492,6 @@
<a href=/post/ecran-demarrage-session-vim-startify/ lang=fr>
Un écran de démarrage et un gestionnaire de session avec vim-startify</a>
</li>
-<li>
-<a href=/post/livre-l-odyssee-des-genes/ lang=fr>
-L'odyssée des gènes</a>
-</li>
</ul>
</div>
</aside>
RSS
--- rss.xml.pretty 2024-03-02 09:58:12.606923148 +0000
+++ ../web/rss.xml.pretty 2024-03-02 09:58:12.606923148 +0000
@@ -5,9 +5,81 @@
<description><![CDATA[Derniers posts du blog de Damien Pobel]]></description>
<link>https://damien.pobel.fr</link>
<generator>metalsmith-feed</generator>
- <lastBuildDate>Tue, 27 Feb 2024 07:06:24 GMT</lastBuildDate>
+ <lastBuildDate>Sat, 02 Mar 2024 09:57:25 GMT</lastBuildDate>
<atom:link href="https://damien.pobel.fr/rss.xml" rel="self" type="application/rss+xml"/>
<item>
+ <title><![CDATA[La maintenabilité comme critère de décision]]></title>
+ <description><![CDATA[<figure class="object-center bordered">
+ <img loading="lazy" src="/images/660x/shrug.png" alt="Image où il est inscrit
+ ¯\_(ツ)_/¯ qui signifie shrug ou haussement d'épaule.">
+</figure>
+
+<p>En début d'année, j'ai lu <a href="https://www.packtpub.com/product/get-your-hands-dirty-on-clean-architecture-second-edition/9781805128373">Get Your Hands Dirty on Clean Architecture (Second
+Edition)</a>
+de <a href="https://reflectoring.io/authors/tom/">Tom Hombergs</a>. Comme son titre
+l'indique, ce très bon livre traite de la <em>Clean Architecture</em> et plus
+particulièrement de <a href="https://fr.wikipedia.org/wiki/Architecture_hexagonale">l'architecture
+hexagonale</a>. Tout au long
+des quelques 140 pages, l'auteur aborde ce type d'architecture sous différents
+aspects mais il en est un qui revient régulièrement tout en étant le sujet du
+premier chapitre : <strong>la maintenabilité</strong>.</p>
+<p>Une bonne partie de ce premier chapitre peut se résumer par cette expression
+<em>pseudo-mathématique</em> :</p>
+<pre><code class="language-plaintext">maintenabilité >>> tout le reste
+</code></pre>
+<p>Dans <em>tout le reste</em> rentrent les qualités qu'on cherche souvent à atteindre
+dans la construction d'un logiciel par exemple les performances, la
+<em>scalabilité</em>, la robustesse, la flexibilité et bien d'autres… Et comme
+l'explique très bien l'auteur, la maintenabilité a ceci de spécial qu'elle est
+une qualité qui permet d'atteindre toutes les autres. En effet, dès qu'un
+logiciel est maintenable, il est facile à faire évoluer pour atteindre certaines
+qualités dès que le besoin émerge. Évidemment, l'ajout de
+fonctionnalités et la correction des bugs sont également d'autant plus simples que le
+code est maintenable. En d'autres termes, la maintenabilité aide à la fois à
+atteindre des objectifs fonctionnels et non fonctionnels.</p>
+<p>Je formule généralement cette idée de la manière suivante :</p>
+<blockquote>
+<p>Un bon code est un code facile à changer.</p>
+</blockquote>
+<p>Ni plus, ni moins. Jusque là, rien de très original je crois mais ça va mieux en
+le disant 😁</p>
+<p>Dans ce chapitre, Tom Hombergs pousse la réflexion un peu plus loin et notamment
+en énonçant ce qui m'apparaît maintenant comme un corollaire :</p>
+<blockquote>
+<p>Whenever we have to decide between multiple options, we can choose the one
+that makes the code easier to change in the future. No more agonizing between
+different options. We just take the one that increases maintainability the
+most.</p>
+</blockquote>
+<p>ce qui peut se traduire par :</p>
+<blockquote>
+<p>Chaque fois que nous devons choisir entre plusieurs options, nous pouvons
+choisir celle qui rendra le code plus facile à changer dans le futur. Plus
+besoin de se torturer l'esprit entre différentes options. Nous choisissons
+simplement celle qui augmente le plus la maintenabilité.</p>
+</blockquote>
+<p>Quand j'ai lu cette partie, je dois dire qu'une petite lumière s'est allumée
+dans ma tête 💡 J'ai beau être convaincu de l'importance de la maintenabilité
+depuis de nombreuses années maintenant, je n'avais jamais considéré cette
+qualité comme une aide à la décision de manière aussi directe. Et forcément, en
+regardant un peu dans le rétroviseur, je me rends compte qu'appliquer ce
+principe dans certaines décisions aurait potentiellement mener à de meilleurs
+choix.</p>
+<p>Comme souvent avec ce genre de principe général, il s'agit d'un élément parmi
+beaucoup d'autres et comme l'indique Tom Hombergs, le <em>bon</em> choix n'est parfois
+pas celui qui améliore ou conserve la maintenabilité. Néanmoins opter pour ce
+principe par défaut me semble être une bonne approche.</p>
+]]></description>
+ <link>https://damien.pobel.fr/post/la-maintenabilite-comme-critere-de-decision</link>
+ <guid isPermaLink="true">https://damien.pobel.fr/post/la-maintenabilite-comme-critere-de-decision</guid>
+ <category><![CDATA[bonnes pratiques]]></category>
+ <category><![CDATA[métier]]></category>
+ <category><![CDATA[travail]]></category>
+ <category><![CDATA[qualité]]></category>
+ <category><![CDATA[code]]></category>
+ <pubDate>Sat, 02 Mar 2024 00:00:00 GMT</pubDate>
+ </item>
+ <item>
<title><![CDATA[Utils et helper sont sur un bateau…]]></title>
<description><![CDATA[<figure class="object-center bordered">
<img loading="lazy" src="/images/660x/plouf.jpg" alt="Petites vaguelettes
@@ -738,175 +810,5 @@
<category><![CDATA[potager]]></category>
<pubDate>Sat, 02 Jan 2021 00:00:00 GMT</pubDate>
</item>
- <item>
- <title><![CDATA[« Clean Code » résumé en quelques lignes]]></title>
- <description><![CDATA[<p class="note">
-Ce texte est une traduction et une adaptation de <a
-href="https://gist.github.com/cedrickchee/55ecfbaac643bf0c24da6874bf4feb08">Summary
-of 'Clean code' by Robert C. Martin</a>.
-</p>
-
-<p>Voici un résumé des principales idées du livre « <a href="https://www.decitre.fr/livres/clean-code-9780132350884.html">Clean Code: A Handbook of Agile
-Software
-Craftsmanship</a> » de
-Robert C. Martin (Uncle Bob).</p>
-<p>Du code est propre (<em>clean</em>) si il peut être compris facilement - par chaque
-personne de l'équipe. Un code propre (<em>Clean code</em>) peut être lu et amélioré par
-un·e développeur·se autre que la personne qui l'a écrit. Avec la
-compréhensibilité vient la lisibilité, la facilité à changer, l'extensibilité et
-la maintenabilité.</p>
-<figure class="object-center bordered">
- <img loading="lazy" src="/images/660x/water-drop.jpg" alt="Une goutte d'eau">
-</figure>
-
-<h2 id="règles-générales">Règles générales</h2>
-<ol>
-<li>Suivez <strong>des conventions reconnues</strong>.</li>
-<li><em>Keep it <strong>simple</strong> stupid</em>. Plus simple est toujours mieux. <a href="/post/complexite-charge-cognitive/">Réduisez la
-complexité</a> autant que possible.</li>
-<li><strong>Règle du boy scout</strong> : laissez le camp plus propre que l'état dans lequel
-vous l'avez trouvé.</li>
-<li>Lors de résolution d'un problème, toujours chercher et trouver <strong>la cause
-racine</strong>.</li>
-<li>Suivez <a href="https://fr.wikipedia.org/wiki/Principe_de_moindre_surprise"><strong>le principe de moindre
-surprise</strong></a>.</li>
-<li><abbr title="Don't Repeat Youself">DRY</abbr> : ne vous répétez pas, et <a href="https://medium.com/@nicolopigna/this-is-not-the-dry-you-are-looking-for-a316ed3f445f">mais
-attention à l'interprétation de ce
-principe</a>.</li>
-</ol>
-<h2 id="règles-de-design">Règles de design</h2>
-<ol>
-<li>Gardez les données configurables (par exemple les constantes) à hauts
-niveaux. Elles devraient être <strong>faciles à changer</strong>.</li>
-<li>Préférez le polymorphisme aux <code>if</code>/<code>else</code> ou <code>switch</code>/<code>case</code>.</li>
-<li>Évitez la sur-configurabilité et <a href="/post/au-cas-ou/">tout ce qui n'a pas prouvé sa
-nécessité</a>.</li>
-<li>Utilisez <strong>l'injection de dépendances</strong>.</li>
-<li>Suivez <a href="https://fr.wikipedia.org/wiki/Loi_de_D%C3%A9m%C3%A9ter"><strong>la loi de
-Déméter</strong></a> : une
-classe ne devrait connaître que ses dépendances directes.</li>
-</ol>
-<h2 id="astuces-pour-la-compréhensibilité">Astuces pour la compréhensibilité</h2>
-<ol>
-<li>Soyez <strong>cohérent</strong>. Si vous faites quelque chose d'une certaine manière,
-toutes les choses similaires devraient être faites de la même manière.</li>
-<li>Utilisez <strong>des noms de variables explicites</strong>.</li>
-<li><strong>Encapsulez les conditions limites</strong> : elles sont compliquées à suivre. Il
-vaut mieux les isoler à un endroit.</li>
-<li>Préférez <a href="https://patricklouys.com/2017/06/04/value-objects-explained/">des <strong><em>value objects</em>
-spécifiques</strong></a>
-plutôt que des types primitifs</li>
-<li><strong>Évitez les dépendances logiques</strong> : n'écrivez pas de méthodes qui dépendent
-d'autre chose dans la même classe.</li>
-<li><strong>Évitez les conditions négatives</strong>.</li>
-</ol>
-<h2 id="règles-de-nommages">Règles de nommages</h2>
-<ol>
-<li>Choisissez <strong>des noms descriptifs et sans ambiguïté</strong>.</li>
-<li>Faites <strong>des distinctions qui ont du sens</strong>.</li>
-<li>Utilisez <strong>des noms prononçables</strong>.</li>
-<li>Utilisez <strong>des noms cherchables</strong>.</li>
-<li>Remplacez les nombres magiques par <strong>des constantes bien nommées</strong>.</li>
-<li>Évitez d'ajouter des préfixes ou des informations sur les types.</li>
-</ol>
-<h2 id="règles-relatives-aux-fonctions">Règles relatives aux fonctions</h2>
-<ol>
-<li><strong>Courtes</strong>.</li>
-<li><strong>Ne fait qu'une chose</strong> et la fait bien.</li>
-<li>Utilisez <strong>des noms descriptifs</strong>.</li>
-<li>Préférez les avec <strong>le moins d'arguments possibles</strong>, idéalement pas plus de 3.</li>
-<li><strong>Sans effet de bord</strong>.</li>
-<li><a href="https://ariya.io/2011/08/hall-of-api-shame-boolean-trap">N'utilisez pas de
-<em>flag</em></a> : écrivez
-plutôt plusieurs méthodes sans ce type d'argument.</li>
-</ol>
-<h2 id="règles-relatives-aux-commentaires">Règles relatives aux commentaires</h2>
-<ol>
-<li>Essayez d'écrire <a href="/post/juste-dose-commentaires-dans-le-code/"><strong>du code expressif</strong> ne nécessitant pas de
-commentaire</a>. Si c'est
-impossible, prenez le temps d'écrire un bon commentaire.</li>
-<li>Ne soyez pas redondant (par exemple : <code>i++; // increment i</code>).</li>
-<li>N'ajoutez pas de bruit évident.</li>
-<li>N'utilisez pas les commentaires de fermeture de bloc (par exemple : <code>} // end of function</code>).</li>
-<li><strong>Ne commentez pas de code</strong>. Supprimez ce code.</li>
-<li>Utilisez des commentaires <strong>pour expliquer l'intention</strong>.</li>
-<li>Utilisez des commentaires <strong>pour avertir des conséquences</strong>.</li>
-</ol>
-<h2 id="structure-du-code-source">Structure du code source</h2>
-<ol>
-<li><strong>Séparez les concepts verticalement</strong>.</li>
-<li><strong>Le code lié</strong> devrait apparaître <strong>dense verticalement</strong>.</li>
-<li>Déclarez les <strong>variables à proximité de leurs usages</strong>.</li>
-<li><strong>Les fonctions dépendantes les unes des autres</strong> devraient être <strong>à
-proximité</strong>.</li>
-<li><strong>Les fonctions similaires</strong> devraient être <strong>à proximité les unes des
-autres</strong>.</li>
-<li>Placez les fonctions dans <strong>la direction descendante</strong>.</li>
-<li>Gardez les <strong>lignes courtes</strong>.</li>
-<li>N'alignez rien horizontalement.</li>
-<li>Utilisez des <strong>espaces pour associer des choses liées</strong> et dissocier des
-choses liées faiblement.</li>
-<li><strong>Ne cassez pas l'indentation</strong>.</li>
-</ol>
-<h2 id="objets-et-structures-de-données">Objets et structures de données</h2>
-<ol>
-<li>Cachez les structures internes.</li>
-<li>Devraient être <strong>petits</strong>.</li>
-<li><strong>Ne font qu'une chose</strong>.</li>
-<li><strong>Possèdent un petit nombre de variables d'instance</strong>. Si votre classe a trop
-de variables d'instance, il est probable que votre objet fasse plus qu'une
-chose.</li>
-<li>Une classe de base ne devrait rien connaître de ses classes dérivées.</li>
-<li><strong>Il vaut mieux avoir plusieurs fonctions</strong> que de passer du code à une
-fonction pour qu'elle choisisse un comportement.</li>
-<li><strong>Préférez des méthodes non statiques</strong>.</li>
-</ol>
-<h2 id="tests"><a href="/post/bon-test-unitaire-integration-fonctionnel/">Tests</a></h2>
-<ol>
-<li><strong>Un concept</strong> par test.</li>
-<li><strong>Rapides</strong>.</li>
-<li><strong>Indépendants</strong>.</li>
-<li><strong>Répétables</strong>.</li>
-<li><strong>Auto validants</strong>.</li>
-<li><strong>Utiles</strong>.</li>
-<li><strong>Lisibles</strong>.</li>
-<li><strong>Faciles à lancer</strong>.</li>
-<li><a href="/post/code-coverage-taux-couverture-tests/">Utilisez un <strong>outil de génération de
-couverture de code</strong></a>.</li>
-</ol>
-<h2 id="indicateurs-dun-code-pas-terrible-code-smells">Indicateurs d'un code pas terrible (<em>Code smells</em>)</h2>
-<ol>
-<li><strong>Rigidité</strong> : le logiciel est difficile à faire évoluer. Une petite
-modification peut causer une cascade de changements.</li>
-<li><strong>Fragilité</strong> : le logiciel dysfonctionne en plusieurs endroits en
-réponse à un unique changement.</li>
-<li><strong>Immobilité</strong> : vous ne pouvez pas réutiliser une partie du code dans
-d'autres projets car cette opération est risquée ou nécessite un grand
-effort.</li>
-<li><a href="/post/complexite-charge-cognitive/"><strong>Complexité inutile</strong></a>.</li>
-<li><strong>Répétition inutile</strong>.</li>
-<li><strong>Opacité</strong> : le code est difficile à comprendre.</li>
-</ol>
-<h2 id="gestion-des-erreurs">Gestion des erreurs</h2>
-<ol>
-<li><strong>Ne mélangez pas</strong> la gestion des erreurs et le code.</li>
-<li>Utilisez des <strong>Exceptions</strong> au lieu de renvoyer des codes d'erreurs.</li>
-<li><strong>Ne retournez pas <code>null</code></strong>, <a href="/post/mauvaises-pratiques-bugs/">n'utilisez pas <code>null</code> non
-plus</a>.</li>
-<li>Lancer des exceptions <strong>avec du contexte</strong>.</li>
-</ol>
-]]></description>
- <link>https://damien.pobel.fr/post/clean-code</link>
- <guid isPermaLink="true">https://damien.pobel.fr/post/clean-code</guid>
- <category><![CDATA[complexité]]></category>
- <category><![CDATA[métier]]></category>
- <category><![CDATA[qualité]]></category>
- <category><![CDATA[code]]></category>
- <category><![CDATA[bonnes pratiques]]></category>
- <category><![CDATA[traduction]]></category>
- <category><![CDATA[clean code]]></category>
- <category><![CDATA[unit test]]></category>
- <pubDate>Invalid Date</pubDate>
- </item>
</channel>
</rss>
RSS tag
--- "métier.xml.pretty" 2024-03-02 09:58:13.446918879 +0000
+++ "../web/rss/métier.xml.pretty" 2024-03-02 09:58:13.446918879 +0000
@@ -5,9 +5,81 @@
<description><![CDATA[métier]]></description>
<link>https://damien.pobel.fr</link>
<generator>metalsmith-feed</generator>
- <lastBuildDate>Tue, 27 Feb 2024 07:06:24 GMT</lastBuildDate>
+ <lastBuildDate>Sat, 02 Mar 2024 09:57:25 GMT</lastBuildDate>
<atom:link href="https://damien.pobel.fr/rss/métier.xml" rel="self" type="application/rss+xml"/>
<item>
+ <title><![CDATA[La maintenabilité comme critère de décision]]></title>
+ <description><![CDATA[<figure class="object-center bordered">
+ <img loading="lazy" src="/images/660x/shrug.png" alt="Image où il est inscrit
+ ¯\_(ツ)_/¯ qui signifie shrug ou haussement d'épaule.">
+</figure>
+
+<p>En début d'année, j'ai lu <a href="https://www.packtpub.com/product/get-your-hands-dirty-on-clean-architecture-second-edition/9781805128373">Get Your Hands Dirty on Clean Architecture (Second
+Edition)</a>
+de <a href="https://reflectoring.io/authors/tom/">Tom Hombergs</a>. Comme son titre
+l'indique, ce très bon livre traite de la <em>Clean Architecture</em> et plus
+particulièrement de <a href="https://fr.wikipedia.org/wiki/Architecture_hexagonale">l'architecture
+hexagonale</a>. Tout au long
+des quelques 140 pages, l'auteur aborde ce type d'architecture sous différents
+aspects mais il en est un qui revient régulièrement tout en étant le sujet du
+premier chapitre : <strong>la maintenabilité</strong>.</p>
+<p>Une bonne partie de ce premier chapitre peut se résumer par cette expression
+<em>pseudo-mathématique</em> :</p>
+<pre><code class="language-plaintext">maintenabilité >>> tout le reste
+</code></pre>
+<p>Dans <em>tout le reste</em> rentrent les qualités qu'on cherche souvent à atteindre
+dans la construction d'un logiciel par exemple les performances, la
+<em>scalabilité</em>, la robustesse, la flexibilité et bien d'autres… Et comme
+l'explique très bien l'auteur, la maintenabilité a ceci de spécial qu'elle est
+une qualité qui permet d'atteindre toutes les autres. En effet, dès qu'un
+logiciel est maintenable, il est facile à faire évoluer pour atteindre certaines
+qualités dès que le besoin émerge. Évidemment, l'ajout de
+fonctionnalités et la correction des bugs sont également d'autant plus simples que le
+code est maintenable. En d'autres termes, la maintenabilité aide à la fois à
+atteindre des objectifs fonctionnels et non fonctionnels.</p>
+<p>Je formule généralement cette idée de la manière suivante :</p>
+<blockquote>
+<p>Un bon code est un code facile à changer.</p>
+</blockquote>
+<p>Ni plus, ni moins. Jusque là, rien de très original je crois mais ça va mieux en
+le disant 😁</p>
+<p>Dans ce chapitre, Tom Hombergs pousse la réflexion un peu plus loin et notamment
+en énonçant ce qui m'apparaît maintenant comme un corollaire :</p>
+<blockquote>
+<p>Whenever we have to decide between multiple options, we can choose the one
+that makes the code easier to change in the future. No more agonizing between
+different options. We just take the one that increases maintainability the
+most.</p>
+</blockquote>
+<p>ce qui peut se traduire par :</p>
+<blockquote>
+<p>Chaque fois que nous devons choisir entre plusieurs options, nous pouvons
+choisir celle qui rendra le code plus facile à changer dans le futur. Plus
+besoin de se torturer l'esprit entre différentes options. Nous choisissons
+simplement celle qui augmente le plus la maintenabilité.</p>
+</blockquote>
+<p>Quand j'ai lu cette partie, je dois dire qu'une petite lumière s'est allumée
+dans ma tête 💡 J'ai beau être convaincu de l'importance de la maintenabilité
+depuis de nombreuses années maintenant, je n'avais jamais considéré cette
+qualité comme une aide à la décision de manière aussi directe. Et forcément, en
+regardant un peu dans le rétroviseur, je me rends compte qu'appliquer ce
+principe dans certaines décisions aurait potentiellement mener à de meilleurs
+choix.</p>
+<p>Comme souvent avec ce genre de principe général, il s'agit d'un élément parmi
+beaucoup d'autres et comme l'indique Tom Hombergs, le <em>bon</em> choix n'est parfois
+pas celui qui améliore ou conserve la maintenabilité. Néanmoins opter pour ce
+principe par défaut me semble être une bonne approche.</p>
+]]></description>
+ <link>https://damien.pobel.fr/post/la-maintenabilite-comme-critere-de-decision</link>
+ <guid isPermaLink="true">https://damien.pobel.fr/post/la-maintenabilite-comme-critere-de-decision</guid>
+ <category><![CDATA[bonnes pratiques]]></category>
+ <category><![CDATA[métier]]></category>
+ <category><![CDATA[travail]]></category>
+ <category><![CDATA[qualité]]></category>
+ <category><![CDATA[code]]></category>
+ <pubDate>Sat, 02 Mar 2024 00:00:00 GMT</pubDate>
+ </item>
+ <item>
<title><![CDATA[Utils et helper sont sur un bateau…]]></title>
<description><![CDATA[<figure class="object-center bordered">
<img loading="lazy" src="/images/660x/plouf.jpg" alt="Petites vaguelettes
@@ -642,39 +714,5 @@
<category><![CDATA[qualité]]></category>
<pubDate>Fri, 15 Mar 2019 00:00:00 GMT</pubDate>
</item>
- <item>
- <title><![CDATA[Veille de la semaine #11 de 2019]]></title>
- <description><![CDATA[<ul>
-<li><a href="https://dev.to/granze/are-web-components-a-thing-3ae7">Are Web Components a thing?</a> (en) : yes!</li>
-<li><a href="http://neowaylabs.github.io/programming/unix-shell-for-data-scientists/">7 Unix Commands Every Data Scientist Should Know</a> (en) : j'ai même envie de dire que tout·e développeur·se devrait connaître.</li>
-<li><a href="https://www.petermorlion.com/991-2/">Unit Testing Best Practices: 7 Ways to Improve Your Tests</a> (en) : de très bons conseils pour améliorer vos tests</li>
-<li><a href="https://medium.com/@erichiggins/technical-debt-is-like-tetris-168f64d8b700">Technical Debt is like Tetris</a> (en) : excellente analogie et ❤ Tetris (traduction en français dans <a href="/post/dette-technique-partie-tetris/">La dette technique est comme une partie de Tetris</a>)</li>
-<li><a href="https://aweary.dev/fault-tolerance-react/">The Fault in Our Tolerance: Accounting for Failures in React</a> (en) : comment rendre une application React un peu plus résiliente aux potentielles erreurs</li>
-<li><a href="https://tech.decitre.fr/posts/refonte-visuels-produits-1-les-aventuriers-du-coffre-perdu">Refonte de nos 3 millions de visuels produits - Les aventuriers du coffre perdu</a> (fr) : une <em>aventure</em> pleine de rebondissements ;)</li>
-<li><a href="https://mixitconf.org/ticketing">Billetterie MiXiT</a> (fr) : Je devrais pas en faire la publicité, ça réduit mes chances d'être tiré au sort ;) mais MixIT 2019 est vraiment une super conférence.</li>
-<li><a href="https://www.timsommer.be/famous-laws-of-software-development/">Famous laws of Software development</a> (en) : je dirais pas que ce sont des lois, mais elles se vérifient tellement souvent…</li>
-</ul>
-<p>Et un peu hors-sujet :</p>
-<ul>
-<li><a href="http://lapenseeecologique.com/et-si-nous-nous-trompions-de-transition-pour-un-luddisme-ecologique/">Et si nous nous trompions de transition ? Pour un luddisme écologique</a> (fr) : le conditionnel est sans doute de trop…</li>
-</ul>
-<p>(En plus du <a href="/rss.xml">flux RSS global</a>, les billets <em>veille</em>
-et uniquement ceux là sont listés dans le <a href="/rss/veille.xml">flux RSS correspondant</a>)</p>
-]]></description>
- <link>https://damien.pobel.fr/post/veille-semaine-11-2019</link>
- <guid isPermaLink="true">https://damien.pobel.fr/post/veille-semaine-11-2019</guid>
- <category><![CDATA[veille]]></category>
- <category><![CDATA[code]]></category>
- <category><![CDATA[métier]]></category>
- <category><![CDATA[conférence]]></category>
- <category><![CDATA[retour d'expérience]]></category>
- <category><![CDATA[react]]></category>
- <category><![CDATA[unit test]]></category>
- <category><![CDATA[shell]]></category>
- <category><![CDATA[unix]]></category>
- <category><![CDATA[standard]]></category>
- <category><![CDATA[web components]]></category>
- <pubDate>Thu, 14 Mar 2019 11:12:16 GMT</pubDate>
- </item>
</channel>
</rss>
RSS tag fr
--- fr.xml.pretty 2024-03-02 09:58:14.226914871 +0000
+++ ../web/rss/linux/fr.xml.pretty 2024-03-02 09:58:14.230914851 +0000
@@ -5,7 +5,7 @@
<description><![CDATA[linux]]></description>
<link>https://damien.pobel.fr</link>
<generator>metalsmith-feed</generator>
- <lastBuildDate>Tue, 27 Feb 2024 07:06:24 GMT</lastBuildDate>
+ <lastBuildDate>Sat, 02 Mar 2024 09:57:25 GMT</lastBuildDate>
<atom:link href="https://damien.pobel.fr/rss/linux/fr.xml" rel="self" type="application/rss+xml"/>
<item>
<title><![CDATA[Veille de la semaine #19 de 2018]]></title>
URL: https://797.damien.pobel.fr
Stats
Blog Blog | Open | Open | 8073 | 8227 | ❌️ Post | Open | Open | 11252 | 11291 | ❌️ Enhanced tag page (veille) | Open | Open | 8137 | 8176 | ❌️ Tag page pagination (javascript, page 5) | Open | Open | 10084 | 10123 | ❌️ Tag page (lecteur d'écran) | Open | Open | 6166 | 6205 | ❌️ Tags | Open | Open | 27316 | 27359 | ❌️ CV CV fr | Open | Open | 22361 | 22361 | ✅️ CV fr pdf | Open | Open | 110749 | 110749 | ✅️ CV | Open | Open | 21486 | 21486 | ✅️ CV en pdf | Open | Open | 87268 | 87268 | ✅️ Pages Page list | Open | Open | 8192 | 8231 | ❌️ About | Open | Open | 3510 | 3510 | ✅️ Misc Github profile, | Open | Open | 2058 | 2101 | ❌️ Github page, | Open | Open | 10316 | 10355 | ❌️ Photos Resized Photo (660x) | Open | Open | 32036 | 32036 | ✅️ Resized Photo (200x) | Open | Open | 5438 | 5438 | ✅️ RSS feeds (build date should be updated) RSS | Open | Open | 58543 | 53554 | ❌️ RSS tag | Open | Open | 44878 | 46302 | ❌️ RSS tag fr | Open | Open | 34783 | 34783 | ❌️
Diffs
Homepage
Blog
Post
Enhanced tag page (veille)
Tag page pagination (javascript, page 5)
Tag page (lecteur d'écran)
Tags
Page list
Github profile,
Github page,
RSS
RSS tag
RSS tag fr