Discussion :

[el_slapper]

ça fait un bon moment, oui, et c'était pas du côté des SdM... Mais en attendant, quel est le budget annuel accordé à l'informatique ? Et il y a une équipe à temps plein non ??(.../...)

Je suis d'accord avec tout le reste de ton discours. Mais pas avec ça. On ne progressera pas en se jetant à la gueule des "mon métier est plus difficille que le tien" mutuels. Nous avons TOUS des contraintes fortes.


Certes, en bancaire, les budgets sont colossaux. Mais ils ne sont pas dédiés à 3 applis qui se courent après. Encore une fois, nous sommes 2 et demi pour gérer 30 applis, 1500 scripts, 3 millions de ligne de code; nous sommes, pour une de ces applis, alimentés par 130 applis toutes différentes, toutes en sous-effectif aussi. Rapportés à la quantité réelle d'informations à traiter, nous sommes autant en sous-effectif que la moyenne du métier. D'autant que nous avons des contraintes "de sécurité" qui pèsent fortement sur la productivité. Et qu'il me parait inconcevable de faire sauter.

[souviron34]

Je suis d'accord avec tout le reste de ton discours. Mais pas avec ça. On ne progressera pas en se jetant à la gueule des "mon métier est plus difficille que le tien" mutuels. Nous avons TOUS des contraintes fortes.

Ce n'est pas ce que je voulais dire.. et je ne jetais rien à la gueule de quicquonque

Je ne faisais que dire que le milieu bancaire (en particulier) ou tout autre où une équipe est employée à temps plein pour créer/maintenir des softs "locaux" dont les clients sont captifs est différent et a des contraintes de budgets très différentes de boites industriels où le logiciel est vendu à des clients extérieurs, non captifs..

