À force de voir différents projets, on finit par identifier de mauuvaises habitudes de développement. Bref des antipatterns. Ceux-ci peuvent conduire certains projets à l’échec voire dans certains cas causer la faillite d’entreprises.
Cet article en liste quelques unes et de bons moyens pour les perdre.
Un des anti-patterns rencontré le plus fréquemment est celui des méthodes jumbo, à savoir de méthodes qui ont une taille se comptant en centaines voire en milliers de lignes. Un des phénomènes de ce type de code est que personne n’ose y rentrer, car il n’est absolument pas débogable hormis par son auteur. Par le passé, je suis tombé sur un joli spécimen d’une telle méthode dont le code ressemblait à ceci :
public void methodJumbo() {
// début du code... 300 lignes
if () {
if () {
if () {
if () {
// 20 if() imbriqués
}
}
}
}
// fin du code... 200 lignes
}
Une telle méthode n’est absolument pas maintenable, car personne n’est capable d’envisager ce qui se passe si on modifie un if() en terme de régressions introduiutes. Dans la même veine il m’est arrivé de tomber sur une méthode Java de plusieurs centaines de lignes de code… fonctionnant entièrement par réflexivité.
Le pire du pire est de tomber sur un bug dans une telle méthode. Il m’est arrivé d’avoir à corriger un segfault sur une fonction C de 3000 lignes de code. Sauf que la stacktrace survenait à la sortie de la fonction et pas à l’endroit de l’erreur. Il a fallu une semaine de débogage pour corriger le problème. Sur une fonction plus courte, il va de soi que le débogage n’aurait pas été si long…
Il existe un moyen très simple de se défaire des méthodes jumbo : écrivez des tests automatisés en commençant par les tests unitaires. Vous constaterez sans problème qu’il est impossible d’écrire des tests pour de telles méthodes dans un temps raisonnable. Ça devrait suffire à vous en éloigner.
De nombreux développeurs estiment qu’il n’est pas nécessaire de mettre des tests automatisés sur leur code. Si cette approche fonctionne à peu près sur un projet de quelques milliers de lignes, dès que celui-ci commence à grandir les mauvaises surprises arrivent. L’application commence à exploser dans tous les sens, et le time-to-market atteint des sommets. Ceci peut à terme nuire gravement à l’entreprise.
Dans certains cas extrêmes, on trouve des développeurs pour qui « si ça compile c’est que ça marche ». Il existe quelques langages comme Haskell pour lesquels c’est assez vrai, mais ceux-ci restent une minorité. De manière générale je conseille fortement à quelqu’un qui aurait cet état d’esprit de changer d’urgence de mentalité… ou de changer de métier.
La première étape est de faire intervenir un coach pour que celui-ci initie le processus de mise en place des tests automatisés… ou alors l’entreprise peut embaucher quelqu’un qui est converti à cette démarche, ce qui serait bénéfique. Il s’agit d’ailleurs souvent d’un excellent développeur, mais avis à ceux qui ont des oursins dans les poches, cette personne se monnaie cher.
Ensuite, il convient de mettre en place un rôle de chien de garde, qui surveillera la qualité du comme committé ainsi que les tests. Il est important que ce rôle soit tournant pour que tout le monde se sente impliqué.
Enfin on pourra également paramétrer le serveur d’intégration continue pour faire échouer les builds en dessous d’une certaine couverture de tests.
Ce point est plus controversé, et pourtant il suffit d’une vue de l’esprit pour le comprendre. Quand vous développez, à un moment ou l’autre vous créez une API qui permet de dialoguer avec l’extérieur. Ce dernier sera bien souvent constitué d’autres développeurs de la même équipe, ou d’autres équipes.
Alors pour bien mettre les points sur les i il convient de se souvenir qu’une API est un contrat, et par conséquent elle doit être documentée de manière exhaustive. Doivent notamment apparaître, pour chaque classe et chaque méthode de l’API :
Pour rappel, toute méthode avec visibilité public ou protected fait partie de votre API et doit donc être documentée, de même que les classes qui contiennent ces méthodes.
Un autre avantage de prendre l’habitude de documenter votre code est que ceci vous force à comprendre ce que vous faites. Ça paraît stupide mais c’est important. Car en documentant, vous vous forcez à expliquer à autrui ce que vous avez fait, ce qui vous oblige à l’avoir compris au préalable.
La documentation devrait se trouver dans le code et être générée avec des outils comme Doxygen ou encore Javadoc. Seuls les points d’entrée de votre code ainsi que les documents d’architecture doivent se trouver dans un Wiki ou tout autre document externe. C’est ainsi qu’on simplifie la maintenance de cette documentation, car pour rappel, une documentation incorrecte est pire que pas de documentation.
On peut mettre la tâche de documentation dans ce qu’on appelle le definition of done. Ou encore faire planter les builds ou les commits si la documentation n’est pas là. Ça ne couvrira pas tous les cas, mais ça obligera les gens à un minimum de rigueur.
Enfin, le chien de garde, cf. ci-dessus, devra veiller à la qualité de la documentation.
Pour finir, il est important de rappeler que le management des entreprises a souvent une très large responsabilité des mauvaises habitudes prises par les développeurs. La première cause imputable au management est le respecter vos développeurs. Autrement dit ne leur demandez pas systématiquement de faire les choses pour hier, ne mégotez pas sur un jour ou deux de délai supplémentaire, et surtout évitez le management par la pression. Ce dernier fonctionne à court terme mais est dévastateur à long terme, pour les équipes et pour le produit. Et rappelez-vous : un fort turnover est synonyme d’un problème de management, et conduit à une baisse drastique de la qualité du code.
Autre point tout aussi important : payez correctement vos développeurs et ne mégotez surtout pas sur les salaires. Les bons développeurs sont demandés, et valent cher. Et un projet sur lequel il n’y a pas ou trop peu de bons développeurs est un projet voué à l’échec. De nombreuses start-ups échouent parce qu’elles n’ont pas le bon personnel pour mettre en oeuvre leur projet, à bon entendeur…
Forcez-vous aux quelques astuces évoquées ci-dessus, vous en constaterez rapidement les bénéfices. Et surtout souvenez-vous, small is beautiful. Je vous conseille d’ailleurs une très bonne lecture, le livre The Clean Coder de Robert C. Martin aka Uncle Bob.
Ceci dit le management a une responsabilité indéniable dans ces mauvaises habitudes. C’est à lui de prendre les bons profils, mais surtout de les respecter. Si ce n’est pas fait, nul doute que les mauvais réflexes reviendront rapidement pour tenir les délais irréalistes…
Besoin de tester ton niveau en développement informatique ?
Cet article vous a plu ? Vous aimerez sûrement aussi :
Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.
Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.
Les maladies inflammatoires chroniques de l’intestin ou "MICI" sont invisibles, mais leurs impacts sur la…
Depuis l'été, j'ai un Pixel qui intègre à la fois un TPU (Tensor Processing Unit)…
On se retrouve dans un nouvel article avec toutes les infos sur cette nouvelle saison…
Pourquoi l’inclusion numérique est essentielle : le point avec Mathieu Froidure. Dans un monde de…
Elles sont passées où les femmes dans la tech ? Entre le manque de représentation…
