Des conseils trop évidents pour qu'on les suive tous à la lettre

ChatGPTLe **Brutalist Programming Manifesto** prône une approche minimaliste et pragmatique du développement logiciel. Voici ses points clés :

1. **Simplicité avant tout** : Préférer des solutions simples et courtes, même si cela nécessite de simplifier le problème. La complexité n'est pas un signe de compétence, mais un défaut.
2. **Résoudre des problèmes concrets** : Créer des applications pour répondre à des besoins immédiats, plutôt que des frameworks pour des problèmes hypothétiques futurs.
3. **Humilité** : Ne pas se croire plus intelligent que les autres. L'expérience vient de l'échec, et la maîtrise est intuitive.
4. **Autonomie** : Éviter de dépendre de bibliothèques ou de codes externes pour rester maître de son propre code et de sa maintenance.
5. **Robustesse** : Écrire du code capable de fonctionner sur du matériel vieux de 10 ans ou encore en usage dans 10 ans, en privilégiant des langages comme le C.
6. **Ne pas croire à une sécurité totale** : Accepter que la sécurité informatique parfaite est impossible à atteindre.
7. **Utilisation des bons outils** : Adapter l'interface utilisateur aux besoins, en évitant les solutions purement idéologiques.
8. **Éviter les ornements** : Exclure les animations et le design superflu pour se concentrer sur l'efficacité et la simplicité.
9. **Les outils ne sont que des outils** : Ne pas devenir dépendant d'outils, mais privilégier la réflexion et des formats simples comme le texte brut.
10. **Humble perspective** : Ne pas chercher une performance ou une scalabilité démesurée, rester pratique et réaliste.
11. **Ne pas travailler gratuitement sans plaisir** : S'assurer que le travail apporte de la satisfaction ou une compensation.
12. **Ne pas suivre aveuglément** : Remettre en question les méthodologies et ne suivre que ce qui est utile dans un contexte donné.

En résumé, ce manifeste défend un développement logiciel centré sur la simplicité, l'efficacité, et une indépendance face aux tendances ou aux complexités inutiles.

Même résumé, c'est encore trop long à lire ... 😐

Résumé bref : faites le contraire de ce que les cadres demandent.

1. **Simplicité avant tout** :
Oui c'est l'idéal, on est d'accord. Mais on va toujours tomber sur des cas particulier qui vont demander d'être traité en tant que tel.
On atteint toujours rapidement 90 ou 95% de la solution, c'est toujours les 5-10% restant qui demandent beaucoup plus de temps, car c'est plein de cas particuliers.

2. **Résoudre des problèmes concrets** :
Oui mais si on n'avait pas inventés tous ces frameworks, ça serait quand même bien la galère.
Si on n'avait ni bootstrap, ni Django, et aujourd'hui React ou Angular (material design) pour faire des sites web, ça serait la galère à chaque fois.
Ou si on n'avait pas un/des framework(s) pour faire des applications windows...

3. **Humilité** :
Le problème est souvent derrière le clavier 😁

