J'ai des cas de figure où acheter le matos pour pouvoir
Je ne répondrais pas à la Zenitramerie qui consiste à trouver les contre exemples.
Un autre cas de figure est où la criticité de la chose n'est pas importante
Ce n'est pas vraiment une question de criticité. Pour les trucs critiques les procédures et le type de test sont différentes et complémentaire. C'est d'ailleurs pour ca que la QA, les test engineers et le release engineering existent.
le time to market (vaut mieux un truc buggué à l'heure qu'un truc non buggé dans un marché déjà saturé par les autres)
La troisième version c'est il vaut mieux un truc qui marche maintenant avec une feature de moins. Plutôt que d'accumuler une dête technique monstrueuse sous le pretexte du TTM.
D'ailleurs ton TTM il s'écroule après 6 mois quand une équipe passe 50% de son temps à résoudre ses problèmes et faire du support pendant que l'autre continue au même rythme voir devient plus véloce. Les deux ont livrés à temps pourtant…
C'est mon constat ayant bossé sur des codes de toute taille et dans quelques domaines où les tests sont un peu plus compliqués que dans la plupart des domaines (systèmes distribués, réseaux, grosse appli JS, moteur de recherche, big data etc.).
Et j'ai aussi eu l'occasion d'experimenter la chute de vélocité à moyen terme et l'empilement des BR d'une équipe quand on a joué la carte du "trop compliqué à tester" pendant quelques mois. On a passé un/deux mois à faire le taff qui aurait du être fait, plus longtemps que si on l'avait fait pendant le dev, et c'est reparti…
Quand je code tout seul pour le fun c'est étrangement la même chose.
Pas pour rien que gmail (par exemple!) a été en beta pendant des années
Tu parles encore d'un truc dont tu ne connais absolument rien. T'as une idée de comment fonctionne l'engineering et la code base chez Google ? Tu as des fait sur gmail en particulier ?
genre un Linux ça a combien de RC parce que tes tests unitaires n'ont pas été suffisants?
AFAIK Y'a 0 TU dans Linux… Au passage prendre Linux comme exemple pour la gestion de projet est souvent une très mauvaise idée.
Sans compter le test qu'il faut pour débugger, car le code est juste mais le test est faux.
C'est étrange. J'ai du bosser sur quelques millions de ligne de codes et les seuls tests que j'ai eu a debugger sont ceux de gens qui soit disaient que c'était compliqué de tester, soit qui s'en foutait et soit qui pissait du mauvais code. En se penchant dessus on fait quelque chose qui juste marche. Dans les autres cas, la seul raison d'y toucher était un changement fonctionnel (et c'est à ca que ca sert).
Bref, je tiens juste à signaler que oui, c'est important, mais… Ca dépend, en fait. De beaucoup de choses (taille ou criticité de la cible ou des délais ou…)
Comme toujours il y a quelques raisons valides. Et comme souvent les gens utilisent ces quelques mais pour se convaincre qu'ils sont dedans et couper toute reflexion plutôt que de réfléchir à pourquoi c'est difficile et trouver des réponses efficaces. Non la couverture n'est pas un objectif. Non le but n'est pas d'appliquer bêtement un principe. Le but c'est d'ameillorer la qualité, la vélocité et donc te permettre de coder des nouveaux trucs plutôt que de débugger ou de passer 6 mois sur 12 en recette.
[^] # Re: Pas de révision d'historique
Posté par ckyl . En réponse au journal Chiselapp ferme ses portes. Évalué à 1.
Je ne répondrais pas à la Zenitramerie qui consiste à trouver les contre exemples.
Ce n'est pas vraiment une question de criticité. Pour les trucs critiques les procédures et le type de test sont différentes et complémentaire. C'est d'ailleurs pour ca que la QA, les test engineers et le release engineering existent.
La troisième version c'est il vaut mieux un truc qui marche maintenant avec une feature de moins. Plutôt que d'accumuler une dête technique monstrueuse sous le pretexte du TTM.
D'ailleurs ton TTM il s'écroule après 6 mois quand une équipe passe 50% de son temps à résoudre ses problèmes et faire du support pendant que l'autre continue au même rythme voir devient plus véloce. Les deux ont livrés à temps pourtant…
C'est mon constat ayant bossé sur des codes de toute taille et dans quelques domaines où les tests sont un peu plus compliqués que dans la plupart des domaines (systèmes distribués, réseaux, grosse appli JS, moteur de recherche, big data etc.).
Et j'ai aussi eu l'occasion d'experimenter la chute de vélocité à moyen terme et l'empilement des BR d'une équipe quand on a joué la carte du "trop compliqué à tester" pendant quelques mois. On a passé un/deux mois à faire le taff qui aurait du être fait, plus longtemps que si on l'avait fait pendant le dev, et c'est reparti…
Quand je code tout seul pour le fun c'est étrangement la même chose.
Tu parles encore d'un truc dont tu ne connais absolument rien. T'as une idée de comment fonctionne l'engineering et la code base chez Google ? Tu as des fait sur gmail en particulier ?
AFAIK Y'a 0 TU dans Linux… Au passage prendre Linux comme exemple pour la gestion de projet est souvent une très mauvaise idée.
C'est étrange. J'ai du bosser sur quelques millions de ligne de codes et les seuls tests que j'ai eu a debugger sont ceux de gens qui soit disaient que c'était compliqué de tester, soit qui s'en foutait et soit qui pissait du mauvais code. En se penchant dessus on fait quelque chose qui juste marche. Dans les autres cas, la seul raison d'y toucher était un changement fonctionnel (et c'est à ca que ca sert).
Comme toujours il y a quelques raisons valides. Et comme souvent les gens utilisent ces quelques mais pour se convaincre qu'ils sont dedans et couper toute reflexion plutôt que de réfléchir à pourquoi c'est difficile et trouver des réponses efficaces. Non la couverture n'est pas un objectif. Non le but n'est pas d'appliquer bêtement un principe. Le but c'est d'ameillorer la qualité, la vélocité et donc te permettre de coder des nouveaux trucs plutôt que de débugger ou de passer 6 mois sur 12 en recette.