Discussion :

[Marco46]

Je rejoins marco46 concernant les tests unitaires, par contre un peu moins d'accord sur le fait que "pas de test unitaire => amateur".

C'est le point de vue de Uncle Bob, et je suis assez d'accord avec lui.

Si tu n'as pas d'automatisation de tes tests, ça veut dire que tu les fais à la main. Ton cycle de feedback (entre modification du code et vérification) est potentiellement très long, et tu n'as aucune garantie que la couverture soit suffisante. Effectuer ce test à la main c'est de l'amateurisme, c'est pour moi parfaitement indiscutable, c'est du même ordre que réinventer la roue en permanence (ne pas utiliser de librairies ou de frameworks), c'est même pire puisqu'on fait manuellement des opérations qui sont automatisables facilement. Bref c'est une perte de temps sèche et également une absence de qualité indigne d'un pro.

Je sais bien que tout le monde n'est pas d'accord sur ça, il suffit de voir le ratio +1/-1 sur mon post initial pour s'en convaincre. Et c'est encore bien pire chez les décideurs qui ont une culture du développement logiciel très superficielle (pour rester poli).

Y'a des contextes où on ne peut utiliser correctement des TU sous peine de faire pire que si il n'y en avait pas. (e.g. faire des tests unitaires sur la communication d'une BDD, c'est possible, mais sans Mock c'est pas tellement utile, même principe pour la communication avec une infra (API))

Les TU remplissent un besoin précis : S'assurer que le code produit fait ce qu'il est censé faire, et avoir de la visibilité sur ce statut dans le temps. En exécutant une seule commande, on peut savoir si le code fait ce qu'il est censé faire ou pas. Cela permet donc le refactoring en limitant drastiquement les risques de régression. Évidemment cela suppose que les TU soient de bonne qualité.

Maintenant faire communiquer un système avec un autre (se connecter à une BDD, se connecter à une autre application via un WS, etc ...) ça ne peut évidemment pas être couvert par un test unitaire puisque le propre du test unitaire c'est de mocker tout le contexte autour du bloc de code à tester.

Pour ça on a les tests d'intégration qui ont pour rôle de tester que le cas passant entre 2 systèmes fonctionne. Bref, à besoin différent, solution différente

[el_slapper]

(.../...)Pour ça on a les tests d'intégration qui ont pour rôle de tester que le cas passant entre 2 systèmes fonctionne. (.../...)

...suivis des tests d'homologation, ou un robot simule un utilisateur crétin qui fait toutes les erreurs possibles avant de faire le bon mouvement. Je programme ce robot, et on ramasse pas mal de choses. Et quand on a des bugs en prescription de médicaments, si on les laisse passer, ça peut tuer des gens... J'ai trouvé un doublonnage de prescriptions, une fois. Pas glop.

Dans un monde idéal, on aurait tout ça : des TU automatiques à chaque commit, suivis d'un test complet par le programmeur, suivis de tests d'intégration autant automatisés que possibles, avec un build et une exécution toutes les nuits, et enfin, repasser le robot à chaque version. Bon, partout ou je suis passé, les décideurs préfèrent le management par la panique, et c'est déjà bien d'avoir le robot pour détecter quand le programmeur n'a pas vérifié que son WPF s'ouvrai sans exploser à vide..... Quand il n'y avait pas le robot, ça partait chez le client et boum.

Pour revenir aux TU, c'est aussi un problème de culture. Quand on a des utilisateurs qui demandent des macros excel(dans un cas ou c'est justifié, puisque 'il s'agit juste de toutouiller des données pour fournir un excel au client), mais qui refusent obstinément d'installer rubberduck, faire des TU, ça devient monstrueux. Et nettoyer l'excel de ses tests auto à chaque livraison demanderait trop de temps. Quand tu as un écosystème COBOL ou tu est le seul à faire des TU, à la fin, tu te fais tancer parce que tu livres des programmes non demandés, et qui ne tournent même pas en prod, donc qui ne servent à rien, donc tu as volé l'argent du client.

