Kata refactoring legacy code chez Ossia

Christian

Le premier kata ossiens s’est déroulé le 11/02/2016. Le thème était refactoring Legacy Code. Je me suis donc retrouvé, développeur .Net, avec une majorité de Java-iste :).

Ce fût une excellente soirée d’échanges autour de nos technologies respectives. J’espère que j’aurais l’occasion de faire un kata en Java la prochaine fois.

La base choisie était le kata TripService de Sandro Mancuso disponible ici sur github.

Les réflexions de la soirée sont disponibles ici sur github : https://github.com/MacReiben/KataOssia-201602.

N’oubliez d’envoyer vos idées pour la soirée du mois prochain !

@ bientôt !

facebooktwittergoogle_plusmail

La sous qualité, une norme ?

Christian

Je me rends régulièrement au meetup Software Craft(wo)manship in Paris. Lors de la dernière séance une discussion concernant la qualité du code s’est engagée.

La sous qualité comme sous norme

Un constat des craftmans présents est que la qualité coûte cher. Ce constat vient de la vision court-termiste qu’a le client de son application.

Le temps de développement est perçu comme un poste de dépense. Il faut délivrer le plus vite possible. Il en résulte une pression accrue sur les équipes de développements qui n’ont plus le temps de structurer et développer un produit fini.

Le résultat est une application buggée. Le développement de fonctionnalité se transforme en TMA. Plus exactement, l’équipe répare.

La qualité coûte cher

Voici un des principaux préjugés qui explique la « normalisation » de la sous qualité.

Le client perçoit son logiciel comme une dépense, un fardeau. C’est pourtant un investissement qui lui permettra d’augmenter sa performance.

Sans faire de calculs profonds, une TMA de plusieurs mois (année ?) coûtera plus chère qu’une majoration 15 à 30% du temps développement initial avec TDD.

Trouver les arguments

Réduction du turn over

La qualité du code a un effet sur le moral des équipes. Une mauvaise qualité de code entraine une démotivation. La perspective des développeurs au réveil le matin s’apparente à réparer ce qui s’effondre pour pouvoir livrer les ruines.

Le développeur finit par partir, lassé. Il faut le remplacer – et mobiliser des ressources pour recruter.

N’oublions pas que la sous qualité engendre la sous qualité. Il devient de plus en plus difficile d’ajouter des fonctionnalités sans provoquer des régressions. La correction des régressions consume le temps prévu pour les évolutions. C’est un cercle vicieux.

Le logiciel en tant qu’investissement

Le monde est digitalisé en ces derniers jours de 2015. Il n’est par exemple plus possible pour une banque d’investissement d’avoir une panne de son système d’information. Il n’est pas envisageable pour un trader d’être incapable de conclure une transaction.

Le logiciel est, dans l’exemple des BFIs, au centre du business. Il permet de conclure le deal avant le rival. Les logiciels sont les outils sur lesquels reposent les marchés.

Au même titre qu’un couteau émoussé, un logiciel buggé, instable, avec un time to market trop important, ne permettra pas à son utilisateur de travailler correctement. Il perdra du temps.

Les bugs cassent le workflow de l’utilisateur. Il doit s’interrompre dans son travail. L’apparition de bug dénote l’instabilité qui réduit la confiance de son utilisateur dans son outil.

Le développement d’une fonctionnalité prends des mois – le fameux time to market – l’utilisateur exécute manuellement des traitements automatisables en attendant sa fonctionnalité.

En un mot l’utilisateur perds du temps. Ce qui, en finance, peut prendre des proportions vertigineuses…

Conclusion

L’amélioration de la qualité de code par l’utilisation de méthodologies telles que TDD ou BDD permet d’améliorer la fiabilité des livrables.

Elle représente un coût réduit par rapport à une TMA de plusieurs mois. D’autre part, une bonne qualité permet de réduire le turn over. Coté utilisateur, la qualité donne confiance à l’utilisateur dans votre équipe.

Enfin un code de qualité garantit la possibilité pour une application d’évoluer sereinement.

Conseil lectures

facebooktwittergoogle_plusmail

Unity : tester l’instanciation des classes

Christian

Cela fait plusieurs fois que je rencontre le problème des enregistrements manquants dans Unity. Le projet se lance et on obtient l’erreur suivante :

Les applications en entreprise nécessitent souvent que des webservices soient lancés, des cas de tests créés etc … .
Mettre toutes ces conditions en place prends du temps – pour parfois aboutir à ce message d’erreur, et être obligé de tout recommencer.
Heureusement il est possible d’automatiser.
Régler le problème d’un test unitaire
Pour pallier à cette perte de temps, voici un test unitaire qui instancie tous les types définis dans Unity.
J’utilise dans cet exemple MSTest comment moteur de test et FluentAssertions comme librairie d’assertion (plus lisible que la librairie d’assertion classique).
La collection _typeToExclude donne la possibilité d’exclure certains types au cas où.

Enjoy !

 

facebooktwittergoogle_plusmail