Quand faut-il laisser un commentaire à l'intérieur du code?
- un besoin business incongru (expliquez l'histoire originel)
- cela a demandé des recherches (partagez des liens)
- plusieurs options étaient considérées (justifiez)
- question dans une revue de code
Un excellent article sur la manière de conduire un refactor sur le long terme.
Un autre article clean-archi / archi hexagonale.
Celui la met l'accent sur les problèmes des architectures classiques ou le métier est "mélangé" avec les couches d'API et de persistence et sur la solution de cloisonnement qu'apporte l'architecture hexagonale.*
Les principes les plus importants:
- le domaine ne dépend que de lui même
- pas de framework dans le domaine
- inversion de contrôle via notamment l'injection de dépendances
- commencer par le domaine (et les tests associés!)
Une explication de l'architecture hexagonale avec un exemple simple de catalogue de produit en Typescript.
Un manifest qui va dans le sens du KISS (Keep It Simple, Stupid)
Mes préférés:
Synthesis is the key of communication. We have to write code for humans not machines.
Keep it plain. Try to keep your designs with few layers of indirection.
Le service de scan de vulnérabilité et de qualité de code LGTM s'arrête le 16 décembre 2022.
Ils se sont fait intégré aux équipes de Github depuis 3 ans et leur moteur d'analyse de code est maintenant intégré complètement à Github: CodeQL
Pour l'utiliser, il faut mettre en place cette Github Action
Il ne faut pas toujours chercher à rendre le code clean avec des abstractions et en évitant les répétitions.
Souvent cela rend le code plus complexe et donc plus difficile à maintenir.
La est toutes la subtilité du métier de développeur, trouver le bon compromis entre clean code et KISS code (Keep It Simple and Stupid).
L'auteur pointe aussi une autre erreur, de gestion d'équipe, il a refactoré le code d'un collègue sans lui en parler avant.
Un site qui regroupe les anti-patterns de nommage des variables.
Par exemple, une fonction qui s'appelle getXXX mais qui ne retourne rien dans certains cas et mute directement un argument.
C'est plein de bon sens et à lire en complément de la recherche sur le naming des variables
Un article très complet sur les bonnes pratiques lors du développement d'une app Flutter.
Points abordés:
- linters
- utilisation de l'IDE pour refacto
- différents types de tests (et les Golden Tests propres à Flutter)
- code coverage
- CI/CD
- mesurer la qualité du code
Un article sur l'architecture hexagonale qui explique notamment la distinction entre port et adapter.
L'auteur fait aussi un commentaire intéressant I’ve never applied these architectures to the letter, though.
Comme pour tout, il faut éviter de rentrer dans une application dogmatique de tel ou tel architecture, process, etc
L'architecture hexagonale offre un excellent moyen de structurer son code en modules indépendants mais elle doit être utilisée avec un regard critique et peut être contournée lorsque cela s'avère nécessaire.
Excellent guide dont je recommande la lecture à tout développeur Node.js ;-)
Mon top:
Un article qui va dans le sens inverse de la tendance actuelle autour de l'utilisation des Hooks dans React.
L'auteur disserte sur le non respect des principes SOLID par les Hooks et sur les problèmes de dettes technique que cela créé.
Les Hooks sont vraiment quelque chose d'étrange, ils ne respectent pas la programmation fonctionnelle, ni la programmation objet.
Ce sont juste des helpers pour écrire et lire de la donnée dans une sorte de gros objet global, l'avantage avec le système de props étant qu'on n'a pas besoin de les passer entre chaque composant.
Très bon explication sur les différences entre les Map et les POJO en Javascript.
En substance:
- utilisez les POJO lorsque le nombre de clé est connu d'avance et en tant que Data Transfer Object (DTO)
- utilisez les
Mappour tout ce qui s'apparente à un cache RAM et nécessite des insertions/deletions arbitraires
Lorsqu'elle sont bien utilisées, les Map auront une meilleure performance, utilisent moins de RAM et offre une meilleure API plus complète POJO (e.g. Map.clear) au prix d'une perte en DX (e.g. initialisation, spread operator)
La chercheuse résume son travail dans la vidéo de 10 minutes à la fin de l'article.
Elle a développé un concept de "linguistics smell" pour parler de l'épineux problème du naming qui accroît la complexité du code.
2 conseils simples:
- avoir des noms qui respectent leurs promesses (
isValidest un booléen,customerscontiens plusieurs éléments, etc) - se mettre d'accord sur une structure (les dates se terminent par
at, les quantifieurs sont à la fin, pas d'abreviation, etc)
Excellent article sur les erreurs les plus communes faites par les équipes de dev.
La plus importante pour moi est aussi celle que j'ai mis le plus longtemps à apprendre: écrire du code clair, pas du code intelligent
En règle général il vaut mieux éviter les commentaires dans le code, à la place écrivez du code auto-explicatif (nom des variables, des fonctions)
À l'intérieur des fonctions, les (rares) commentaires doivent donner des informations de contexte impossible à deviner.
Les commentaires restant doivent de préférence être en en-tête des fonctions et très bien rédigés pour être vraiment utiles.