Alors qu'en fait, non, tu a fait un système bien plus performant, et bien plus adaptatif. Quand je vois notre programmeur principal compta qui installe en direct des correctifs à chaud(chez le client, à l'hôpital) en oubliant à chaque fois de mettre à jour perforce, sans même avoir testé, et qui déjà trouve que Perforce est une insupportable atteinte à sa liberté, je crois que les TU automatisés, ce n'est pas pour demain, ici - pourtant, on a un vrai problème de qualité. Et je n'ai le droit de taper que sur l'interface, donc je le fais, c'est mieux que rien. Et on ramasse un tas de bugs - surtout à la compta.....

[Marco46]

...suivis des tests d'homologation, ou un robot simule un utilisateur crétin qui fait toutes les erreurs possibles avant de faire le bon mouvement. Je programme ce robot, et on ramasse pas mal de choses. Et quand on a des bugs en prescription de médicaments, si on les laisse passer, ça peut tuer des gens... J'ai trouvé un doublonnage de prescriptions, une fois. Pas glop.

Pour moi c'est typiquement le genre de cas où si un mec meurt et qu'il y a procès le développeur qui a fait le con devrait se retrouver en taule exactement comme un médecin qui ne prend pas les mesures d'hygiène nécessaires ou un mécanicien qui déconne en remplaçant les freins d'un véhicule, ou encore l'industrie alimentaire qui met de la merde dans la bouffe.

Ça s'appelle un homicide involontaire :

[...]
Il y a également délit, lorsque la loi le prévoit, en cas de faute d'imprudence, de négligence ou de manquement à une obligation de prudence ou de sécurité prévue par la loi ou le règlement, s'il est établi que l'auteur des faits n'a pas accompli les diligences normales compte tenu, le cas échéant, de la nature de ses missions ou de ses fonctions, de ses compétences ainsi que du pouvoir et des moyens dont il disposait.

Dans le cas prévu par l'alinéa qui précède, les personnes physiques qui n'ont pas causé directement le dommage, mais qui ont créé ou contribué à créer la situation qui a permis la réalisation du dommage ou qui n'ont pas pris les mesures permettant de l'éviter, sont responsables pénalement s'il est établi qu'elles ont, soit violé de façon manifestement délibérée une obligation particulière de prudence ou de sécurité prévue par la loi ou le règlement, soit commis une faute caractérisée et qui exposait autrui à un risque d'une particulière gravité qu'elles ne pouvaient ignorer.

Et vous verrez qu'on y viendra dès qu'un évènement lié à un bug informatique aura causé une catastrophe entrainant de nombreux morts, soit par une loi directe soit par jurisprudence.

[Marco46]

Dans un monde idéal, on aurait tout ça : des TU automatiques à chaque commit, suivis d'un test complet par le programmeur, suivis de tests d'intégration autant automatisés que possibles, avec un build et une exécution toutes les nuits, et enfin, repasser le robot à chaque version.

Ca ça ne dépend que de nous. C'est à nous d'inclure tout ça dans nos estimations. Le donneur d'ordre demande une fonctionnalité, on lui fait une estimation. Point barre ...

Bon, partout ou je suis passé, les décideurs préfèrent le management par la panique

... et les décideurs n'ont pas à se méler de savoir comment on s'y prend parce que ce n'est pas leur métier. Ils ne pinent rien au génie logiciel, donc qu'ils ferment leur gueule sur ces sujets.

A-t-on déjà vu le directeur d'un hôpital imposer au personnel de réutiliser les instruments de chirurgie d'une opération à l'autre par mesure d'économie ? C'est exactement du même ordre. Les décideurs n'ont pas à s'occuper de comment on réalise nos logiciels. Ce n'est pas leur métier. C'est très difficile de les remettre à leur place mais il faut le faire.

[MikeRowSoft]

Et vous verrez qu'on y viendra dès qu'un évènement lié à un bug informatique aura causé une catastrophe entrainant de nombreux morts, soit par une loi directe soit par jurisprudence.

Tu es le genre d'individu a qui je répondrais sérieusement sur un sondage traitent de l'importance de l'informatique à un stade personnel et de l'importance de l'informatique à un stade professionnel. Surement pas d'état, puisque sa n'existe pas de façons aussi organisé que les impôts.

[GrandFather]

Tu es le genre d'individu a qui je répondrais sérieusement sur un sondage traitent de l'importance de l'informatique à un stade personnel et de l'importance de l'informatique à un stade professionnel. Surement pas d'état, puisque sa n'existe pas de façons aussi organisé que les impôts.