(il en va de même pour l'ergonomie : tu peux avoir une ergonomie "passable", si tes clients sont captifs, ils n'ont pas le choix (voir Socrate pour les guichetiers de la SNCF, ou tout autre appli "maison"). Si ils ne le sont pas, c'est un des nerfs de la guerre..)

Et simplement dans les milieux industriels que j'ai fréquentés, le développement d'un soft ne suit en rien les contraintes dites plus haut par arkhamon.. pour toutes les raisons citées, le budget n'en étant pas une des moindres, de même que la "non-captivité" des clients, résultants en la mise en concurrence de plusieurs boites.. Vu que les projets sur lesquels j'ai bossé étaient gros, c'est pour ça que je me permettais de comparer... Je sais que les projets bancaires sont très gros.

Je ne parlais pas de "mon métier", mais de l'environnement du milieu... Météo Canada, comme Météo France, est un service gouvernemental, dans lequel les crédits sont plus que contrôlés... Dans le médical, la boite pour laquelle je bossais avait en concurrent 3M et HP... Pour les aiguilleurs, c'était Airbus comme concurrrent.. Or, pour chacun de ces projets, le soft n'est qu'une petite ou 1/2 partie de l'équipement, et les négociations sur l'achat se font pendant des années.. (quand tu dois négocier avec la FAA pour équiper ou non l'ensemble des aéroports américains par exemple, en concurrence avec Aibus, t'as pas trop intérêt à dire "il faut que je ré-écrive proprement mon soft", alors que tout le monde sait qu'il marche dans plus de 80 pays depuis 30 ans (en Fortran, puis C)... C'est tout ce que je veux faire sentir comme différence...

Du coup, tu n'as pas le loisir d'appliquer la théorie..

Par exemple, pour les aiguilleurs, la décision a été prise de migrer vers C++ (une absurdité à mon avis), mais la migration se fait progressivement pendant plus de 10 ans... 800 exemplaires vendus de l'ancienne version à travers le monde avec satisfaction des clients, c'est un peu complqué de leur livrer - sans leur faire payer en plus, ou juste le prix convenu du SAV - une nouvelle version qui incluera des bugs...

C'est tout.. C'était par rapport aux "règles" énoncées plus haut

[arkhamon]

Je ne faisais que dire que le milieu bancaire (en particulier) ou tout autre où une équipe est employée à temps plein pour créer/maintenir des softs "locaux" dont les clients sont captifs est différent et a des contraintes de budgets très différentes de boites industriels où le logiciel est vendu à des clients extérieurs, non captifs..

Rien que ça ça vaut un +1 ! Tu as tout a fait raison, c'est un point que je n'avais pas vu sous cet angle. Mais du coup, et je suis bien placé pour le savoir, quand on a des clients captifs, pourquoi continuer à développer comme des porcs ?

Du coup, tu n'as pas le loisir d'appliquer la théorie..

Et c'est bien dommage.

Par exemple, pour les aiguilleurs, la décision a été prise de migrer vers C++ (une absurdité à mon avis), mais la migration se fait progressivement pendant plus de 10 ans... 800 exemplaires vendus de l'ancienne version à travers le monde avec satisfaction des clients, c'est un peu complqué de leur livrer - sans leur faire payer en plus, ou juste le prix convenu du SAV - une nouvelle version qui incluera des bugs...

C'est tout.. C'était par rapport aux "règles" énoncées plus haut

Pas faux non plus. Mais après, les clients devraient bien se rendre compte qu'en faisant des économies de bouts de chandelles, ce qu'ils vont obtenir ne va pas forcément leur donner pleine satisfaction.
S'il est vrai qu'on à un service à la hauteur du prix qu'on l'a payé, beaucoup oublient souvent les coûts cachés de telles négociations "fructueuse" ou l'on a réussi à économiser quelques euros... Dommage.

[souviron34]

Mais du coup, et je suis bien placé pour le savoir, quand on a des clients captifs, pourquoi continuer à développer comme des porcs ?

ça, sans doute je compatis...

Et c'est bien dommage.

Oui et non.. Le but d'un soft est .. son but.. Pas qu'il soit fait suivant telle ou telle théorie..

Si donc on a quelque chose qui marche, pourquoi vouloir le modifier pour appliquer des règles - qui d'ailleurs se modifieront avec la prochaine mode ou "découverte" ???

Si le soft correspond au but pour lequel il a été fabriqué et fait tout ce pourquoi il a été conçu, de la manière dont les utilisateurs le souhaitent, c'est en soi suffisant..

Je te citerais un petit exemple que j'ai eu il y a 3 ans : je suis appelé en aide pour le re-développement d'un code de la SNCF (celui qui gére les horaires des trains à toutes les gares). Le code est en Fortran (77 pour la plupart), a été créé par des cheminots devenus ingénieurs au début des années 80, et maintenu et "fine-tuné" par eux pendant 25 ans, fonctionne parfaitement, prend en compte tous les types de trains (dont les tgv, nouveaux et anciens), tous les dénivelés des rails, tous les postes transformateurs, les différents modes d'économie d'énergie, etc etc.. "Quelqu'un", parce que les différents intervenants sont partis à la retraite et que le Fortran ça fait pas "moderne", décide de ré-écrire tout en Java. MAIS le coeur du soft a été laissé tel quel, en Fortran 77.. Avec les "patchs" créés par les gars au fur et à mesure des 30 ans.. Beaucoup trop de savoir enfoui dedans... Avec beaucoup trop d'impact possible si une erreur se glisse dans la ré-écriture.. (impact pouvant être collision de trains par exemple ). J'étais en charge de l'analyse de l'algo et des données du coeur.. Je peux te dire que c'était pas simple, et que refaire ça, en n'oubliant strictement rien, ben!.. Y'en avait pour une fortune avec un risque gigantesque..

Donc oui et non

Mais après, les clients devraient bien se rendre compte qu'en faisant des économies de bouts de chandelles, ce qu'ils vont obtenir ne va pas forcément leur donner pleine satisfaction.
S'il est vrai qu'on à un service à la hauteur du prix qu'on l'a payé, beaucoup oublient souvent les coûts cachés de telles négociations "fructueuse" ou l'on a réussi à économiser quelques euros... Dommage.

voui.. "quelques euros"..

Quand tu as payé ton système 5 millions pièce en 10 exemplaires, tu veux bien consacrer admettons 5% ou 10% par an en maintenance, mais pas tellement plus, hein ?? Et tu t'attends à un service exemplaire...

Les "clients" ne font pas des économies de bout de chandelle. Ils ont acheté quelque chose qui marchait, ont passé 10 ou 15 ans à faire inclure leurs spécificités, faire corriger tous les petits "à-côtés" qui ne convenaient pas ou étaient des bugs, pour avoir une Rolls-Royce exactement à leur convenance.

Ils verraient d'un très mauvais oeil que tu leur dises "ah désolé , mais pour avoir un code propre pour nous, il faudrait que vous remettiez la main à la poche et que vous vous attendiez à repasser à travers une partie des désagréments de ces 10 dernières années"

La fonctionalité est ce qu'ils ont acheté. Pas le fait que le code soit propre ou non..



Enfin, on va pas s'écharper là-dessus, nous sommes pas mal HS... Mais simplement le suivi de "règles" et d'une belle théorie n'est pas la priorité, et peut assez souvent être même nuisible au but poursuivi, qui est de remplir pleinement et à 100% la fonctionalité demandée.. C'est pour ça que j'insistais sur la différence de "milieu".. et que mon passage par l'ergonomie des logiciels m'a renforcé dans cette attitude : le but d'un soft est de satisfaire le client. Point final. Que derrière ce soit un monstre n'est pas important, pourvu que ça marche. Bien entendu, il est souhaitable que cela soit relativement facile à dépanner, updater, maintenir. Mais en dehors de ça, les "règles" sont de beaux outils théoriques qui ne servent pas à grand chose..

Exemple d'ergonomie : sur un soft médical, le Directeur Technique exige de moi un "Dictionnaire de l'IHM" pour les programmeurs, indiquant exactement tous les widgets, les fenêtres, leur apparence, les règles de positionnement, etc etc etc.. Je le fais... Cependant, le logiciel étant destiné à être commercialisé, je fais venir un graphiste pour finaliser les écrans... Et il fait des "aberrations" du point de vue du Directeur Technique, avec ses "règles". Telle liste sur tel écran a une écriture noire sur un fond gris, telle autre a une écriture bleue sur un fond blanc, etc etc... Ben oui... ça fait plus joli dans ce contexte... Mais c'est pas une "règle"... Après 3 mois de bras de fer avec le Directeur Technique, et un Salon International, où la conclusion est que le soft apparaît comme le meilleur du moment, le Directeur Technique admet que le graphiste avait raison, et que finalement, ses "règles" et son "Dictionnaire" sont absurdes... Bref, ce qui du point de vue du logiciel devrait être "encadré" ne doit pas l'être dans la réalité... Il est bien plus préférable que ton soft s'arrache et que tous les utilisateurs s'extasient dessus que il suive des règles et une théorie pour le côté informatique... Faire les 2 serait "le paradis", mais la priorité doit être mise sur la satisfaction du client, pas sur la conformité d'un soft à des règles de conception..

[souviron34]

J'ajouterais, à votre décharge, arkhamon et el_slapper, que il est vrai que la France est assez spécialisée dans ces grands trucs "in house", entre les banques, les mutuelles, et des trucs comme EDf ou la SNCF..

La plupart des boites vendant du logiciel en France sont maintenant devenues des trucs basés sur le Web.. mais représentent peu dans le poids total de l'informatique en France..

Et que donc cela "oriente" la vision de l'informatique en France...

Donc je vous comprend

Mais soyez cependant conscient que c'est quand même un cas assez particulier dans lequel vous évoluez

[arkhamon]

Mais soyez cependant conscient que c'est quand même un cas assez particulier dans lequel vous évoluez

Yep d'accord avec toi. Une gabegie de moyens mal utilisés bien souvent...

[arkhamon]

Oui et non.. Le but d'un soft est .. son but.. Pas qu'il soit fait suivant telle ou telle théorie..

Si donc on a quelque chose qui marche, pourquoi vouloir le modifier pour appliquer des règles - qui d'ailleurs se modifieront avec la prochaine mode ou "découverte" ???

Tu as raison et je le dis tout el temps, quand ca marche on touche pas. Je proposais de revenir aux bases dans le cadre des NOUVEAUX développements. Et il me semble que dans ces cas là, on peut parfaitement prendre la décision de développer proprement. Ca induirait probablement une légère hausse de prix au départ, mais ça permettrait à mon avis de réduire les coûts de maintenance.

Enfin, on va pas s'écharper là-dessus, nous sommes pas mal HS...

On s'écharpe pas, on papote autour d'un café...

Mais simplement le suivi de "règles" et d'une belle théorie n'est pas la priorité, et peut assez souvent être même nuisible au but poursuivi, qui est de remplir pleinement et à 100% la fonctionalité demandée..

Ouaip. Mais ça empêche pas de le faire proprement non (oui je sais je vais finir par passer pour un vieux radoteur, ce que je suis d'ailleurs ).

Et concernant ton problème d'ergonomie, je suis de tout coeur avec toi : les problématiques d'ergonomie sont toujours quasi insolubles, car faisant appel à ce qui est de moins logique : l'Homme... Tu as eu le bon réflexe de passer par des professionnels, mais tu ne peux jamais rien faire contre un mec qui décide de choisir la palette fluo pour son PC. Au détriment de sa santé (je suis membre du CHSCT dans ma boite...).

[souviron34]

Pas de problèmes, nous sommes d'accord sur presque tout...

Je proposais de revenir aux bases dans le cadre des NOUVEAUX développements. Et il me semble que dans ces cas là, on peut parfaitement prendre la décision de développer proprement. Ca induirait probablement une légère hausse de prix au départ, mais ça permettrait à mon avis de réduire les coûts de maintenance.

je suis d'accord, mais je nuance cependant par ce qu'on expliquait plus haut :

• il y a des cas où la fonctionalité évolue, et, à moins de tout refaire, il est plus sensé de rajouter des choses, quitte à ce que ça ne soit pas "très" propre.
• il y a des cas où les inter-dépendances sont extrêmement fortes, et faire un découpage strict est quasi impossible
• il y a des cas où les données en entrée, on peut supposer qu'elles sont bonnes, mais c'est une supposition.... et on n'a peut-être pas le droit de garder ça une supposition (pour une bibliothèque par exemple, ou des données comme je mentionnais pour la météo, et les logiciels dits "critiques")

Même sur un développement nouveau...

C'était le sens de mes remarques par rapport aux tiennes du début... qui relativisaient un peu tes propos

[Logan Mauzaize]

C'est plus que gênant, c'est impensable. Des centaines d'applis dépendent du batch comptable de la nuit.

J'espère que sur des modifications apportantes c'est tout de même tester ??? Ceci dit j'ai vu des automates pour centrales électriques passés en production sans plus de tests

Non, parceque le reste du monde en dépend(on est dans une banque, hein, la compta, c'est sacré)

On est dans un environnement de recette, donc peu de monde devrait en dépendre à un instant T.

Je suis pas mal en aval aussi, même sous MVS. Je connais ton problème. Etre en amont, je l'ai été, ça n'est pas évident non plus.

Disons que t'es toujours en amont ou en aval de quelqu'un. Tant qu'on te demande pas de rendre des comptes sur ton précédent c'est déjà ça ^^
Le soucis vient quand les règles de tolérance (données erronées qu'on accepte) deviennent complexes voir contradictoire. Ou alors que le volume d'erreur dépasse largement la limite de l'acceptable. Exemple véridique après plusieurs mois d'EIS : 30% sur le total, plus de 50% sur les données les plus utiles ... On se retrouve alors à rajouter un module qui génère un CSV de synthèse et à ajouter des contrôles de cohérence.

Je reprends mon exemple. Nous avons une transaction de saisie sur compte du client pour le compte de l'état.
(1)L'opérateur, via la transaction JAVA, saisit la saisie(jeu de mot volontaire). Le système emet, immédiatement, un fluc comptable.
(2)La nuit, le batch comptable créée le compte qui va bien, fait les mouvements, et met à disposition de la transaction un fichier qui liste les comptes qu'il a créé.
(3)Au petit matin, un batch lié à la transaction met à jour la base avec les comptes créés.
(4)Dans la journée(ou un autre jour), l'opérateur se connecte, et vérifie via la transaction qu'il a bien sous la main un compte créé par le batch comptable. Il peut alors déboucler l'opération.

Tu peux tester automatiquement chaque point. Le point 2 par la compta, les autres par la saisie. Mais faire un cas de test complet de l'application saisie, qui commence par la saisie de la saisie, en passant par le débouclage, ça nécéssite un automatisme asynchrone. J'ai comme qui dirait un doute.

En fait on a exactement la même chose en gestion de configuration avionique, les concepteurs font des modifications (transactions) qu'on entasse dans des fichiers/tables en diff ou en final. Périodiquement on met à jour une base de données centralisée, d'autres chaînes viennent ensuite récupérer/consolider leurs données ou valider les modifications. Que ce soit côté MVS (Bureau d'Etude) ou J2EE (Service client).

Côté MVS, on faisait saisir les transactions aux utilisateurs et on déclenchait la chaîne manuellement dans le scheduler MVS. Et chaque équipe fonctionnellele validait ses morceaux. Et l'utilisateur validait les résultats à l'écran.

L'insistance que tu fais sur les logs est importante aussi. Des années de maintenance m'ont appris l'importance de logs complètes. Spécialement des compteurs précis. Si tous les mois on a "200 entrées, 199 sorties", et qu'un mois on a "200 entrées, 21 sorties", on va avoir un doute.
Si tous les mois on a "200 entrées, 199 sorties, 21 sorties marketing, 178 sorties restitutions", et qu'on se retrouve avec "200 entrées, 199 sorties, 21 sorties marketing, 0 sorties restitutions" alors on sait déjà qu'on a perdu les restitutions.

Et si en plus on a un message "178 entrées restitutions rejetées pour code agence non numérique", eh bien on sait déjà exactement quelle est la donnée qui a été pourrie, il ne reste plus qu'à corriger les données et à relancer.

Je pense qu'il faut avoir une petite expérience de support ou de suivi d'exploitation pour en avoir pleinement conscience

Pour les règles, je pense justement qu'à force de s'en affranchir, on en arrive à des situations ubuesques : des personnes n'ayant aucune vraie formation qui font de l'informatique en en ignorant les règles qui ont été baties par des pros... J'avais longuement débattu de ce point dans un autre sujet et je maintiens et persiste dans mon conception de l'informatique : un beau métier qui demande des règles come dans tout autre métier. Une poutre ca se fabrique dans les règles un mur ça se monte suivant les règles ou ca se casse la gueule, pourquoi toujours considérer qu'en informatique on peut faire n'importe quoi ? Etonnant ça...

Parce que les applications de gestion ne risque pas de faire ecrouler une maison ;-) Dans la plupart des cas ca se finit sur une boîte de dialogue d'erreur avec un message incompréhensible et l'utilisateur recommence sa manip. Ceci dit pour m'être lancé dans plusieurs projets de construction, si tu te renseignes t'en trouves à la pelle des murs qui ne tiennent pas debout. Donc non ce pas qu'en informatique.

Votre module, s'il doit vérifier ses entrées, ne peut le faire que s'il a toutes les infos et tous les algo pour le faire. Dans ce cas, il a de quoi faire le boulot du module précédent. Donc il y a duplication et donc perte (d'argent, de temps machine, d'accès BDD...). Et si un jour l'algo en question doit évoluer, c'est deux modules et non un seul qui doit être modifié. Et en reproduisant ce paradigme (j'adore ce mot), on se retrouve effectivement avec une analyse d'impact quasiment impossible à faire.

Tu pars d'une idée absurde/contradictoire. Premièrement, un système de doit d'avoir des pré-conditions et donc de les vérifier. Exemples tout con, un enregistrement X ou Y doit avoir un identifiant donc tu t'attends à ce qu'il soit unique, tu récupères des fichiers sur un dépôt FTP, tu t'attends à ce qu'ils respectent un certains format dans le nom.
Deuxièment, donc tu estimes qu'on peut changer les conditions des données émises sans impact sur le module receveur ... C'est justement la définition de ces conditions (ie spécifications d'interface) que l'on peut réaliser l'analyse d'impact. C'est sur ce principe que repose les méthodes formelles.
Enfin concernant la perte d'argent, l'argent "perdu" en développement est gagné au moins une fois quand il faut corriger le problème, au minimum 4 fois dès qu'il faut analyser l'origine du problème et infiniment dès lors qu'il faut défaire les conséquences. Et je parle même pas des modules qui se retrouvent encore en aval de ce maillon de la chaîne !

Je reste intimement convaincu que si chacun s'assure que ce qu'il produit est correct en amon, l'aval a moins de soucis. Toyota a découvert ça il y a 30 ans et ce concept, lui, a survécu à toutes les modes de le production...

Si tu parles du Lean Management, on est loin du "contrat de confiance" dont tu parles. Les contrôles/vérifications sont une part importante du process.

Il n'en reste pas moins qu'un module peut très bien (et devrait) s'étonner dans une log (là pour le coup les logs c'est capital) que d'habitude il reçoive un fichier de 200 lignes et que d'un coup il n'en reçoit que 30. Mais à mon avis il ne devrait pas être responsable de vérifier ses entrées.

Je comprends pas trop en quoi le volume est un critère plus important qu'un autre ? C'est une règle comme une autre.

La programmation par contrat, ça veut dire que le module en amont, celui qui nous envoie ses données, a pensé absolument à tout. C'est possible(voire parfois indispensable) dans certains cas(je pense en particulier à l'embarqué).

Même pas, comme l'a fait remarqué Souviron34, on travaille avec des données analogiques donc par nature instable et incertaine. Un peu comme les saisies utilisateurs sur les applications de gestion.

Parce que Java offre un garbage collector, il est devenu impossible de libérer soi même une ressource. Or cela va contre cette "règle" qui dit qu'on doit gérer ses ressources. Le laisser faire par d'autres est dangereux (cf fuites mémoires...).

Les seules fuites mémoires qui existe en Java c'est quand tu gardes un objet qui référence un graphe qui n'est plus nécessaire. Physiquement, il n'y aucune fuite, d'un point de vue logique, c'est autre chose ... Donc oui tu peux et tu dois te débarrasser des choses dont tu n'as plus besoin. Seulement tu les détruits pas, tu dis simplement "j'en ai plus besoin". Et le GC nettoiera quand plus personne n'en aura besoin. Bon le problème du GC c'est qu'il s'exécute quand il veut, c'est-à-dire quand il n'y a plus assez de mémoire réservée.

D'accord, sauf que le jour où les règles de typologie vont changer, il faudra AUSSI modifier ton code. Donc double travail : celui du module qui pond les fichiers d'entrée et ton module qui les vérifie. Double travail, double coût, double risque de mauvaise compréhension, double risque de bug (nous ne sommes qu'humains), doubles analyses d'impacts etc... Tu vois mon principe de raisonnement ?

C'est l'apanage de tout transfert d'information : transfert de compétence, téléphone arabe, etc.

C'est justement ce que j'allais dire. En même temps, un pluviomêtre ne devrait-il pas être réglé pour ne pas pouvoir envoyer cette pluviométrie ? Ou alors que cette valeur doive être vérifiée avant l'envoi ? Plus on détecte un dysfonctionnement tôt, moins ça coute cher de le corriger. C'est une des rares notions du management moderne avec laquelle je sois 100% d'acord.

Sauf que tu donnes de la compétence à un pluviometre. Il est beaucoup plus judicieux d'y ajouter un thermometre, un hygrometre et un anémometre. Et ajouter un module de contrôle qui calcule la fiabilité en fonction des paramètres physiques (température, humidité, vitesse du vent) et de paramètre de "confiance", par exemple %erreur. En tout cas ca fonctionne comme ca dans un avion.

J'en déduis donc que tu surcharges inutilement ton soft pour pallier à l'incompétence de personnes en amont. C'est tout le problème des développeurs : une partie (compétents) passe son temps à bidouiller pour pallier l'incompétence d'une autre partie qui fait n'importe quoi. Admets que si chacun faisait son travail correctemetn et effectuait ses contrôles correctement, la vie des autres serait grandement simplifiée.

Si chacun respectait la loi, on aurait pas besoin de système judiciaire. La nature humaine est ainsi faite.

un bloc de 36000 lignes en COBOL est effectivement une aberration !

Bof pas tellement. Le langage est super verbeu, limité à 64 colonnes utiles et pas très moderne (limiter à déplacer et tester des données, ou évaluer un paragraphe). Sans parler de l'abscence d'espace locale pour les variables, tout est en "statique" ("Working Area"), les noms des variables ont alors des noms à rallonges.

A mon avis nous sommes dans un autre cas : une tentative (en général vouée à l'échec) de refactorer une usine à gaz existante. Un architecte est formel : quand les bases sont pourries, on démolit et on rebatit proprememnt, au final ça revient toujours moins cher.

Si t'as une bonne base de test de non-régression, voir de test tout court, sinon ca va te couter un bras en non-régression...
Une fois j'ai flingué un programme COBOL vraiment mal foutu avec un mélange odieu de GOTO et de PERFORM, impossible de savoir où sortait les appels, ce choix nous aura coûté une bonne semaine de test supplémentaire et autant pour la recette. Bon au final on a bien fait car à la mise en production, ils ont relevés des écarts entre les deux versions ; après analyse c'était l'ancienne version qui était buggée.

J'aime bien cet exemple de l'architecte et de la tour : on étudie tout avant, et on se tient au plan, sinon la tour se casse la gueule. J'ai encore JAMAIS vu Vinci ou Bouygues rajouter 3 étages en heut d'une tour existante ou un niveau de sous sol de parking en dessous.
A force en informatique d'oublier les règles de base, on en arrive à des tours de Pise (sauf que la vraie elle est encore debout elle) voir des Tchernobyl en puissance, dasn lesquels on ne contrôle plus rien...

Sauf que contrairement à Vinci et Bouygues, on passe plus de temps à rajouter des étages à une tour qu'à en faire une nouvelle. Un logiciel ressemble plus à un quartier de Casablanca que La Défense.

Ouais. Mais on peut aussi apprendre aux gens à pas tout dégueulasser.

Si tu arrives déjà à le faire pour les rues, tu rendras heureux de nombreux maires. Idem pour les locataires et les propriétaires.

Un pont est loni d'être bête, et il subit toute une série de contraintes dont certaines sont dynamiques. Quant au compilateur, ce n'est qu'un morceau de "l'édifice". Tiens d'ailleurs en passant, le compilo demande à ce que la syntaxe et la structure soit parfaite, sinon il stoppe. Il n'accepte aucune trangession à ses régles (qui sont porutant strictes et parfois complexes), et pourtant personne ne critique. C'est peut être pas pour rien...

Le compilateur fait justement le travail de pré-condition dont on parlait. Il ne présume pas de la bonne compétence du programmeur pour effectuer des trucs pourris. Particulièrement le type-checking, même pour les langages dynamiques, par exemple en Java.

Faut juste pas confondre capacité de développer rapidement une fonctionnalité et le faire comme un porc.

Justement c'est bien du premier dont il est question sans y inclure ni y exclure le deuxième. L'enjeu est la rapidité de déploiement, peu importe ce qu'il y a derrière.

C'est ce type de charlots qui pourrissent le métier, métier qui ne t'en déplaise, DOIT être fait par des professionnels, professionnels ayant eu une VRAIE formation et suivant les règles de l'art. Y aura peut être moins de plantages...

Franchement, je pense que je vois plus d'idiotie chez des gens formés (moi-même inclus) que chez les "charlots". Ces derniers sont souvent moins vaniteux et moins confiant et ont tendance à vérifiér 36 fois ce qu'ils font. Ca m'arrive de faire un code pourris sans m'en rendre compte en me disant, c'est simple et je maîtrise.
Bon je dis pas non plus que les "charlots" produisent toujours du bon code, ni même que tous les "formés" sont vaniteux/suffisants/confiants mais je suis pas sûr qu'il y ait un rapport direct entre la qualité d'un code et le parcours de la personne qui l'a écrite.

Si la provenance n,'est pas sure, je teste. Mais dans l'absolu, je ne devrais pas avoir à le faire. Mais je suis d'accord, entre l'absolu et la réalité...

Et ce code t'en penses quoi ?

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
SELECT TOTAL, OK, OK/TOTAL*100 "%OK" FROM (
  SELECT COUNT(*) TOTAL, SUM(IF FOO='BAR' THEN 1 ELSE 0 END IF;) OK FROM FOOBAR
)

?

Justement la vérification de l'écriture, c'est pas ton soft qui le fait, c'est al couche réseu dédiée de l'OS. Dans ce cas là pourquoi ton soft ne fait-il pas une vérification des paquets IP ? Tu te bases donc sur la sécurité d'IP pour travailler. Ton appli se base sur le principe que l'OS est solide. Ce qu'on exoige d'nun OS, pourquoi ne pas se l'éxiger de soi ou des applis amont ?

L'OS te renvoie une erreur, à toi de choisir ce que tu en fais : ignorer, réagir ou planter.
Tu peux exiger ce que tu veux de toi-même mais pas du budget du donneur d'ordre ... Puisque tu parles d'exigence, parlons "Qualité". Un produit de qualité est un produit réalisé dans les conditions définies : coût, délai, fonctionnalité. Par exemple, la tour Eiffel est un très mauvais produit, il a coûté un bras pour un truc qui devait durer jusqu'à la prochaine expo.

2 semaines de négo mais j'ai eu le feu vert.

On en revient à ce que disais el_slapper. Pendant ces deux semaines, ton client a perdu de la compétitivité...



PS : désolé pour le gros retard, la guerre est déjà presque terminée

[el_slapper]

J'espère que sur des modifications apportantes c'est tout de même tester ??? Ceci dit j'ai vu des automates pour centrales électriques passés en production sans plus de tests

Oui, mais pas en automatique. C'est ça, que je voulais dire. il FAUT tester, ne pas le faire relève de la faute professionelle. Mais ça n'est pas possible de manière automatique. Donc, quand on dépend du batch de nuit, le test s'étale toujours sur deux jours.

Bon, j'ai vu des gens faire une confiance aveugle, et livrer en se disant "le format de sortie ne va pas changer, donc tout va bien se passer en aval". C'est de la faute professionelle, et tout c'est mal passé en aval(chez moi). Ca ne signifie pas que le test soit automatisable.

On est dans un environnement de recette, donc peu de monde devrait en dépendre à un instant T.

Sauf que l'instant T est vital. La chaine comptable est un gros monstre, qui doit passer à une heure précise, et s'amuser à la lancer à un autre moment, même en environnement de recette, c'est s'exposer à bien des plantages.

Disons que t'es toujours en amont ou en aval de quelqu'un. Tant qu'on te demande pas de rendre des comptes sur ton précédent c'est déjà ça ^^
Le soucis vient quand les règles de tolérance (données erronées qu'on accepte) deviennent complexes voir contradictoire. Ou alors que le volume d'erreur dépasse largement la limite de l'acceptable. Exemple véridique après plusieurs mois d'EIS : 30% sur le total, plus de 50% sur les données les plus utiles ... On se retrouve alors à rajouter un module qui génère un CSV de synthèse et à ajouter des contrôles de cohérence.

Tiens, j'ai connu ça(sauf que j'ai fait un fichier plat de correction). Ici, au moins, pas de souci : toute donnée fausse entraine le rejet du fichier complet. Mais j'ai vu des applis permissives dans lesquelles on pouvait saisir des choses fausses, et les gérer. A mon sens, il faut soit les rejeter, soit les corriger(si on peut).

Je pense qu'il faut avoir une petite expérience de support ou de suivi d'exploitation pour en avoir pleinement conscience

On en revient à une de mes marottes : nôtre métier est jeune. On est pas en médecine, ou chacun comprend qu'après une opération, même bien faite, le patient doit se reposer. On est en informatique, et tout doit magiquement marcher. Je ne pense pas voir une vision plus réaliste de notre métier parmi les profanes de mon vivant.

Même pas, comme l'a fait remarqué Souviron34, on travaille avec des données analogiques donc par nature instable et incertaine. Un peu comme les saisies utilisateurs sur les applications de gestion.

un point pour toi. Je paye là ma méconnaissance de l'embarqué.

Bof pas tellement. Le langage est super verbeu, limité à 64 colonnes utiles et pas très moderne (limiter à déplacer et tester des données, ou évaluer un paragraphe). Sans parler de l'abscence d'espace locale pour les variables, tout est en "statique" ("Working Area"), les noms des variables ont alors des noms à rallonges.

C'est surtout un langage de niche, très puissant dans son domaine, et impossible en dehors. Enfin, j'ai aussi vu des requêtes SQL de 16 000 lignes...

Si t'as une bonne base de test de non-régression, voir de test tout court, sinon ca va te couter un bras en non-régression...
Une fois j'ai flingué un programme COBOL vraiment mal foutu avec un mélange odieu de GOTO et de PERFORM, impossible de savoir où sortait les appels, ce choix nous aura coûté une bonne semaine de test supplémentaire et autant pour la recette. Bon au final on a bien fait car à la mise en production, ils ont relevés des écarts entre les deux versions ; après analyse c'était l'ancienne version qui était buggée.

Vécu aussi. Sur un programme massif(toutes la génération des courriers de facturation au client). J'ai passé 5 semaines à développer le "comparateur" entre l'ancienne et la nouvelle version. Il n'y avait, au final, qu'une seule erreur sur l'ancienne version, mais de taille : ele mettait le 31 Juin et le 31 Septembre comme date de fin de validité des documents. Comme ces dates n'existent pas, les documents étaient valables juridiquement sans limite de date.....

Sauf que contrairement à Vinci et Bouygues, on passe plus de temps à rajouter des étages à une tour qu'à en faire une nouvelle. Un logiciel ressemble plus à un quartier de Casablanca que La Défense.

Et c'est légitime. Parceque c'est faisable assez facilement, tout simplement. Il faut s'adapter et adapter l'architecture du programme, bien sur, mais il existe des méthodes de refactoring dédiées.

Justement c'est bien du premier dont il est question sans y inclure ni y exclure le deuxième. L'enjeu est la rapidité de déploiement, peu importe ce qu'il y a derrière.

mon expérience, c'est que faire "à peu près propre" ne coute pas plus cher, voire légèrement moins cher. Par contre, si on veut respecter tous les canons de la conception, soudain, les couts explosent. C'est toujours une question de compromis.

Franchement, je pense que je vois plus d'idiotie chez des gens formés (moi-même inclus) que chez les "charlots". Ces derniers sont souvent moins vaniteux et moins confiant et ont tendance à vérifiér 36 fois ce qu'ils font. Ca m'arrive de faire un code pourris sans m'en rendre compte en me disant, c'est simple et je maîtrise.
Bon je dis pas non plus que les "charlots" produisent toujours du bon code, ni même que tous les "formés" sont vaniteux/suffisants/confiants mais je suis pas sûr qu'il y ait un rapport direct entre la qualité d'un code et le parcours de la personne qui l'a écrite.

+1. Je n'ai pas constaté de corrélation entre la formation des gens et la qualité de leurs actions. Peut-être même dans l'autre sens : un autodidacte qui fait de la merde saute rapidement, un BAC+5 sera plus ménagé.

L'OS te renvoie une erreur, à toi de choisir ce que tu en fais : ignorer, réagir ou planter.
Tu peux exiger ce que tu veux de toi-même mais pas du budget du donneur d'ordre ... Puisque tu parles d'exigence, parlons "Qualité". Un produit de qualité est un produit réalisé dans les conditions définies : coût, délai, fonctionnalité. Par exemple, la tour Eiffel est un très mauvais produit, il a coûté un bras pour un truc qui devait durer jusqu'à la prochaine expo.

Dans mes bras.

Après, on peut post-rentabiliser sur les produits dérivés(dans le cas de la tour eiffel, les visites touristiques), mais un film qui échoue en salle, même si il finit rentabilisé, est considéré comme un échec. A raison.

[DridriLaBastos]

Et puis il y a moi, qui n'utilise pas de débogueurs simplement parce que je ne sais pas les utiliser, du coup je fais ce que je peux avec des printfs, des sud::cout ou la fonction 0x0A de l'interruption 0x10