@thorstenball "Good code" stays, I'd bet. Coupling, complexity, dead branches, unclear intents will hinder any mind reading or changing code, meat or chips.
Thankfully the only thing I hate more than mutating a state is having to use a monad or build a GenServer-backed spaceship where a simple `i++` would have worked.
Deployment time is almost always a factor of the risk you are prepared to tolerate in your release process. I.e. go faster by having less validation. The other factor is the efficiency of your risk mitigation (tests adhering to the pyramid, parallelism). Are there other factors?
@GuLhe_le_GuJ C'est très possible qu'ils zapent la tz en input et qu'ils la parsent juste direct dans leur locale, en effet. Full disclosure on avait exactement ce bug-là sur notre API et c'est moi qui l'ai corrigé quand on nous l'a rapporté, c'est pour ça que je savais que Z c'était UTC.
Grasping at straws: Why "performative, scolding environmentalism [e.g., banning plastic straws] that is disconnected from the scale of the problems it claims to address" is not an effective way of meeting environmental challenges. https://t.co/J1kE6g4NkX
@GuLhe_le_GuJ A voir absolument sur le sujet: What We Actually Know About Software Development, and Why We Believe It's True - https://t.co/xo2TNhq8xw (passage sur les CR à 33:20 mais mate tout, must-see absolu)
Aussi https://t.co/NbcgMwNxcs et accessoirement https://t.co/BeYHDHH6AG
@GuLhe_le_GuJ J'pense le coeur de combat c'est les PR obligatoires (sur Github, Gitlab ou autre) pour les Code Reviews. Une fois que t'as ça automatiser les builds/restrictions ça se fait très vite. Pour convaincre: La recherche montre que les CR attrapent plus de bugs que les tests unitaires
@GuLhe_le_GuJ Chez nous on a les 2 (+ auto-deploy quand le build master est green), donc tout changement passe au moins 2 builds: 1 sur la branche, 1 sur master. Le build branche n'attrape pas tout mais l'auto-build master fait que master ne reste jamais rouge très longtemps. Je recommande :)
@GuLhe_le_GuJ Aussi build auto sur tous les push sur toutes les branches (via Git hook) + Pull Request systématique avant tout merge sur master (via Github, Gitlab...) + Hooks pour rapporter le statut du build sur la PR + Bloquer le merge sur les PR dont le dernier commit n'a pas de build vert
@GuLhe_le_GuJ Pour moi qui mettait toujours toute ma validation dans le serveur (éventuellement dupliquée dans le client pour l'ergonomie, ce qui me frustre tjrs), jouer avec ce genre d'appli a été une petite révélation: une grosse part de ma validation peut se faire seulement dans le client.
@GuLhe_le_GuJ Dans ce cas-là ta validation côté serveur peut se limiter à du contrôle d'accès: qui peut lire/écrire quoi. Ça se complique sur les données à ownership partagé, mais sur bcp d'applis t'en as peu voire pas.
@GuLhe_le_GuJ Quand tu ne peux pas tout mettre dans le backend, tu réalises le peu de validation vraiment "sécurité", qui sauve l'utilisateur des autres et nécessite du backend, et combien sauve simplement l'utilisateur de lui-même, auquel cas le client fait bien l'affaire.
@GuLhe_le_GuJ Un exercice amusant sur la validation c'est de coder une appli client riche (PWA par exemple) avec une DB accessible par le client comme Firestore, sans backend, juste un set limité de security rules.
I'm delighted at the evolution of the Javascript ecosystem these last few years. It's like React, Redux, CommonJS and ES6 have turned the "bad parts" wasteland you avoided like plague into a harmonious realm of functional patterns and immutable designs.