Euh... Kamoulox ?

[elmhaidara]

Dans la catégorie de la recherche dichotomique pour chercher par exemple un commit ayant introduit une régression, une commande git qui peut être très utile : git bisect.

[Shepard]

ou qui te retourne une BrolException

J'ai un ami qui avait laissé traîner une PenisTooSmallException. Je vous laisse imaginer sa tête quand elle a été levée lors d'une défense de projet :p

[Songbird]

J'ai un ami qui avait laissé traîner une PenisTooSmallException.

Ahah, ce collector.

[fenkys]

Pour moi c'est typiquement le genre de cas où si un mec meurt et qu'il y a procès le développeur qui a fait le con devrait se retrouver en taule exactement comme un médecin qui ne prend pas les mesures d'hygiène nécessaires ou un mécanicien qui déconne en remplaçant les freins d'un véhicule, ou encore l'industrie alimentaire qui met de la merde dans la bouffe.

Ça s'appelle un homicide involontaire :



Et vous verrez qu'on y viendra dès qu'un évènement lié à un bug informatique aura causé une catastrophe entrainant de nombreux morts, soit par une loi directe soit par jurisprudence.

C'est déjà arrivé :

• Therac 25
• Bug mortel à lhopital

Dans aucun des deux cas, les développeurs n'ont été inquiétés alors qu'un bug informatique est clairement la cause de ces accidents.

[Luckyluke34]

C'est déjà arrivé :

• Therac 25
• Bug mortel à lhopital

Dans aucun des deux cas, les développeurs n'ont été inquiétés alors qu'un bug informatique est clairement la cause de ces accidents.

En même temps, la justice pénale ne s'est saisie d'aucun de ces deux cas. Pour le Therac-25 il y a eu seulement une enquête non officielle en interne, et pour l'hôpital, juste un rapport de la commission régionale de conciliation et d'indemnisation.

[el_slapper]

Pour moi c'est typiquement le genre de cas où si un mec meurt et qu'il y a procès le développeur qui a fait le con devrait se retrouver en taule exactement comme un médecin qui ne prend pas les mesures d'hygiène nécessaires ou un mécanicien qui déconne en remplaçant les freins d'un véhicule, ou encore l'industrie alimentaire qui met de la merde dans la bouffe.

Ça s'appelle un homicide involontaire

Oui, mais va le prouver... Va prouver qu'il y a malveillance. D'ailleurs, les liens donnés par Fenkys montrent que c'est assez compliqué à démontrer.

Ca ça ne dépend que de nous. C'est à nous d'inclure tout ça dans nos estimations. Le donneur d'ordre demande une fonctionnalité, on lui fait une estimation. Point barre ...

Allons, tu sais très bien que dans la vraie vie, ça ne se passe pas comme ça. J'ai eu à maintenir un projet, mes malheureux prédécesseurs avaient demandé 300, on leur avait donné 100.... Ca a couté bien plus que les 200 manquants en maintenance, évidemment. Mais ils sont passés quand même, et ça marchait. Impressionnant. Et malheureux, parcequ'au final, j'ai du tout refaire, ça coutait moins cher que de modifier l'appli pour prendre en compte une évolution majeure.

... et les décideurs n'ont pas à se mêler de savoir comment on s'y prend parce que ce n'est pas leur métier. Ils ne pinent rien au génie logiciel, donc qu'ils ferment leur gueule sur ces sujets.

Mais c'est leur pognon que nous consommons. D'ou les rapports de force généralement défavorables au dev, surtout dans les boites non informatiques. Maintenant que je suis en édition de logiciel, j'apprécie beaucoup quand un de mes collègues demande "Je veux bien passer à mi-temps sur ce projet, mais alors c'est une semaine sur deux, je refuse de jongler jour après jour, je ne serais pas productif", et la chef répond "c'est une bonne idée, qui d'autre veut faire pareil?" au lieu de lui hurler dessus jusqu'à ce qu'il cède.

