Discussion :

[unparia]

Ce qui est à pérenniser c'est le code (je pense) faire qu'il soit explicite et qu'il puisse être repris par quelqu'un d'autre.

J'insiste donc : Pérenniser le code ne sert à rien tant que ce qui doit être fait en amont n'est pas fait.

Pour ma part, je ne vois pas la différence.

Elle est E N O R M E !

Il n'y a pas de cahier des charges, de consignes, rien de rédigé.

L'essentiel manque donc. Essentiel, car ces spécifications fonctionnelles sont la définition même de la vocation de l'application.
D'autant qu'à un moment ou à l'autre, il va en plus falloir mettre "en regard" les spécifications fonctionnelles et les spécifications techniques (au moins cela, même si l'on a fait "harakiri" de la modélisation des données).

Ta réaction fait que je n'ose même plus de parler des différentes dépendances, à divers niveau et de diverses natures (aucune pérennisation n'est possible sans les isoler et les prendre également en compte)

Crois-tu vraiment que l'intervention de ton jury était "gratuite" et "naïve" et n'avait pas un sens et une vocation très justifiés (à deviner) ?
On ne compte plus les colères de différents responsables informatiques, responsables de centre de traitement de l'information, chefs de projet etc ... causées par la découverte de la présence de nombreuses petites applications qui n'observent pas les règles nécessaires à :
- leur définition
- leur recensement
- leur suivi
Le fait est qu'elles sont la plupart du temps construites à l'aide d'applications bureautiques, dont Excel.

[el_slapper]

Concernant les test unitaires, ce que j'ai compris c'est qu'il faut venir tester les fonctions une à une et vérifier qu'elles fonctionnent bien toutes. Mais si ma macro globale fonctionne c'est que toutes les fonctions présentes fonctionnent... ? Peut-être que je me trompe.(.../...)

Le cycle de vie d'une application, c'est 20/30% en développement, et 70/80% en maintenance. Enfin, une application pérenne. Or, ta question porte sur la pérennité. Donc il faut que tu sois fiable dans le temps, facile à maintenir. Quand tu reviens sur une appli un peu vieille, tu ne sais plus très bien quoi fait quoi. Les tests unitaires servent en partie à ça : tu regarde comment ça appelle la fonction, et tu comprends comment ça marche.

Mais le vrai plus, c'est quand tu dois changer ta fonction/procédure/méthode/propriété. Les vieux tests unitaires que tu as écrit dans une autre vie doivent toujours tous passer OK. Sauf, évidemment, là ou tu as spécifiquement changé ton comportement. Exemple : on gère des payements pour un tas de trucs. On a une fonction centralisée un peu compliquée qui ramène le type de payement, et qui est appelée partout. Ca marche. On est contents. Bon, dedans, il y a une règle un peu relou qui veut qu'un paiement par TIP se fasse en fait par chèque si le montant dépasse un million d'euros. tout simplement parce-que les TIP pré imprimés n'ont que six cases avant la virgule.

Bon, le temps passe, et puis le fournisseur de pré imprimés ajoute deux cases. Cool. Mais il faut changer la fonction(d'ou l'intérêt d'avoir fait des petits bouts, si tu faisais la décision pour chacun de tes 23 produits, tu serais chocolat - mes collègues avaient raison de t'inciter à faire des petits morceaux). Une fois. Puis la tester.

Si tu as fait correctement ton test unitaire, dans le temps, tu as juste à adapter au nouveau comportement : un payement prévu par TIP qui dépasse le million se fait toujours par TIP, il faut qu'il dépasse les 100 millions pour forcer le paiement en chèque. Tout le reste, les virements de toutes sortes, ne change pas. Et tu en as pour 10 minutes à valider ton changement. Si tu n'as pas fait de tests unitaires automatisés, par contre, le risque de régression est grand. Une régression, c'est quand on corrige un truc à droite, et qu'on casse un truc à gauche. Ca arrive tout le temps. Et, avec des tests unitaires bien pensés, ça se détecte tout de suite, on répare, et on évite de transformer un virement en paiement par chèque, ou vice-versa.

En bref : les tests unitaires automatisés sont modérément utiles lors du développement initial - pas inutiles, pas transcendants non plus - mais ils deviennent essentiels quelques mois après leur écriture. Une appli, ça vit, et il faut des outils pour vérifier qu'on ne casse pas tout à chaque maintenance.

[Pierre Fauconnier]

Oparion,

J'ai deux questions: En quoi es-tu étudiant et quel est le sujet du travail que tu présentes au jury?

[Oparion]

@Pierre Fauconnier :

Je suis étudiant en Sciences.
Pour ma deuxième soutenance je vais leur présenter mes travaux sur les incertitudes liés à des bancs d'essais.
Concernant Excel, je ne vais plus rien présenter (normalement).
Comme je l'avais noté je n'ai plus de comptes à rendre au jury sur ce point.
Mais pouvoir laisser un code documenté, c'est ce que m'a demandé mon maître d'apprentissage.

[unparia]

pouvoir laisser un code documenté, c'est ce que m'a demandé mon maître d'apprentissage.

J'imagine (c'est un minimum).
Ce n'est cependant pas l'objet de la discussion que tu as ouverte, ni (au vu de ses réactions, que tu rapportes toi-même) la réponse qu'attendait ton jury, hein ...

[Oparion]

@unparia :

En effet, un professeur m'a dit : Ce n'est pas suffisant.
Donc me voila à la recherche de solutions