Avec le temps qui passe, de nombreux projets IT ont tendance à s’effondrer sous leur propre poids. Ca peut se traduire notamment par des milliers de lignes de code impossibles à maintenir et qui fonctionnent par coïncidence, une impossibilité de faire évoluer fonctionnellement les projets, ou encore une lourdeur qui rend l’utilisation pénible. Et pourtant si chacun y met du sien il est possible d’éviter ça…
Débloque les + belles offres tech en 10 mins
Mener à bien un projet IT requiert en fait que tout le monde joue le jeu :
– Le client, qui doit être disponible pour toute question.
– Les développeurs, qui doivent tenir une certaine rigueur.
– Le management, qui ne doit pas tout exiger pour hier.
Si une de ces conditions n’est pas respectée le projet va droit à l’échec sur le long terme.
Une bonne méthodologie pour arriver à ce qu’on veut consiste à adopter le Domain Driven Design. Ceci permet de garantir en permanence une cohérence entre ce que pense le client, et le code qui est effectivement implémenté. Et donc en favorisant le dialogue la maintenabilité du code ne s’en trouve que renforcée.
Dès lors qu’un projet fait intervenir plusieurs personnes sur le code, il convient de nommer un chien de garde qui sera là notamment pour surveiller les commits et vérifier que le code ne part pas dans toutes les directions. Au besoin cette personne n’hésitera pas à annuler un commit qui ne respecterait pas les règles et voir le développeur en question pour qu’il corrige son travail. En fait à ce niveau il ne faut pas hésiter à être comme à l’armée, à savoir appliquer des règles strictes et corriger tout comportement déviant… 😉
Afin d’impliquer tout le monde dans le process qualitatif, il peut être souhaitable que le rôle de chien de garde tourne. Quand l’équipe commence vraiment à grossir, il convient de découper le projet en sous modules, chacun ayant son chien de garde responsable de la qualité du code produit.
Néanmoins comme tout ce qui a trait à l’informatique on peut automatiser de nombreuses choses. Aussi on pourra mettre en place au niveau du gestionnaire de sources des règles qui rejettent automatiquement un commit qui ne satisferait pas tel ou tel critère. Parmi ceux-ci on pourrait tout à fait imaginer faire un audit automatique du code avec un outil comme FindBugs et rejeter celui-ci si des erreurs apparaissent lors de la validation.
Vos APIs doivent être correctement définies, correctement documentées et surtout leurs entrées doivent être contrôlées. Ainsi si une méthode n’accepte pas qu’on lui passe la valeur null elle doit immédiatement lever une exception avant même d’aller plus loin. Tout ça aide notamment à détecter au plus vite les erreurs.
On parle de la définition des APIs dans cet article.
Au cours de la vie d’un projet les équipes tournent, et la base de code grossit. Aussi pour un nouveau développeur rien n’est pire que de faire de la rétro-ingénierie sur une API qui n’a pas été documentée. Et c’est encore pire quand derrière cette dernière on trouve des milliers de lignes de code.
Aussi il est nécessaire de documenter vos APIs, et de maintenir la documentation en question. L’intérêt de la chose est multiple :
Pour la plupart des projets les tests automatisés apparaissent indispensables. En fait les seuls cas où ceux-ci ne sont pas applicables concernent le dialogue avec le matériel, ainsi que les appels à des ressources externes comme des connexions réseau. Ceux-ci doivent être exécutés rapidement, et maintenus.
Je ne vais pas m’étendre sur le sujet, on en a déjà parlé, cela dit n’oubliez pas qu’une application bien couverte par des tests est généralement bien designée, car sinon ceux-ci ne seraient tout simplement pas réalisables.
De plus en plus de projets utilisent des serveurs d’intégration continue. On a déjà traité le sujet. L’important ici est que chacun ait bien la discipline que dans le cas où le serveur indique que des tests automatiques échouent, ou que la compilation ne passe plus, les développeurs s’arrêtent de travailler jusqu’à corriger le problème.
Ceci requiert néanmoins une infrastructure suffisante. J’ai déjà vu des serveurs d’intégration continue hébergés sur des VMs et les builds mettaient plus d’une heure à s’exécuter. Pour du feedback rapide, c’est raté, d’autant que ça incitera les développeurs à remettre à plus tard la correction des problèmes.
Personnellement quand je code je définis d’abord la signature de la méthode avec la documentation, ensuite un test unitaire et après seulement je commence à écrire mon code.
A noter que vous n’êtes cependant pas obligé de documenter les méthodes private, mais tout ce qui est visible à l’extérieur devrait l’être.
En fait le management par la pression peut fonctionner un temps, mais très rapidement on en arrive au cercle vicieux suivant :
Par ailleurs un développeur sous pression adoptera facilement la méthode RACHE, ce qui nuira gravement au code. C’est pourquoi il convient d’être raisonnable sur la charge de travail quotidienne des développeurs. Huit heures par jour doivent être un grand maximum. Et c’est sans compter les problèmes de santé qui peuvent survenir sinon, tels que le burn out, et qui coûtent très cher aux entreprises.
On peut comprendre parfois qu’il y ait des coups de bourre, mais ceux-ci ne devraient survenir que parce qu’il y a un bug critique à corriger dans l’application, et pas parce qu’on ne respecte pas les deadlines.
Par ailleurs le management par la pression a une influence directe sur le turnover en l’augmentant, et un taux de rotation élevé est ce qu’il y a de pire en terme de qualité de code. Si, si, croyez-moi, on voit très rapidement ce genre de chose rien qu’en lisant ce qui est produit !
Il existe en fait deux types de deadlines :
La première n’est en fait pas une vraie deadline. Il vaut mieux en effet sortir un logiciel en retard par rapport au planning souhaité mais qui soit stable que tenir les délais et sortir un machin inutilisable. Pour vous donner une idée, de plus en plus d’éditeurs n’hésitent plus à décaler les dates de sorties des logiciels pour que ceux-ci satisfassent des critères de qualité. D’ailleurs un respect absolu des deadlines peut coûter très cher à l’éditeur.
Nous voyons maintenant comment gérer les secondes, qui sont là de vraies deadlines.
Pour traiter ces deadlines, en fait il suffit de planifier le projet correctement. Bref si on adopte une approche par micro-versions, ces deadlines ne poseront pas un problème.
Par micro-versions j’entends qu’il faudrait livrer fréquemment des versions du projet qui ne contiennent à chaque fois que de petits changements. Comme ça si par exemple on dépend d’un service externe qui abandonne son ancienne API à telle date on peut faire une version qui tourne uniquement autour de ça et rien d’autre.
Bref adoptez le comportement release early, release often. C’est comme ça que vous obtiendrez le plus rapidement du retour sur ce que vous faites, et donc pourrez corriger au fur et à mesure votre projet. Une bonne solution pour le mettre en place est d’adopter le Continuous Delivery ou livraison continue, qui est indiquée dans la démarche devops.
Ne tentez pas de faire des releases énormes, sinon vous risquez de ne pas pouvoir tenir vos deadlines. En effet celles-ci peuvent être imprévues, vous forçant à terminer en vitesse les autres fonctionnalités du produit en codant à l’arrache… et donc en dégradant l’état du projet à long terme.
En fait il est parfaitement raisonnable de livrer un logiciel en production alors que certaines fonctionnalités sont en plein développement. Le tout est de désactiver celles-ci, et pour ça on passe par la configuration. Il existe ainsi des librairies comme ff4j qui permettent de le faire facilement dans le monde Java.
Bref ça ne signifie absolument pas que les fonctionnalités prévues pour la release doivent être en état de développement, mais juste que vous pouvez livrer de nouvelles fonctionnalités non terminées dès lors que celles-ci ne sont pas visibles pour l’utilisateur. Et c’est là que la configuration entre en jeu, justement pour les masquer. 🙂
Pour mener à bien un projet, tout le monde doit jouer le jeu. D’un côté le client doit être disponible et ne pas hésiter à passer plusieurs jours à échanger avec un ou plusieurs développeurs pour qu’il y ait un accord sur le besoin réel. Ceci doit intervenir avant même de coder. Ensuite la disponibilité client est critique pour avoir un retour sur les développements en cours. A ce sujet, les méthodes agiles bien appliquées peuvent être une solution au problème.
Les développeurs de leur côté doivent être très rigoureux, et conserver celle-ci dans le temps. Ce n’est pas un exercice facile surtout avec le turnover, mais c’est pourtant critique pour éviter que le projet ne finisse par s’effondrer sous son propre poids.
Enfin le management doit jouer le jeu et éviter à tout prix de gérer les équipes par la pression. Il n’y a rien de pire pour le turnover, et donc pour la qualité du code.
Débloque les + belles offres tech en 10 mins
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…