Et même dans ce contexte très favorable, la pression des clients(des Hôpitaux, je rappelle) fait que parfois on livre en urgence des composants qui ne sont pas encore passés par les fourches caudines de la qualité(i.e. moi ou ma collègue). Alors bon, je me souviens du milieu bancaire, ou c'était largement pire, ou on m'a tapé sur les doigts(20 minutes d'engueulade en me traitant de voleur) pour avoir fiabilisé les traitements, et je me dis que ta théorie, elle est jolie, mais elle ne colle pas au monde réel que je fréquente.

A-t-on déjà vu le directeur d'un hôpital imposer au personnel de réutiliser les instruments de chirurgie d'une opération à l'autre par mesure d'économie ? C'est exactement du même ordre. Les décideurs n'ont pas à s'occuper de comment on réalise nos logiciels. Ce n'est pas leur métier. C'est très difficile de les remettre à leur place mais il faut le faire.

Euh, comment dire..... J'ai passé une semaine dans un hôpital pourtant moins radin que les autres lors d'une installation, et j'ai vu des choses que je couvrirais du secret professionnel, mais bon, ça faisait très bricolage, pour rester poli. Pas au point que tu décris, mais pas joli-joli quand même.

[Zirak]

Ca ça ne dépend que de nous. C'est à nous d'inclure tout ça dans nos estimations. Le donneur d'ordre demande une fonctionnalité, on lui fait une estimation. Point barre ...

... et les décideurs n'ont pas à se méler de savoir comment on s'y prend parce que ce n'est pas leur métier. Ils ne pinent rien au génie logiciel, donc qu'ils ferment leur gueule sur ces sujets.

Les décideurs n'ont pas à s'occuper de comment on réalise nos logiciels. Ce n'est pas leur métier. C'est très difficile de les remettre à leur place mais il faut le faire.

Encore faut-il que l'on te demande ton avis pour estimer le temps nécessaire, ce qui n'est pas le cas partout, tellement les tâches ont été fractionnées sur différents "métiers".

Et si les "décideurs" s'appellent comme ça, c'est justement car ce sont eux qui "décident". Si c'était juste des mecs que l'on peut écouter parler sans tenir compte de ce qu'ils disent, cela ne serait pas des "décideurs". En général, il y a quand même un lien hiérarchique avec ces personnes, donc oui ,tu peux expliquer que, mais rien ne les oblige à tenir compte de ton avis, même si ce n'est pas leur métier et qu'ils n'y connaissent rien. Si ils ont décidé que tu devais le faire en X jours, car cela a été vendu comme ça au client par un mec qui n'y connait rien, et bien il faudra le faire en X jours, même si cela veut dire pas de TU.

Tu as bien raison d'être aussi catégorique sur tes convictions, mais comme le dit el-slapper, ce n'est pas toujours aussi simple. ^^

[Garvelienn]

A-t-on déjà vu le directeur d'un hôpital imposer au personnel de réutiliser les instruments de chirurgie d'une opération à l'autre par mesure d'économie ? C'est exactement du même ordre. Les décideurs n'ont pas à s'occuper de comment on réalise nos logiciels. Ce n'est pas leur métier. C'est très difficile de les remettre à leur place mais il faut le faire.

Le directeur d’hôpital ne va pas imposer cela car si il y a un procès par la suite, c'est pour sa pomme. Par contre, il va fournir des instruments de mauvaise qualité, avec du retard, etc. Bah oui, le personnel arrive quand même à travailler. Pas besoin de dépenser plus. Oh et puis, les chaises pour les infirmiers/ères, ça ne sert à rien de les remplacer. Ils/elles n'ont pas à s'assoir normalement. Et puis, n'achetons qu'un seul chariot par étages. Jusqu'à présent, on ne nous a rien dit. Eh oui, dans tous les milieux, l'argent, toujours l'argent. Si on veut développer quelque chose de sérieux, il faut le faire sur son temps personnel malheureusement.

Les décideurs décident dans quelles conditions on travaille. Malheureusement pour le personnel qui n'a pas son mot à dire sauf si c'est dans la même vision que la tête de décision... Et ce n'est pas forcément qu'à cause de l'argent. Dans les associations de bénévoles humanitaires, on retrouve des fois ce même schéma. C'est juste humain.

edit: que du true story au passage

[MikeRowSoft]

Euh... Kamoulox ?

Non, tu peux te laissé allé, aucune gravité n'est envisageable.

Mon Lumia 550 n'a aucun bogue qui le fait planté, que des bogues de désagréments.

[Luckyluke34]

J'ai eu à maintenir un projet, mes malheureux prédécesseurs avaient demandé 300, on leur avait donné 100.... Ca a couté bien plus que les 200 manquants en maintenance, évidemment. Mais ils sont passés quand même, et ça marchait.

C'est tout le noeud du problème.

• Comment faire comprendre à un décideur qu'il est en train d'échanger une économie de 200 à court terme contre une perte de, disons 400 en maintenance à moyen terme + des préjudices non chiffrables dûs à des bugs ?
  
  Je suis d'accord que l'époque se fout royalement du moyen terme. L'approche de Marco46 (et de Uncle Bob) se heurte de plein fouet à la quête folle du profit immédiat et à la loi du financier qui règnent en ce moment. Mais pour autant, est-ce qu'on doit laisser tomber notre devoir de conseil en tant que professionnels ?

• Par ailleurs, lorsqu'on on nous attribue 100 au lieu des 300 promis, est-on obligé de rogner sur la qualité ? Est-ce qu'on ne peut pas livrer moins de fonctionnalités ?
  
  Je rappelle que le point portait sur les tests unitaires, donc directement la validité du code et la détection de bugs. Que se passerait-il si par défaut les développeurs se mettaient dans un mode "qualité" au lieu de se mettre en mode "respect à tout prix des délais calculés par d'autres" ? Si on avertissait par écrit le demandeur que le délai est intenable et que rogner sur la qualité occasionnera des bugs ? A ce moment-là, l'ordre du supérieur de basculer dans l'autre mode, c'est à dire de faire sciemment de la m**** au niveau qualité, deviendra nécessairement officiel et explicite, et quelque part, le développeur se protège les miches au lieu d'être le complice tacite d'un produit plein de bugs.

PS @el_slapper : je te pensais moins fataliste, pour le coup tu as une vision au vitriol de l'avenir de notre profession...

[Aurelien.Regat-Barrel]

non non je ne bave sur les debogueurs et je sais largement mieux m'en servir que les nouveaux arrivants qui ne savent coder qu'en C# sans vraiment rien maitriser dans la gestion memoire (fonctionnement GC etc).
Je dis que c'est a utiliser en dernier recours en combinaison des logs bien sur

Ah ben on est bien d'accord alors

arf le coup du serveur de symbole et analyse du crash dump

"en combinaison des logs bien sur"

En pratique c'est artillerie lourde

Là je suis pas d'accord. Avec Visual Studio en tous cas, c'est assez simple et rapide à mettre en place. Et quand il s'agit de trouver où se situe le déréférencement du pointeur null ou la levée d'exception, c'est très pratique. le log permet ensuite de comprendre pourquoi on en arrivé là - ça se complète.

En embarqué, le dump ne peut parfois toujours être généré et stocké localement pour un futur export (avec les logs) quand le technicien passe. Dans ce cas les logs sont critiques non pas parce que c'est un outil plus puissant que le dump, mais parce que c'est le seul dont on dispose (nuance!).

Ce que tu me racontes est ce qu'une equipe de mon taf ont mis en place (ceux la meme qui considerent que les traces sont inutiles et un soft passé par les TU il n'est nul besoin de traces quand un dump suffira).

