Pourquoi les développeurs codent avec le cul

Tout le monde a déjà utilisé ses fesses pour pondre un bout d’algo. Même toi qui lis ce texte avec des yeux hostiles. L’amoureux des process et le premier artisan développeur de France : ton postérieur a été utilisé dans un programme. D’ailleurs beaucoup de logiciels sont en partie, ou totalement, codés avec le cul. Mais pourquoi ? Qu’est-ce qui fait que, tous ensemble, on s’est bien mis tous d’accord pour faire de la merde ? Aller aujourd’hui on enfile son masque à gaz et on essaye de comprendre les codebases les plus pourries du monde !

Cours Forest !

Alors j’ai tout de suite commencé à t’insulter dans cet article en t’accusant d’avoir utilisé tes fesses dans ta codebase et je m’en excuse. Mais c’est vrai! Pourquoi j’en suis si sûr ? Parce que je sais que tu as déjà rencontré une horreur qui s’appelle la deadline. La deadline elle est laide, mais au début ça va parce qu’elle est loin. Du coup ton projet au début c’est les neuf symphonies de Beethoven. Y’a des arcs-en-ciel, ça sent le jasmin et ça se touche en code review. Mais très vite l’horreur de la deadline se rapproche et dans la panique tu commences à ne plus utiliser ton clavier comme d’habitude. Tu la connais cette situation.

Tu commences à commenter les trigger de CI parce que t’as pas le temps pour les tests. Deux jours plus tard, tu sais pas comment c’est possible, t’es encore plus en retard. Là tu transpires fort et tu commences à ne plus respecter le Git Flow. Jean-Jean responsable des Process ne vient plus te voir, il transpire lui aussi à l’autre bout de l’open space ! Et BOOM ça y est tout le monde code avec le cul. Point de non retour à partir de là c’est l’autoroute du caca. Plus le temps passe dans cette situation, plus tu transpires fort, plus ça va se ressentir sur le code. Et c’est là que réside l’explication pour une très grosse partie des programmes, jeux, logiciels codés avec le cul. Des dévs stressé(e)s de façon maximum à qui on demande souvent l’impossible en termes de temps. Ils deviennent évidemment complètement barjos en fin de projet quand la deadline est déjà pour hier.

On se fout bien de la gueule des retards dans le milieu du bâtiment. Mais dans le milieu de la programmation on est quand même bien des champions. Ramener la coupe à la maison ! Au fur et à mesure qu’une entreprise évolue et expérimente des façons de faire ce genre de situation tend à disparaître. Mais pour ceux comme moi qui sont passés en début de carrière dans des jeunes entreprises, notamment des agences de communication -où justement on vend bien les choses- ça doit vous parler. Heureusement les choses s’améliorent, les idées d’itération ont fait leur chemin et de moins en moins de monde deal avec ce genre de situation. Ceci dit ça veut pas dire qu’il faut arrêter d’utiliser ses fesses.

Il faut parfois coder avec le cul

OK alors tu dois te dire que j’ai craqué, mais pas du tout. Coder comme un gros sale c’est parfois ce qu’il faut faire. Retiens tes insultes ho grand gourou du code quality et lis la suite. C’est super important d’être polyvalent en tant que programmeur. Savoir écrire très rapidement un code avec son cul peut être primordial pour la réussite de certains projets.

Ça peut être aussi important que d’écrire du code parfait avec un peu plus de temps. Si tu bloques complet comme un végétarien devant une côte de bœuf, ça prouve un manque d’adaptation. Alors oui, tu vas me dire qu’avec une bonne gestion de projet et un process au top rien de tout ça arrive. Tu seras pas choqué d’apprendre que dans la vraie vie ça se passe pas comme sur ton diagramme de Gantt.

Dans la vraie vie ton patron il veut un PoC. Un proof of concept, une démo, un prototype tu l’appelles comme tu veux. En gros il veut que tu lui pondes un truc très rapidement pour prouver qu’il y’a du potentiel dans l’idée. Avec la bouse que tu lui auras chiée, il pourra alors te débloquer du temps pour ensuite faire le projet en vrai. Propre, avec la dernière techno dedans, comme tu aimes et tout. Et c’est OK de faire ça du coup. Il faut aussi comprendre que les gens ont besoin de preuve de faisabilité avant d’investir un maximum de thunes dans le projet sexy que tu veux faire. Bref du coup tu le lances dans la création du proto.

Tu fais ça vite et ça marche ! T’es content, t’es au top de ta vie. Tu vas pouvoir faire le chemin vers la bonne version qui partira en prod un jour. Mais parfois il se passe quelque chose de grave à la place. Ton patron il te regarde droit dans les yeux. Il tremble pas hein. Il te dit : « C’est super ce que t’as fait, on pousse en prod ! » .

Trahison d’état. Prison ferme. La pire des décisions possibles. Le nombre de projets informatiques que j’ai vu avec ce scénario tourner en prod est hallucinant. Je suis sûr que c’est l’une des plus grandes raisons des codebases de merde. Les prototypes avec du code temporaire propulsé directement en prod sont légion dans les applis que tu utilises tous les jours. Un code de merde doit servir un but précis et être jeté une fois qu’il a rempli son but. C’est du code poubelle, un temps limité, qu’il faut détruire au lance-flamme dès que possible. Même du code normal a un temps limité alors t’imagines bien que celui-là ne devrait pas survivre. Souvent j’entends des responsables dire que c’est juste de la dette technique et qu’on finira par la rattraper. Non mais ça c’est du génie tellement c’est l’excuse parfaite.

