Un assware, littéralement traductible par “Logiciel de cul”, n’est pas un logiciel porno ou une chaise mais un type de logiciel codé avec le derrière.
Les asswares ont une facheuse tendance à planter aux moindres cliques ou à utiliser de vieilles technologies. Ils peuvent également avoir des prérequis techniques très élevés.
https://www.jesuisundev.com/pourquoi-les-developpeureuses-codent-avec-le-cul/
Tout le monde a déjà utilisé ses fesses pour pondre un bout d’algo. Même toi qui lit ce texte avec des yeux hostiles. L’amoureux des process et le premier artisan développeur de France : ton postérieur à é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 ? Allez aujourd’hui on enfile son masque à gaz et on essaye de comprendre les codebases les plus pourries du monde !
Du coup ton projet au début c’est les neuf symphonies de Beethoven. Y’a des arc-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 terme de temps. Ils deviennent évidement complètement barjos en fin de projet quand la deadline est déjà pour hier.
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étruite au lance flamme dès que possible. Même du code normal à un temps limité alors t’imagines bien que celui là 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.
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é que 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’utilise. Car le plus tard n’arrive jamais. Et sur ce point les développeur(euse)s eux-memes 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és 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.
Dans le grand schéma des choses la plupart des cas avérés de gros caca dans le code est le faite de gestion de projets désastreuse. Maintenant qu’on a bien insisté la 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 zero autonomie sur aucune tache. 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. A leur départ ces personnes sont très souvent remplacées par des juniors.
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. Ca 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 tout les boites qui ont les moyens de prendre le temps et de mettre des moyens dans ta formation et tes projets.