Je suis pas sûr de raconter la même chose, car pour moi une appli sans fichier de log, c'est de l'amateurisme, TU ou pas TU. Faut pas mettre la charrue avant les boeufs.

Le côté "être pro", c'est vis à vis du support client. Pour l'avoir vécu, quand un soft te pète dans les pattes, et que 10 secondes plus tard, il t'informe que ton problème est corrigé et que c'est dispo à telle URL, ben moi j'ai trouvé ça très pro!

Au passage j'ai pu recemment voir avoir la demonstration de la pietre efficacité du systeme... puisque meme l'outil lui meme d'analyse du dump etait foiré.
Resultat, pour corriger un pb sur un logiciel tu te retrouves a devoir deboguer l'outil d'analyse lol !

Si on va dans cette direction, je peux moi aussi te donner une exemple de piètre efficacité des fichiers de logs : des logs tellement volumineux (plusieurs Go) qu'il ne sont pas exploitables (ne serait-ce que les ouvrir dans un éditeur de texte) et qu'il faut coder des outils spécifiques (4 jours de dev...) pour extraire les lignes dignes d'intérêt... Et c'est tellement fréquent comme fonctionnement que y'a des produits spécialisés dans l'aggrégation et le filtrage de tout ce bruit (kibana...). Pour autant, j'en ai pas conclu (dans l'exemple précédent) que les logs étaient un mauvais outil, juste que c'était fait n'importe comment dans ce contexte.

