Je n'ai jamais parlé d'une prod qui casse un vendredi.
Non, une prod, n'implique pas nécessairement un travail en équipe, ni d'astreintes.
Comment tu peux sortir une généralité comme celle-ci ? Tout dépend du contexte.
Quand tu as vu, comme moi des softs hyper critiques être maintenu depuis des années par 1 seul bonhomme (qui est le seul à connaitre le code, la partie métier) à quart de temps dessus et qui n'a jamais eu d'astreinte pour ça...
tu descends un peu de ta tour d'ivoire. (attention : j'ai jamais dit que c'était bien mais c'est un constat)
Je le redis : pour moi, un bon typage c'est une forme de test : si tu touches à un truc qui ne compile plus, ben tu dois le traiter avant de pousser en prod.
Sur des langages ou tout se fait au runtime, on fait de plus en plus d'analyse static en amont.
L'objectif est le même : prévenir plutôt que guérir.
Je n'arrive toujours pas à comprendre ce que tu essayes de démontrer avec le rollback.
Le rollback c'est le joker au cas ou.
Les devs n'auront pas peur de la prod pas parce qu'ils peuvent revenir en arrière 50 fois dans la journée mais parce que leurs déploiements, aussi fréquents soient-ils se passeront dans l'ensemble bien et que les soucis en prod ne seront pas inlassablement de même nature.
Pour moi, c'est un leurre de croire que tout est rollbackable (et par conséquent, c'est dangereux de trop s'appuyer dessus).
T'as plein de cas ou tu ne peux pas te permettre ce luxe.
qlqs exemples loin d'être exhaustif :
- chg en base de donnée conséquente : même si entre la liv et le rollback, il c'est passé 5min, tu as potentiellement des données à migrer et du coût le rollback ne peut pas être simple.
- tu ne maîtrises pas toute la chaîne de production : ton code dépend d'un web service externe qui a upgrade par ex.
- tu as des niveaux de cache : t'es obligé d'invalidé tes caches à chaque livraison/rollback : tu peux faire explosé ta prod en jouant à ça.
Le rollback, pour moi, c'est du travail dans l'urgence.
Tu atténues l'urgence mais y'a quand même quelqu'un qui a appuyé urgemment sur l'interrupteur.
Je n'ai jamais vu ce type de bug arriver dans une prod.
Tu m'aurais dit "rarement", je me serais dit "étonnent" mais soit.
Avec un jamais, je suis partagé entre "mauvaise foi", "déni", "ignorance".
Je te donne un cas sur lequel j'ai été confronté mille fois (et qui est proprement traité en Rust) : https://fr.wikipedia.org/wiki/Charles_Antony_Richard_Hoare#R.C3.A9flexions_sur_la_programmation
Qu'un objet (structure de données) puisse être vide par défaut et que l'on ne vérifie sa nullité qu'au runtime a énormément d'incidence.
Maintenant, tu extrapoles sur des structures complexes avec énormément d'imbrications (et qui ont tendance à changer régulièrement) et pour résoudre tous les cas potentiels de bugs, tu te rends vite compte que tu es proche de l’explosion combinatoire.
Quand il dit "bug à 1 milliard", je crois qu'il est en dessous de la réalité.
Ce qui est certain, c'est qu'à l'heure des libs/frameworks, ces soucis de typage ne nous saute pas forcément aux yeux juste en lisant la tracktrace.
C'est bien plus sournois mais ça n'empêche que le fond du problème vient de là.
Je vois aussi que beaucoup de frameworks pour des langages faiblement typés ont tendance à atténuer ces soucis parce qu'ils font le travail à notre place.
C'est un moyen détourné qui entraîne d'autres dérives (à mon sens).
Par exemple, sur la stack javascript, utiliser des frameworks obligent npm et donc une foison de dépendances (et dépendances tiers).
Cette dérive est en partie dût à la qualité déplorable du typage du langage et la monté de TypeScript et cie n'y es pas étranger.
En client/serveur toujours, on parle de plus en plus d'isomorphisme.
Ça soulève bien un soucis de typage pour moi : la capacité de partager une structure de donnée sans faux raccord.
[^] # Re: rust
Posté par mothsART . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 1. Dernière modification le 15 mai 2020 à 12:08.
Je n'ai jamais parlé d'une prod qui casse un vendredi.
Non, une prod, n'implique pas nécessairement un travail en équipe, ni d'astreintes.
Comment tu peux sortir une généralité comme celle-ci ? Tout dépend du contexte.
Quand tu as vu, comme moi des softs hyper critiques être maintenu depuis des années par 1 seul bonhomme (qui est le seul à connaitre le code, la partie métier) à quart de temps dessus et qui n'a jamais eu d'astreinte pour ça...
tu descends un peu de ta tour d'ivoire. (attention : j'ai jamais dit que c'était bien mais c'est un constat)
Je le redis : pour moi, un bon typage c'est une forme de test : si tu touches à un truc qui ne compile plus, ben tu dois le traiter avant de pousser en prod.
Sur des langages ou tout se fait au runtime, on fait de plus en plus d'analyse static en amont.
L'objectif est le même : prévenir plutôt que guérir.
Je n'arrive toujours pas à comprendre ce que tu essayes de démontrer avec le rollback.
Le rollback c'est le joker au cas ou.
Les devs n'auront pas peur de la prod pas parce qu'ils peuvent revenir en arrière 50 fois dans la journée mais parce que leurs déploiements, aussi fréquents soient-ils se passeront dans l'ensemble bien et que les soucis en prod ne seront pas inlassablement de même nature.
Pour moi, c'est un leurre de croire que tout est rollbackable (et par conséquent, c'est dangereux de trop s'appuyer dessus).
T'as plein de cas ou tu ne peux pas te permettre ce luxe.
qlqs exemples loin d'être exhaustif :
- chg en base de donnée conséquente : même si entre la liv et le rollback, il c'est passé 5min, tu as potentiellement des données à migrer et du coût le rollback ne peut pas être simple.
- tu ne maîtrises pas toute la chaîne de production : ton code dépend d'un web service externe qui a upgrade par ex.
- tu as des niveaux de cache : t'es obligé d'invalidé tes caches à chaque livraison/rollback : tu peux faire explosé ta prod en jouant à ça.
Le rollback, pour moi, c'est du travail dans l'urgence.
Tu atténues l'urgence mais y'a quand même quelqu'un qui a appuyé urgemment sur l'interrupteur.
Tu m'aurais dit "rarement", je me serais dit "étonnent" mais soit.
Avec un jamais, je suis partagé entre "mauvaise foi", "déni", "ignorance".
Je te donne un cas sur lequel j'ai été confronté mille fois (et qui est proprement traité en Rust) : https://fr.wikipedia.org/wiki/Charles_Antony_Richard_Hoare#R.C3.A9flexions_sur_la_programmation
Qu'un objet (structure de données) puisse être vide par défaut et que l'on ne vérifie sa nullité qu'au runtime a énormément d'incidence.
Maintenant, tu extrapoles sur des structures complexes avec énormément d'imbrications (et qui ont tendance à changer régulièrement) et pour résoudre tous les cas potentiels de bugs, tu te rends vite compte que tu es proche de l’explosion combinatoire.
Quand il dit "bug à 1 milliard", je crois qu'il est en dessous de la réalité.
Ce qui est certain, c'est qu'à l'heure des libs/frameworks, ces soucis de typage ne nous saute pas forcément aux yeux juste en lisant la tracktrace.
C'est bien plus sournois mais ça n'empêche que le fond du problème vient de là.
Je vois aussi que beaucoup de frameworks pour des langages faiblement typés ont tendance à atténuer ces soucis parce qu'ils font le travail à notre place.
C'est un moyen détourné qui entraîne d'autres dérives (à mon sens).
Par exemple, sur la stack javascript, utiliser des frameworks obligent npm et donc une foison de dépendances (et dépendances tiers).
Cette dérive est en partie dût à la qualité déplorable du typage du langage et la monté de TypeScript et cie n'y es pas étranger.
En client/serveur toujours, on parle de plus en plus d'isomorphisme.
Ça soulève bien un soucis de typage pour moi : la capacité de partager une structure de donnée sans faux raccord.
Je ne fait pas que de l'antithèse.