Dette technique : le crime parfait

Je sais pas qui a inventé cette excuse, mais champion du monde lui aussi. Oui la gestion de la dette technique est une vraie pratique valide. Ici je parle des gens qui abusent de ce terme. Car une dette technique est censée être payée. C’est pas juste lancer trois buzz word d’un article que tu as lu un jour et oublié qu’il y’a des zombies au fin fond de ta codebase. La pratique du faisons vite on fixera plus tard est la troisième grande raison que ton app t’explose dans les mains quand tu l’utilises. Car le plus tard n’arrive jamais. Et sur ce point les développeur(euse)s eux-mêmes sont aussi coupables que les gestionnaires des projets IT.

Je parlais des protos en prod mais y’a pas que ça. La fameuse « gestion » de la dette technique ouvre la porte à toutes les fenêtres. Et certains malins s’engouffrent là-dedans en saut de l’ange. Ils appellent ça la dette volontaire. Quand une nouvelle fonctionnalité non prévue arrive en fin de projet qu’est-ce qui se passe ? BOOM sortez vos fesses les gars on va coder ça vite! Vous inquiétez pas c’est de la dette volontaire on rattrapera ça vite. Quelques semaines plus tard, quand il faut justement nettoyer, les priorités ont changées ! Et tu te retrouves à ajouter une feature dans du spaghetti code en détestant ta vie. Tu te demandes comment t’en es arrivé là et si le problème aurait pu être géré en amont.

C’est un pattern qui revient très souvent dans un cas de spaghetti code de l’enfer dans ton app : le mauvais design. Et là je reviens sur la comparaison avec le milieu du bâtiment. Si les fondations ne sont pas solides ton bâtiment ça va être de la merde. Il risque de se péter la gueule et comme t’es à l’intérieur tu vas pas kiffer. En informatique c’est pareil. La qualité du design en amont est critique pour le futur code de ton application. Il suffit qu’il y ait une couille dans le potager et le dev va commencer à faire des hacks pour rattraper l’oubli dans les specs. Plus y’en aura et plus il va commencer à mettre de la merde partout pour faire tenir les murs. Et en un rien de temps ton projet est tout moisi et ton développeur démotivé.

C’est aussi la faute aux développeur(euse)s ?

Dans le grand schéma des choses, la plupart des cas avérés de gros caca dans le code sont le fait de gestion de projets désastreuse. Maintenant qu’on a bien insisté là-dessus, je suis obligé de dire que parfois le problème vient aussi des développeur(euse)s. Il y a des développeurs non motivés. Des gens qui sont là pour faire de la thunase et qui en ont rien à foutre du code. Ils en ont rien à foutre de toi et de tes efforts pour faire une code base potable. Ils se foutent encore plus du produit et de sa pérennité. Et t’imagines même pas l’intérêt qu’ils ont pour la boite où ils sont! Des touristes qui ont zéro autonomie sur aucune tâche. Oui un dev non motivé avec aucun investissement contribue à ce que ton programme plante tout le temps. Mais ça représente une faible part des raisons. Une personne comme ça se fait souvent dégager assez vite ou part d’elle-même. La plupart du temps, pas tout le temps. À leur départ ces personnes sont très souvent remplacées par des juniors.

Des juniors qui sont propulsés dans un projet comme des petits singes dans la dernière fusée d’Elon Musk. Allez le jeune t’es payé comme une merde mais tu vas nous faire un boulot de senior. T’inquiète pas, t’es un champion, t’es une vraie rockstar ! Sauf que le junior c’est un junior. Il peut pas être au niveau d’un senior parce que le projet le demande. Une phrase aussi simple est pas comprise par beaucoup de monde. Et du coup ça entre dans les raisons pour laquelle ton site il marche pas. La mauvaise personne a été obligée de bosser sur ton site et tu te retrouves à courir sur un lac gelé en claquette pour tout rattraper. Fatalement ça peut pas marcher. Surtout que, non seulement on te met un junior, mais en plus on le forme pas !

Faire du bon code c’est pas un don naturel donné en mode loterie à la naissance. Faire du bon code ça s’apprend. Il y a des façons de faire, des façons de penser, d’aborder les problèmes. Il y a un milliard de choses à savoir qui -ensemble- vont te permettre de faire un code de qualité. Avec des process de qualité type test coverage, pipeline, code review et pair-programming on s’approche un peu plus de la qualité. Le problème c’est que c’est du luxe. Ça coute cher de faire tout ça, ça prend du temps. Du temps que la plupart des boites n’ont pas. Beaucoup des logiciels que tu utilises sont pourris parce que c’est trop cher la qualité. C’est pas toutes les boites qui ont les moyens de prendre le temps et de mettre des moyens dans ta formation et tes projets.

Épilogue

Si tout ce que tu utilises se pète la gueule à la seconde où tu cliques dessus c’est parce que c’est des gens en panique qui ont bossé dessus. Dans un monde parfait la gestion de projet est prévoyante et les développeur(euse)s sont autant motivé(e)s que formé(e)s. Mais la vie c’est de la merde et à la fin on meurt. En attendant si vous trouvez une boite qui donne vraiment de l’importance à la qualité en dehors des buzz word : restez-y. Vous avez trouvé une licorne et elles sont vraiment rares.