Ce site web stocke des informations vous concernant via le dépôt de cookie afin de mesurer l’audience du site. Ces données de navigation sont anonymisées.
En cliquant sur « OK pour moi », vous manifestez votre consentement pour le dépôt de ces cookies.
Sur ce site, nous utilisons des cookies pour mesurer notre audience, entretenir la relation avec vous et vous adresser de temps à autre du contenu qualitif ainsi que de la publicité. Vous pouvez sélectionner ici ceux que vous autorisez à rester ici.
Nouvelle année, nouvelle édition du FOSDEM (Free and Open Source Developers’ European Meeting). Après une édition 2018 bien fournie le cru 2019 s'est également révélé de bonne qualité. Impossible de lister tout ce que nous avons pu voir sur ces deux jours... Comme l'an dernier nous reviendrons donc sur certaines tendances qui nous ont marqué.
Lire la suite
La dette technique peut être définie de plusieurs façons, selon le point de vue : code, logiciel, infrastructure ou le SI en général. Dans cet article, nous allons faire un focus sur la dette technique dans le SI, ses impacts et comment la traiter.
Lire la suite
Le code de vos projets n'est jamais parfait et se détériore avec le temps. C'est un problème important car, s'il est mal maîtrisé, vos temps de développement seront plus longs et vos bugs plus fréquents.
Lire la suite
L’endettement de nos systèmes d’information Ward Cunningham introduisait en 1992 la métaphore de la dette technique faisant une analogie entre les coûts futurs liés aux choix de conception logicielle et une dette financière. Celle-ci introduisait la nécessité de mettre en application des Design Patterns permettant de mieux maitriser la dette technique. En 2009, Ward Cunningham revenait lors d’une interview sur le fait que l’objectif premier n’était pas d’apurer totalement la dette technique mais de s’attacher à la maitriser dans le temps. Pour illustration, l’éditeur CAST…
Lire la suite
En ingénierie logicielle, tant qu'un projet se développe, la dette technique s'accumule inexorablement. Les sessions de refactoring sont là pour contrebalancer cette tendance et leur mise en place régulière garantit la maintenabilité du projet. Mais ce qui est délicat avec la dette technique, c'est qu'elle n'est pas vraiment mesurable, et comme l'iceberg, on n'en voit que la partie émergée. Résultat, le refactoring est souvent sous-estimé et mal maitrisé. Si on ajoute à cela une mauvaise couverture de test, refondre le code applicatif fait peur, fait…
Lire la suite
