Openweb.eu.org

La dette technique en exemple

inf0mag — 2014-11-27T21:06:29Z

C'est vrai que si des tests bien aboutis ont été menés par les développeurs à l'époque on aurait pu éviter tous ces problèmes, mais il faut signaler que malgré les tests, on n'est jamais sur à 100% qu'un logiciel est exempt de bugs (surtout s'ils se manifestent pas lors de l'exécution des scénarios de tests)

La dette technique en exemple

Laurentj — 2014-07-30T13:34:00Z

@Alexeo : le problème de la dette technique est tout aussi critique dans une PME que dans une grosse boite. Ça peut même être pire, car une PME n'aura probablement pas autant de moyen humain et financier à mettre derrière la résolution d'un problème. Et si en plus le site de cette PME est sa principal source de revenu, et qu'il faille couper l'accès plusieurs heures à cause d'un crash ou d'une restauration d'un site, cela peut être dramatique. (et puis, la taille de la boite ne présage pas le volume de données géré).

À cela il faut ajouter la loi de Murphy (http://fr.wikipedia.org/wiki/Loi_de_Murphy) : si la dette technique peut aboutir à une catastrophe, soyez sûr que cela arrivera.

Donc non, la dette technique n'est pas à négliger, que l'on soit PME ou grand groupe.

La dette technique en exemple

Nicolas Hoffmann — 2014-07-14T08:31:39Z

Bonjour,

détrompez-vous, la dette technique menace tout le monde, même les petites structures. C'est très facile d'en accumuler, vu que ce sont parfois des problèmes dormants. Attention quand ils se réveillent.

La dette technique en exemple

Alexeo — 2014-07-11T14:07:35Z

Bonjour,
Je ne connaissais pas cette notion de dette technique et je la découvre au travers de votre article. C'est un très très bon exemple que vous nous proposez.
En revanche, il s'applique à de très grosses structures car je ne pense pas qu'on puisse se retrouver dans ce genre de situation au sein d'une PME. Sauf bien entendu si l'activité explose et implique de mettre en place de gros moyens.
Merci pour cette lecture.

La dette technique en exemple

Arnaud LEMAIRE — 2014-05-30T09:03:19Z

Au delà du concept de dette logiciel, j'aime beaucoup l'idée de l'entropie appliquée au logiciel.

Ce principe exprime qu'un système ne peux qu'évoluer que vers plus de désorganisation ce qui implique que la dette logicielle est quelque chose de "naturel" dans le cycle de vie d'un logiciel.

Il faut donc avoir une attention de tous les instants pour lutter contre la production de dette.

J'explique plus en détail cette réflexion dans un article http://lilobase.wordpress.com/2014/...

La dette technique en exemple

Nicolas Hoffmann — 2013-04-29T10:35:50Z

> Très bon article qui part d'une histoire vraie.

Qui est une histoire vraie, certifiée vécue par l'auteur :)

La dette technique en exemple

Nicolas Chevallier — 2013-04-27T19:27:18Z

Très bon article qui part d'une histoire vraie. C'est évident q'un projet évolue au fil des années et qu'il vaut mieux batir le site sur des fondations solides pour éviter que l'on s'arrache les cheveux (ou que d'autres se les arrachent après nous le plus souvent).

Mais il ne faut pas oublier l'inverse que j'ai vécu : un entrepreneur qui a une bonne idée et qui décide de se lancer sur le net. Comme il se projette à moyen/long terme, il décide de gérer dès le lancement plusieurs langues, plusieurs monnaies... Un an après le site est lancé mais il est lent, mal référencé et au final inutilisable en l'état. C'est là ou j'interviens et qu'une décision radicale est prise pour "simplifier" le tout quitte à casser et à rendre le site moins évolutif sur le long terme. Au final le site décolle.

Je pense qu'on ne peut prévoir de telles évolutions (à l'international) et qu'il est difficile d. J'imagine qu'en 8 ans aussi les outils ont changé, les technos, les bibliothèques... Bref une refonte globale était peut être même nécessaire et n'était pas prévisible au lancement.

Nicolas Chevallier

La dette technique en exemple

Mem’s — 2013-04-17T09:20:06Z

Tous les problèmes n'ont pas le même impact, ceux touchant au données sont les plus importants (surtout dans la situation présenté).

D'autres problèmes qui peuvent aboutir à une dette technique sont des fonctionnalités qui sont utilisés autrement que ce pour quoi elle ont été prévues. Sur du front-end, par exemple, on utilise le user-agent pour détecter si c'est IE, Firefox ou Safari iOS et produire du code (HTML/CSS/JS) adéquate pour contourner les bugs actuels. Seulement ces tests ne prennent pas en compte le forward compatibility, le cas où le bug à été réparé dans une version ultérieur ou qu'une version plus récente d'un navigateur ne s'identifie pas de la même façon que les version antérieurs (cf. IE 11 vs. IE 10-).
D'autres exemples existent comme l'utilisation de propriétés/fonctionnalités CSS/JS préfixés sans prendre en compte une version non préfixé. Ex. : -webkit-transform: rotateX(120deg); nécéssite aussi qu'on utilise transform: rotateX(120deg); pour les navigateur implémentant le Standart REC (Recommendation).