Ce que je contacte souvent, c'est que c'est plus facile de blâmer l'outil que de remettre en question la façon dont on l'utilise. C'est pour ça que j'ai toujours une petite alerte dans ma tête quand quelqu'un dit "ce truc là ça sert à rien c'est nul". Je ne me souviens pas d'un exemple où, après approfondissement, on ne s'est pas rendu compte que, en fait, la personne ne savait juste pas s'en servir correctement.

Et oui, "l'etat de l'art du dev" est une façon parmi d'autres de déguiser son incompétence tout comme le terme "pragmatisme" peut servir (aussi) à cela (je ne te vise pas attention,j'ai aimé nos échanges).

[Aurelien.Regat-Barrel]

J'ai aussi remarqué, en traitement par lots de masse(c'est certainement une mauvaise pratique en transactionnel, et aussi dans la plupart des autres contextes), qui mettre des compteurs complets, détaillés, à la fin de chaque exécution, était une pratique qui permettait de réduire fortement le temps de débug. du genre "3701 enregistrements lus, 3701 enregistrements validés, 523 clients pros ignorés, 3178 clients privés traités, 24 clients privés corrigés, 3154 clients privés inchangés, 3178 clients privés écrits". Parce-que si les chiffres ne collent pas, on sait tout de suite ou chercher. C'est un peu canulant à mettre en place, mais à la maintenance, ça fait gagner un temps fou.