4. **Autonomie** :
Dès que tu utilises un framework (PHP, JS, C#, Java), c'est mort, mais ce n'est justement presque plus possible sans.
Tu veux vraiment refaire toutes tes pages HTML et toutes tes fonctions JS à la main? A chaque fois?

5. **Robustesse** :
MWAHAHAHAHAHAHAHAHAHAHAHAHAHAH! Du C! 😁😁😁😁😁😁😁😁

6. **Ne pas croire à une sécurité totale** :
D'accord, pour ça qu'au boulot, on n'a pas droit aux souris sans fils, aux claviers sans fils et aux headset sans fils.

...

J'ai bossé sur un projet qui avait 2 produits, l'un en React et l'autre en Vanilla JS. Les devs précédents avaient tellement détestés le projet React qu'ils avaient décidé de repartir de zéro et de faire simple. Résultat, quand j'ai dû maintenir et faire évoluer les 2, j'avais un code base complexe mais fait en create-react-app, avec la doc de CRA et de React disponible si besoin. Et un code base avec des fichiers qui avaient étaient simples à l'origine, puis qui s'étaient complexifiés au point de devenir une sorte de micro framework custom, bien sûr sans doc et sans maintenance open source. La morale de l'histoire c'est que c'est pas si mal un bon framework, tendance, maintenu et documenté 😅.

L'avantage d'un bon framework (ou même un mauvais, cela dit), c'est la familiarité qu'on peut avoir avec le framework, ce qui facilite la lecture et la compréhension du code mais aussi sa modification. Le problème, c'est qu'on a souvent tendance à vouloir utiliser un framework même pour des choses "simples", et que le framework (qu'on utilisera peut-être qu'une seule fois) est généralement plus complexe à adopter/assimiler qu'une base de code propre. On se retrouve alors à passer plus de temps pour se familiariser avec le framework que si on avait fait sans. Choisir un bon framework est aussi complexe, car aucun framework ne couvre "tous les use-cases" et dès qu'on commence à sortir de ce qui est initialement prévu, ça devient compliqué (et le code devient vite horrible et surtout, nettement moins accessible même pour les utilisateurs familiarisés avec le framework). C'est une "dette technique" assez habituelle, mais souvent sous-estimée.

Mais ici, le manifeste, ce n'est pas vraiment à propos de choisir ou non d'utiliser un framework, mais plutôt la fâcheuse tendance qu'ont les "bons" développeurs (du moins, ceux qui sont à l'aise avec le langage et n'hésitent pas à cracher des lignes de code à tout va) de vouloir généraliser systématiquement le moindre bout de code et, plutôt que de se concentrer sur ce qui est nécessaire pour réaliser une tâche spécifique, vont plutôt se concentrer sur la généricité et faire de la tâche un cas particulier. Et ca rend le code plus difficile à comprendre, plus difficile à maintenir, et souvent, quand la tâche "spécifique" évolue un peu, on doit commencer à contourner le framework parce que le moindre changement pourrait invalider l'approche générique qu'on avait tenté d'implémenter. Je suis expert dans ce genre de mauvais choix J'ai du mal à envisager de faire un code qui ne sert "qu'à moi" pour "mon problème", et je me retrouve à complexifier inutilement le raisonnement et la base de code. Mais parfois, ça marche, et cette base devient une librairie réutilisable qui évolue dans son coin comme une grande par la suite, alors que je n'en ai plus besoin personnellement

Je suis devenu convaincu qu'il faut un framework ou une lib assez structurante pour éviter les codes customs.
Ce que tu appelles une base de code propre, c'est très subjectif. J'ai bossé sur un projet où un lead dev faisait tout en DDD custom, avec ses propres conventions dont il ne voulait pas en démordre. J'aurais, je crois, préféré utiliser un framework backend auquel je peux me référer à de la doc ou poser des questions précises à une IA.

J'utilise Next depuis plusieurs années et je ne peux pas m'en plaindre. Il permet de faire du React sans perdre du temps au démarrage, de bénéficier d'un mécanisme simple de routage, d'avoir des layouts, du style, du lint, etc.. Pour plein de choses, on ne perd pas de temps à réinventer la roue. J'adore prettier par exemple, qui fait qu'un code n'a qu'une seule façon d'être indenté. Plus de débat entre dev à n'en plus finir là dessus.
Comme il est très répandu, c'est très facile de trouver de la doc d'une autre lib et de poser la question "comment intégrer la lib dans Next". Rails ou Django sont encore plus prescripteurs et je pense que je me sentirais plus bridé, mais ceux qui l'utilisent peuvent aller très vite avec. Dès que tu veux onboard un nouveau dev, il prend ses marques très vite.

Je pense que c'est très formateur d'essayer de rendre les choses génériques. Mais aussi très compliqué. Ne serait-ce qu'en Typescript, quand tu essaies de typer une lib que tu construis, c'est beaucoup plus difficile qu'une app. Bien placer le curseur entre code spécifique et code générique est un exercice hyper difficile, un dilemme de plus de la vie de développeur. Difficile d'avoir l'esprit clair quand tu veux refactor quelque chose. Est-ce que cet "extra mile" que je veux faire vaut le coup ou est-ce que je ne suis pas en train de me faire plaisir ?