Notre quotidien de développeur consiste très souvent à modifier du code existant. Certes, nous avons parfois la chance de développer de nouveaux modules tout frais, tout neufs et le Test Driven Development est à son avantage.
Mais comment peut-on mettre en pratique le TDD sur du code déjà écrit, parfois mal pensé et non testé. Cet article va partir d’un exemple concret, une classe comme on pourrait en trouver sur tous les projets. Le but est de commencer une démarche TDD et de pousser au maximum son efficacité (mise en évidence d’un bug potentiel, ajout d’une nouvelle fonctionnalité, refactoring du code et refactoring des tests). Au final, la classe sera beaucoup plus apte à subir le changement et surtout, elle sera testée et couvrira tous les cas d’utilisation.
Lire la suite de cet article »
Le 4 Juin 1996, à 9h35 le vol 501 de la fusée Ariane 5 effectue son premier décollage. Quelques secondes plus tard, le système de guidage inertiel reçoit trop d’informations et se met hors service, car reconnu défaillant. L’ordinateur de bord est alors notifié qu’un dysfonctionnement est en cours et compromet les informations concernant la trajectoire de la fusée. Cette modification de la trajectoire entraîne l’arrachage d’un moteur d’appoint, déclenchant l’auto destruction de la fusée. Des analyses plus approfondies ont démontré que le système de guidage inertiel est lui même la cause de cet échec. Conçu à l’époque pour Ariane 4, il n’était plus nécessaire pour Ariane 5. Maintenu actif pour des raisons de commodité, ce système s’est avéré être à l’origine d’un des bugs informatiques les plus coûteux de l’histoire.
Au-delà du caractère spectaculaire de cet exemple, il est intéressant de noter que l’origine du dysfonctionnement réside dans un module développé pour une version antérieure de la fusée et devenu obsolète. Ce vestige de code, maintenu dans l’application sans être nécessaire pour son fonctionnement, est l’une des formes de ce que Ward Cunningham désigne sous le terme de dette technique.
A travers ce document, nous découvrirons en quoi la dette technique ralentit la productivité des équipes et nuit aux projets. Nous mettrons en évidence ses mécanismes sous jacents et les leviers d’actions dont nous disposons. Enfin, nous montrerons comment elle se gère au quotidien, par l’instauration de bonnes pratiques de développement et la mise en place d’outils, pour enfin aborder quelques stratégies complémentaires, mais essentielles pour venir à bout de la dette technique.
Télécharger le Livre blanc « Maîtrisez votre dette technique ».
L’évangéliste pragmatique du software craftsmanship, Robert Cecil Martin alias Uncle Bob était l’invité d’honneur de Xebia pour un atelier software craftsmanship sur le code propre (a.k.a Clean Code).
Pendant 2 jours, se sont succédés conseils pratiques, prises de conscience (« aha… »), analogies originales, discussions sur l’industrie à l’heure du repas, randori TDD, kata, coding dojo, décortication minutieuse de classes, effacement de nombreuses lignes de code inutiles et ses fameuses diversions scientifiques (de la mitochondrie au réchauffement du soleil). Tout ça saupoudré d’une expérience de 40 ans dans l’industrie logiciel aux Etats-Unis.
Instants choisis.
Lire la suite de cet article »
Hier, comme tous les premiers jeudi du mois, se tenait notre XKE (Xebia Knowledge Exchange) lors duquel nous étions tous réunis pour échanger autour de sujets techniques passionnants.
Après le traditionnel café du matin, la journée a commencé par une session de Craftsmanship autour du Refactoring to Patterns animée par Simon Caplette et Benoit Guérout.
Nous enchainons avec un challenge amusant autour du langage Java animé par Nabil Gasri.
Après la pause déjeuner, Michael Figuière nous a présenté son retour d’expérience sur le développement d’applications web à fortes affluences.
La journée de XKE s’est achevée par deux sessions parallèles :
Pour les plus courageux, les discussions ont continué en soirée à l’occasion d’un pot improvisé.
Gérer les modifications d’une base de données est toujours une affaire délicate, que ce soit lors du développement d’une application, pendant le déroulement des tests unitaires et même lors du déploiement en production.
On observe un grand nombre de difficultés, en particulier dans les projets Agile, où les changements sur le modèle de données sont fréquents.
A l’heure actuelle, peu d’outils sont disponibles sur le marché et on pense rarement à les mettre en place sur nos projets. On passe par des solutions « maisons » avec toutes les difficultés que cela peut engendrer.
Tout d’abord, nous ferons un point sur les problèmes posés par la gestion des bases de données, puis nous verrons comment Liquibase, outils de refactorisation, peut nous aider à les surmonter.
Nous continuerons par la description de ses caractéristiques et fonctionnalités principales et par les différents moyens de l’exécuter.
Un petit exercice pour se familiariser avec cet outil viendra conclure ce billet.
Lire la suite de cet article »
Complet
Twitter
