En fait, barmic, tu construis ton argumentaire autours de plusieurs postulats qui ne sont pas forcément vrai.
C'est toi qui parle d'une prod qui casse un vendredi à 18h. Le fait d'avoir une prod implique beaucoup de choses (la presque obligation légale d'être en équipe - tu n'a pas le droit d'être en astreinte 24/7 -, le fait qu'il s'agisse d'un service,...) que tu es entrain de remettre en cause dans ce commentaire.
Je pense plutôt qu'il y a une constante : n'importe quel boite souhaite la meilleur qualité et donc des salariés le plus compétents possibles, agiles, volontaires etc.
Je ne suis pas du tout d'accord. La plupart des boites ne savent pas ce qu'est et se foutent de la qualité logiciel. C'est simple elles ne la définissent pas. Parce que c'est une notion complexe et ça peut devenir très chère. Donc non la plupart veulent le niveau suffisant de qualité pour ne pas être trop emmerdé et que ça ne coûte pas trop chère.
Mon constat c'est que beaucoup de choses "critiques" (les fameuses 500 qui font tant plaisir) peuvent être évités en amont avec du typage, du pattern matching et de l'immutabilité.
J'ai vu des projets utilisant les même techno à des niveaux de résilience et de correction très différents et c'est la qualité des tests qui les départagées. Bien sûr le contexte joue sur la qualité des tests, mais c'est mécanique : tu test, ça marche, tu test pas, ça ne marche pas.
La simplicité du rollback, c'est bien mais faut pas que ça devienne une solution de facilité.
Bien entendu qu'il est impossible de livrer en prod sans un dérapage mais ce qui me semble plus important que le rollback en lui-même c'est les mesures prisent après rollback :
pourquoi c'est arrivé et comment on évite à l'avenir.
Avec ça, on réduit leur fréquence graduellement et on peut se permettre d'éviter des dettes techniques : maj des libs régulières, refacto etc.
Je ne suis pas d'accord. Évidement que tu va réfléchir à ce qui s'est mal passé en cas de rollback sinon tu ne livre plus. Ça n'est pas une question de bonne pratique, c'est mécanique. La capacité de rollback c'est ce qui te permet de ne pas avoir peur de ta prod. Les projets qui ont peur de leur prod accumulent de la dette. Les projets qui n'en n'ont pas peur vont se permettre de mettre en prod plus régulièrement donc vont déployer.
En plus, il y a tellement de cas ou un rollback n'est pas possible (ou que celui-ci a un coût) que de s'appuyer dessus c'est le désastre assuré.
Donc tu dis, « bon désolé mais si on a raté quelque chose, tout sera cassé jusqu'au prochain fix ou desaster recovery pour pouvoir remonter des données cohérentes ». Ça tu peut le faire quand tu as des SLA très petites, que la valeur de ta prod est plus faible que celle de ton dev et/ou que tu a le goût du risque. Il arrive qu'on ne puisse pas le faire, mais c'est un défaut à assumer (se préparer à faire un desaster recovery ou un hotfix en urgence. Travailler dans l'urgence, perso j'évite autant que possible.
Reproduire, c'est souvent 90% du taf et quand je fais le constat amer d'avoir passé des heures a arriver à reproduire un bug qui est lié à du typage, ça me fait rager parce que je sais qu'il pouvait être évité en amont.
Je n'ai jamais vu ce type de bug arriver dans une prod. Je ne connais pas tout, hein, mais ça ne m'est jamais arrivé. Du moins dans ce qui est classiquement le rôle du typage. Donc pas les types dépendants par exemple qui s'approche presque plus de la preuve de programme.
Néanmoins, je pense que l'apprentissage de Rust m'a permis de m'améliorer sur plein de sujets et je recommande vivement de sortir de sa zone de confort avec ce genre de langage.
Je n'ai jamais remis ça en cause. Ni les qualités intrinsèques de rust. Comprendre et jouer avec une variété de langage est très enrichissant. Regarder du coté de rust, de lisp, de smalltalk,... C'est très enrichissant, pour comprendre et utiliser le langage que tu utilise au quotidiens.
[^] # Re: rust
Posté par barmic 🦦 . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 3.
C'est toi qui parle d'une prod qui casse un vendredi à 18h. Le fait d'avoir une prod implique beaucoup de choses (la presque obligation légale d'être en équipe - tu n'a pas le droit d'être en astreinte 24/7 -, le fait qu'il s'agisse d'un service,...) que tu es entrain de remettre en cause dans ce commentaire.
Je ne suis pas du tout d'accord. La plupart des boites ne savent pas ce qu'est et se foutent de la qualité logiciel. C'est simple elles ne la définissent pas. Parce que c'est une notion complexe et ça peut devenir très chère. Donc non la plupart veulent le niveau suffisant de qualité pour ne pas être trop emmerdé et que ça ne coûte pas trop chère.
J'ai vu des projets utilisant les même techno à des niveaux de résilience et de correction très différents et c'est la qualité des tests qui les départagées. Bien sûr le contexte joue sur la qualité des tests, mais c'est mécanique : tu test, ça marche, tu test pas, ça ne marche pas.
Je ne suis pas d'accord. Évidement que tu va réfléchir à ce qui s'est mal passé en cas de rollback sinon tu ne livre plus. Ça n'est pas une question de bonne pratique, c'est mécanique. La capacité de rollback c'est ce qui te permet de ne pas avoir peur de ta prod. Les projets qui ont peur de leur prod accumulent de la dette. Les projets qui n'en n'ont pas peur vont se permettre de mettre en prod plus régulièrement donc vont déployer.
Donc tu dis, « bon désolé mais si on a raté quelque chose, tout sera cassé jusqu'au prochain fix ou desaster recovery pour pouvoir remonter des données cohérentes ». Ça tu peut le faire quand tu as des SLA très petites, que la valeur de ta prod est plus faible que celle de ton dev et/ou que tu a le goût du risque. Il arrive qu'on ne puisse pas le faire, mais c'est un défaut à assumer (se préparer à faire un desaster recovery ou un hotfix en urgence. Travailler dans l'urgence, perso j'évite autant que possible.
Je n'ai jamais vu ce type de bug arriver dans une prod. Je ne connais pas tout, hein, mais ça ne m'est jamais arrivé. Du moins dans ce qui est classiquement le rôle du typage. Donc pas les types dépendants par exemple qui s'approche presque plus de la preuve de programme.
Je n'ai jamais remis ça en cause. Ni les qualités intrinsèques de rust. Comprendre et jouer avec une variété de langage est très enrichissant. Regarder du coté de rust, de lisp, de smalltalk,... C'est très enrichissant, pour comprendre et utiliser le langage que tu utilise au quotidiens.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll