[DUMD 2/24] Pourquoi s'améliorer ?

Auteur du billet de blog : Nicolas Hilaire - Neotech Solutions

Nicolas Hilaire

Consultant .NET
  Publié le mercredi 26 octobre 2016

Artisan logiciel particulièrement intéressé par les technologies .NET. Polyvalent et curieux, je suis néanmoins à l'écoute des autres technologies du marché. MVP (Microsoft Most Valuable Professional) de 2007 à 2014, je suis également auteur d'un ouvrage pour apprendre le C#, à destination des débutants et de plusieurs MOOCs sur le C#, Windows Phone ou ASP.NET MVC...

Second billet sur comment devenir un meilleur développeur. Pour retrouver le sommaire ainsi que tous les liens, rendez-vous sur le premier billet.

 

S'améliorer, ce n'est pas forcément faire moins de bug, ou maîtriser le dernier framework à la mode.

Même si forcément je ne vous blâmerai pas de vouloir faire moins de bug dans votre code, le but principal d'un développeur d'application est de faire en sorte que son application fonctionne mais surtout qu'elle puisse évoluer avec le moins de douleur possible et que son maintien en conditions opérationnelles soit le plus simple possible.

 

Le changement comme constante

Vous avez dû vous en rendre compte, le changement est omniprésent dans le cycle de vie d'une application. Il doit être pris en compte et doit être accueilli avec bonne volonté (ceci fait partie des principes de développement agile dont nous parlerons plus tard). Il est très rare que l'on vous demande de réaliser une application, dont le périmètre est complètement clair, qui ne changera jamais au cours du développement et qui n'évoluera jamais par la suite. Le client (le chef, le donneur d'ordre appelez-le comme vous voulez) va constamment venir vous demander de changer des choses. Peut-être parce que tout n'est pas encore complètement clair dans sa tête, ou parce que son besoin change au fur et à mesure, parce qu'il doit s'adapter à la concurrence, ou parce ce qu'il a besoin de nouvelles fonctionnalités, etc.

 

Bref, soyez sûrs d'une chose : votre application va changer.


Vous devez donc faire en sorte que votre code soit ouvert au changement. S'améliorer, c'est apprendre des solutions éprouvées, des principes de conception, qui vont permettre à votre code d'accueillir le changement sans souffrance.

Il est fort probable qu'on vous ait demandé un jour de faire un changement ou une évolution et que vous ayez répondu "oulala, changer ça va être compliqué pour telle et telle raison". Un code qui n'est pas facile à changer est dit rigide. Et un code rigide ce n'est pas bon pour notre ataraxie de développeur.

 

Un code plus facile à maintenir

Votre code va évoluer, mais il va également falloir le maintenir ; corriger d'éventuels bugs. Si vous allez chez le garagiste pour faire réparer votre levier de vitesse et que quand vous récupérez votre voiture, votre levier de vitesse fonctionne mais du coup la vitre électrique ne fonctionne plus. Vous allez fatalement vous dire que ce garagiste est incompétent et vous irez en voir un autre la prochaine fois.

Pourtant, je suis sûr qu'il vous est déjà arrivé de corriger un bug dans une application et que cela a fait apparaître d'autres bugs à d'autres endroits de l'application, qui n'ont rien à voir avec ce que vous avez corrigé. Vous vous doutez bien que si votre client vous demande de changer le bouton d'ajout au panier et que du coup le paiement ne fonctionne plus, il va se demander si vous êtes vraiment compétent.

Malheureusement il est très facile de produire du code que l'on appelle fragile, et ceci est tellement commun que vous l'avez sans doute vécu dans votre vie de développeur.

 

Réduire la complexité

Vous avez sans doute dû également intervenir sur du code tellement obscur qu'il est très compliqué de savoir d'où vient un problème et comment le corriger. Pourtant, ce code était clair et propre au début, qu'a-t'il bien pu se passer entre-temps ?

Plus le temps passe et plus un code à tendance à se dégrader. Le maintenir dans un état convenable est une tâche complexe qui nécessite un investissement durable. Il faut sans cesse le remanier (faire du refactoring, en anglais) à chaque évolution ou correction de bug. Il est important également de faire une intervention en gardant toujours en tête de respecter l'évolutivité de la conception. Il est tellement facile de prendre des raccourcis, de faire des hacks ou des verrues.  Nous sommes développeurs, pas dermatologues ; alors pas de verrues s'il-vous plait. :)

Oui je sais, nous sommes pressés, nous avons des dead-lines, le client râle... Il n'empêche que faire une chose mal dans la précipitation risque de vous y faire revenir plus tard.

 

Conclusion

Il est très facile de faire du code de mauvaise qualité, difficile à maintenir et à faire évoluer.  Mais tout n'est pas perdu, rassurez-vous ! C'est justement l'objectif des billets suivants, vous montrer comment faire du code de qualité. Et cela passe par une constante quête de l'amélioration, d'apprentissage et de remise en question.

Prochain billet : Ecrire du code propre.

Commentaires