Merci pour ce partage sur comment créer des messages de logs utiles (c'est toujours pareil : c'est pas l'outil qui apporte quelque chose mais comment on le met en oeuvre).

Et en plus, j'ai appris un nouveau mot : canulant

[kilroyFR]

...

Alors oui l'histoire des logs volumineux on a eu deja ca, voire meme a l'inverse, des gens qui te disent : je ne sais pas quoi mettre dans les logs... (alors ils logguent parce qu'on leur a dit de faire ... mais c'est completement inutile.
Au final tu leur fait remarquer que leur logs ne servent a rien en l'etat ... et a eux de retorquer avec une mauvaise fois ... 'tu vois je t'avais dit que ca servait a rien...' ()

=> ben trace deja les erreurs fonctionnelles avec des vrais messages explicites et les exceptions ce qui evite de faire perdre du temps a l'analyse (ex: valeur lue x != valeur attendue y); bref des regles simples mais quand les gens n'ont pas le reflexe/habitude c'est difficile.
Pour tout dire sur un composant qui nous posait pb recemment malgré de multiples relances inutiles, j'ai finalement recupére le code et fais l'analyse + ajout traces pertinentes ou il faut pour pallier aux pbs. Au final je les ai mis devant le fait accompli. Alors oui j'ai du prendre sur moi mais c'etait la seule façon (comme c'est un module que j'integre dans mes WS webapi je me suis donné le droit de regarder sur ce qui m'etait fourni).

Et oui comme tu dis les logs en plus des TUs mais malheureusement dans ma boite j'en ai qui ont des principes et ne veulent pas en deroger meme si en pratique on voit qu'il y a des pbs (depassements budgets systematiques...).

[el_slapper]

Comment faire comprendre à un décideur qu'il est en train d'échanger une économie de 200 à court terme contre une perte de, disons 400 en maintenance à moyen terme + des préjudices non chiffrables dûs à des bugs ?

Le concept de dette technique est bien utile, mais seulement face à des gens un minimum intelligents et ouverts. Quand on fait face à des gens qui prennent 100% de leurs décisions en fonction de leur intérêt immédiat, ça ne fonctionne pas.

Je suis d'accord que l'époque se fout royalement du moyen terme. L'approche de Marco46 (et de Uncle Bob) se heurte de plein fouet à la quête folle du profit immédiat et à la loi du financier qui règnent en ce moment. Mais pour autant, est-ce qu'on doit laisser tomber notre devoir de conseil en tant que professionnels ?

C'est pourquoi j'ai parfois joué au con, et quand même fait mon boulot presque comme il faut. "Livre en prod sans passer par la qualif et sans tester!!!! Désolé, chef, les livraisons urgentes, je sais pas faire, en plus les autorisations mettent deux plombes à arriver, ça ira plus vite si je fais comme d'hab(et je glisse un ou deux tests au passage, et je m'aperçois que j'avais fait une connerie que je corrige discrètement)"

Par ailleurs, lorsqu'on on nous attribue 100 au lieu des 300 promis, est-on obligé de rogner sur la qualité ? Est-ce qu'on ne peut pas livrer moins de fonctionnalités ?

Dans ce cas précis, non. C'était une chaine complète à monter avec une sortie bien définie, et ils n'ont pu rogner que sur les contrôles et traitement d'erreurs(j'ai un doute? Je crashe!). Le fait que quand il n'y avait pas d'erreur en entrée, tout se passait comme prévu prouve la grande qualité de l'équipe qui m'a précédé. Mais oui, dans d'autres cas, c'est la question à se poser.

Je rappelle que le point portait sur les tests unitaires, donc directement la validité du code et la détection de bugs. Que se passerait-il si par défaut les développeurs se mettaient dans un mode "qualité" au lieu de se mettre en mode "respect à tout prix des délais calculés par d'autres" ? Si on avertissait par écrit le demandeur que le délai est intenable et que rogner sur la qualité occasionnera des bugs ? A ce moment-là, l'ordre du supérieur de basculer dans l'autre mode, c'est à dire de faire sciemment de la m**** au niveau qualité, deviendra nécessairement officiel et explicite, et quelque part, le développeur se protège les miches au lieu d'être le complice tacite d'un produit plein de bugs.

Ben, souvent, on te montrera la porte. Mais, paradoxalement, j'ai eu quelques expériences ou on m'a demandé explicitement de faire du code sale, et ou j'ai été moins productif que si j'avais fait propre dès le départ. Je ne parle pas de TU, non, là le retour sur investissement est moins immédiat(même si réel et massif). Je parle juste de faire un code un peu organisé et pas monolithique. Eh bien dès le débogguage, faire propre est rentable. Avant même le premier passage en prod(qui dans ce cas a été la seule exécution).

Le truc, c'est qu'on a à faire à des relations sociales. De pouvoir, en l'occurrence, mais ce qui compte, c'est que se sont des relations sociales. Les gens à l'aise avec les machines sont souvent moins à l'aise avec les humains, et se font généralement emmener là ou ils ne veulent pas aller. Par des gens dont c'est le métier que de manipuler les autres.

PS @el_slapper : je te pensais moins fataliste, pour le coup tu as une vision au vitriol de l'avenir de notre profession...

Bon, j'ai un peu forcé le trait. D'ailleurs, il ne s'agit pas de l'avenir, mais du passé et surtout du présent. Et il ne s'agit pas de que nos métiers, mais de tous les métiers. Je ne doute pas que l'actuaire, l'égoutier ou les publicitaire sont soumis aux mêmes tiraillements que nous, par des hiérarchies formées dans les mêmes écoles. Ou on apprend que "le management, c'est la science du contrôle"(je compte au moins 3 mensonges/contre vérités dans cette phrase courte, et j'en loupe probablement). Ma réponse à moi, c'est de résister tant que c'est possible et réaliste. Et la base de ma réponse était la suivante : les TU, c'est au-delà du possible. Même dans une bonne(mais pas parfaite, ni même excellente) boite comme la mienne.

Je fais ce que je peux, je mets en fonctions les codes que mon collègue copie-colle partout, je documente mes crimes, j'automatise tout process qui peut l'être(et là dessus, par contre, mon collègue est très bien, même mieux que moi), je suis heureux d'ouvrir mon code à la critique et à la revue, etc..... Mais le TU, non, ça ne passera pas. Déjà, au bout de 4 ans, les tests automatiques d'interface commencent à peine à être acceptés comme autre chose que des lubies(je rappelle qu'ils ont déjà sauvé des vies), mais si je commence à mettre des TU automatisés sur les fonctions dont je me sers dans lesdits tests automatiques, j'ai 3 étages pour apprendre à voler.