En fait, barmic, tu construis ton argumentaire autours de plusieurs postulats qui ne sont pas forcément vrai.
tout le monde ne travaille pas en équipe ou si c'est le cas en inter-dépendance.
une mise en prod n’inclus pas foncièrement un déploiement complexe : à la base, on parle d'un soft en cli donc le déploiement c'est création d'un exécutable.
tous les projets ne sont pas forcément orienté "software as a service".
dans une grande structure, tu as souvent une panoplies de rôles : dba, admin sys, devops, archi etc.
certaines responsabilités porté par des devs dans certaines boites ne le sont pas dans d'autres
les devs ne choisissent que rarement la stack (ou l'intégralité), langage y compris.
un worflow tel que tu le décris (canary release, AB test) a un coût matériel et humain loin d'être négligeable.
c'est quoi un bon dev ? C'est tellement subjectif.
Un workflow bien millimétré, ça nécessite d'embaucher des gens qualifiés (ou les former) donc on peut les classer dans la case des "bons devs".
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.
et que ce facteur humain va dépendre de leur porte feuille, du processus d'embauche, d'un brin de chance etc.
Tout dépend de ce que tu produits.
Si le dev en question nécessite d'avoir des connaissances métiers très pointus (par exemple médical), le bon dev sera un mélange entre qualité technique et connaissances en rapport.
Si le dev doit interagir avec de la donnée : il faut qu'il soit pointu en SQL, elasticSearch etc sinon la qualité ne pourra pas être au rendez-vous.
Si ça nécessite des connaissances mathématiques, il aura beau savoir suivre un worflow de dingue, ça ne suffira pas.
J'ai et j'ai eu l'occasion de travailler sur des projets seul, avec des petites et des grandes équipes : worflow de malade, dev à l'arrache, langage compilé, interprété, fortement typé ou non.
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é.
Ca veut pas dire qu'on peut pas faire des erreurs de typage avec un langage fortement typé, (genre mettre un string là ou on attend un entier et caster comme un porc un peu partout)
mais on limite vachement les risques, c'est mathématique.
Mieux que ça : dev avec des grosses contraintes m'a mis le nez sur des soucis que je n'aurais jamais anticipé avant.
J'en conçoit, ça n'évite pas les bugs logiques, fonctionnels, métier mais c'est quand même plus valorisant de se concentrer que la dessus, non ?
Il n'est pas impossible d'avoir des erreurs au runtime en Rust (d'ailleurs, aucun langage ne les évites intégralement) mais faut déjà sacrément pousser pour y arriver alors qu'avec d'autres langages, c'est d'une facilité déconcertante.
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.
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é.
Faut avoir un outil de rollback simple mais coder comme si il était impossible.
[quote]
C'est parce que les tests sont écrit par un autre développeur (entre autre) que tu obtiens de la qualité.
[/quote]
Bon, y'a une variété de tests qui existent, je ne t'apprend rien.
Un test pour moi, c'est une forme de doc : ça dit à un instant T ce que ton soft fait ou ne fait pas.
Tout ce qui n'est pas testé n'est pas contractuel.
Je ne vois pas en quoi faire un écrire un test par quelqu'un d'autre que le dev de la fonctionnalité change quoi que ce soit.
La review de code (si c'est possible avec une hiérarchie de reviewer), le pair programming et inclure le code des tests dans cette relecture me semble bien plus vital.
Un reviewer "senior" qui te drive en te disant qu'il manque tel test ou que ce dernier ne sert à rien, n'aura sans doute pas écrit le code mais ce sera tout comme.
Autre constat, plus tu as de doc et moins tu as de chance que ça soit lu, compris, assimilé par tous.
Comme dis, avoir la même rigueur avec un langage interprété nécessite de faire des tests de typage.
Ca prend du temps, ça n'apporte pas grand chose et ça parasite la doc.
Enfin, quand on a un soucis en prod, tu le sais aussi bien que moi, l'enjeu c'est souvent de reproduire.
Limite, c'est un autre métier.
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 suis bien conscient que dans 10 ans je tomberais encore sur les bugs les plus habituels : date, encodage, dépendances etc. mais je ferais tout pour que ça ne soit pas mon cœur de métier.
En toute franchise, je me considère pas comme le meilleur dev, loin de là : j'écris pas en dvorak avec du 150 MPM, je passe souvent par l'étape papier avant de sortir du syndrome de la page blanche.
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.
Ca m'a permis de voir certaines choses soit disant acquises avec un autre regard : par exemple la POO.
[^] # Re: rust
Posté par mothsART . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 6. Dernière modification le 14 mai 2020 à 13:58.
En fait, barmic, tu construis ton argumentaire autours de plusieurs postulats qui ne sont pas forcément vrai.
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.
et que ce facteur humain va dépendre de leur porte feuille, du processus d'embauche, d'un brin de chance etc.
Tout dépend de ce que tu produits.
Si le dev en question nécessite d'avoir des connaissances métiers très pointus (par exemple médical), le bon dev sera un mélange entre qualité technique et connaissances en rapport.
Si le dev doit interagir avec de la donnée : il faut qu'il soit pointu en SQL, elasticSearch etc sinon la qualité ne pourra pas être au rendez-vous.
Si ça nécessite des connaissances mathématiques, il aura beau savoir suivre un worflow de dingue, ça ne suffira pas.
J'ai et j'ai eu l'occasion de travailler sur des projets seul, avec des petites et des grandes équipes : worflow de malade, dev à l'arrache, langage compilé, interprété, fortement typé ou non.
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é.
Ca veut pas dire qu'on peut pas faire des erreurs de typage avec un langage fortement typé, (genre mettre un string là ou on attend un entier et caster comme un porc un peu partout)
mais on limite vachement les risques, c'est mathématique.
Mieux que ça : dev avec des grosses contraintes m'a mis le nez sur des soucis que je n'aurais jamais anticipé avant.
J'en conçoit, ça n'évite pas les bugs logiques, fonctionnels, métier mais c'est quand même plus valorisant de se concentrer que la dessus, non ?
Il n'est pas impossible d'avoir des erreurs au runtime en Rust (d'ailleurs, aucun langage ne les évites intégralement) mais faut déjà sacrément pousser pour y arriver alors qu'avec d'autres langages, c'est d'une facilité déconcertante.
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.
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é.
Faut avoir un outil de rollback simple mais coder comme si il était impossible.
[quote]
C'est parce que les tests sont écrit par un autre développeur (entre autre) que tu obtiens de la qualité.
[/quote]
Bon, y'a une variété de tests qui existent, je ne t'apprend rien.
Un test pour moi, c'est une forme de doc : ça dit à un instant T ce que ton soft fait ou ne fait pas.
Tout ce qui n'est pas testé n'est pas contractuel.
Je ne vois pas en quoi faire un écrire un test par quelqu'un d'autre que le dev de la fonctionnalité change quoi que ce soit.
La review de code (si c'est possible avec une hiérarchie de reviewer), le pair programming et inclure le code des tests dans cette relecture me semble bien plus vital.
Un reviewer "senior" qui te drive en te disant qu'il manque tel test ou que ce dernier ne sert à rien, n'aura sans doute pas écrit le code mais ce sera tout comme.
Autre constat, plus tu as de doc et moins tu as de chance que ça soit lu, compris, assimilé par tous.
Comme dis, avoir la même rigueur avec un langage interprété nécessite de faire des tests de typage.
Ca prend du temps, ça n'apporte pas grand chose et ça parasite la doc.
Enfin, quand on a un soucis en prod, tu le sais aussi bien que moi, l'enjeu c'est souvent de reproduire.
Limite, c'est un autre métier.
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 suis bien conscient que dans 10 ans je tomberais encore sur les bugs les plus habituels : date, encodage, dépendances etc. mais je ferais tout pour que ça ne soit pas mon cœur de métier.
En toute franchise, je me considère pas comme le meilleur dev, loin de là : j'écris pas en dvorak avec du 150 MPM, je passe souvent par l'étape papier avant de sortir du syndrome de la page blanche.
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.
Ca m'a permis de voir certaines choses soit disant acquises avec un autre regard : par exemple la POO.