Il faut toujours mettre une locution latine, ça fait sérieux. Je ne sais plus qui disait ça et G**gl* n'a pas trouvé alors je ne peux pas me la péter en casant une citation trovop lava clavasse.
Pas un jour sans une ligne ? Et bien là j'en suis loin. Il faut dire que j'ai été pas mal occupé ces dernières semaines et pour cause: on m'a mis sur le débuggage d'une application. Ce fût fastidieux labeur; un sacerdoce, une sinécure, un apostolat (je vais encore devoir des royaltees à ma femme pour cette citation).
Dans NTIC, le 'N' c'est pour "nouvelles'. En théorie. Car dans le cas présent, j'ai plutôt creusé dans les strates géologiques de code "hérité" comme on dit en jargon professionnel. Dans les couloirs on parle plus volontiers entre pairs de "vieux bousin". Ce qui a le mérite d'être beaucoup plus parlant, en particulier aux profanes.
Personne n'apprécie réellement de replonger dans des sources poussiéreux. On peut comparer cela à l'exercice législatif. Tout le monde y est allé de sa petite touche personnelle au gré des tendances et des chefs. Il y a beaucoup de choses redondantes voire inutiles. Et il est hors de question de perdre du temps dans un improductif toilettage.
Descartes disait pourtant: Ainsi voit-on que les bâtiments qu'un seul architecte a entrepris et achevés ont coutume d'être plus beaux et mieux ordonnés que ceux que plusieurs ont tâché de raccommoder, en faisant servir de vieilles murailles qui avaient été bâties à d'autres fins.
Quant à Amstrad 100%, ils disaient que le bug est l'unité informatique de l'imperfection humain (et oui, je suis pas si tant vieux que ça hein ...). Cependant, entre le manque, tout humain, de dicernement à anticiper des problèmes improbables et le réchampissage à la truelle de lignes grossières selon des tracés non euclidiens, il y a un monde.
Les bugs sont apparus suite à un récent ajout de fonctionnalités (pas moi, pas taper). Au lieu d'encapsuler ou d'interfacer l'existant, il a été fait pléthore de verrues un peu partout avec force branchements conditionnels précaires.
Quand on m'a dit qu'il y avait des ingénieurs "junior", j'ai pensé à des jeunes diplômés payés au lance-pierres pour financer le CLK de fonction du patron. Il ne semblait pas que la législation encourageât le travail des enfants, surtout pré-puberts. Si les intriguants productivo-médeffiens peuvent désormais s'inviter de la sorte dans l'enceinte d'une administration, il va me falloir réviser urgemment mon échelle de valeurs.
Quoi qu'il en soit me voici avec une mission d'une haute technicité. Très valorisante puisque le langage utilisé n'a plus cours depuis au bas mot une décade révolue. Ça va être tout benef' pour ma carrière ça; me voila promu d'archéologue informatique à éboueur informatique. :-/
Car du déchet il y en a ... jugez plutôt:
- Laisser des pièges.
La compilation des sources du référentiel est certifiée produire la version exécutable en exploitation. Encore faut-il épépiner le code des morceaux qui ne compilent pas.
Que je sache, laisser une fin de commentaire sur un ligne après la mise en exploitation n'est une exigence d'aucune norme qualité en vigueur dont se targue la communication de l'entreprise.
Dans un tout autre style: l'utilisation d'objets déclarés mais jamais initialisés. Le C ne doit pas être assez permissif au goût de certains ... - Diviser pour mieux régner.
Du temps jadis (que les moins de vingt ans ne peuvent pas connaître), il y avait un fichier de milliers de lignes pour une application. Ici je me retrouve avec un fichier de 20 lignes par fonction.
J'ai pas déjà parlé du concept du Tao, moi ? - Utiliser toutes les fonctionalités du langage.
Plutôt que d'inclure un fichier entête dans un fichier source pour déclarer un prototype, pourquoi ne pas recopier juste le prototype dont on a besoin au début du fichier ? Il faut savoir prendre des risques et optimiser le temps de compilation.
Surtout quand le serveur de fichiers n'a pas la même heure que le serveur de compilation. J'adore quand la commandemakerecompile l'intégralité des fichiers parce qu'ils sont dans le futur. Et ce même quand je n'ai rajouté qu'une ligne. - Garder un peu de mystère.
Le code n'est bien entendu pas commenté. On ne sait pas ce que fait telle ou telle fonction. Quant à produire une documentation papier, point de blasphème un jour saint !
Et les personnes qui ont écrit le code ? Dissolus vers d'autres éons. C'est très volatile les prestatairesexternes ... Surtout quand on sait qu'ils sont tenus de mettre leur nom dans les cartouches des fonctions. En cas de problème, cela facilite la recherche des coupables et accélère la prise de sanctions. - Ce qui se conçoit aisément s'énonce clairement.
Pas la peine d'indenter ou de justifier les sources d'une quelconque façon que ce soit. Il est par contre conseillé de mélanger les formats de fichier D*S et *N*X, en laissant de temps en temps des retours de chariot (^M) sur certaines lignes.
Sinon, pour les noms d'index,i,j,k,l, c'est tellement explicite sans commentaire.Bon ... où est-ce que j'ai bien pu ranger ma copie de la pierre de Rosette ? - Honorer la globalisation.
Utiliser des variables globales (c'est tellement plus pratique) et les surcharger de temps à autres avec des variables locales (ça ajoute du challenge). On peut aussi s'amuser à les mettre dans desreturnpour paufiner l'imposture.
Thread safe ? Plait-il ? Qui ose m'apostropher de la sorte ? - Abondance de biens ne nuit pas.
L'utilisation d'énumérations est quasi inexistante. On recopie en dur les différentes valeurs que peut prendre un type de variable. On n'utilise que des entiers et on ne crée de nouveau type sous aucun prétexte; trop dangereux. Pour rajouter une valeur, celui qui suivra passera de longues heures à faire des chercher / remplacer dans la multitude de fichiers sources.
Dans le même esprit, l'utilisation de fonctions est interdite. On préfère là encore recopier des blocs de plusieurs lignes partout où c'est nécessaire. En changeant le nom des variables utilisées, histoire de perdre encore un peu plus de temps. C'est plus lisible; et puis ça évite d'aller chercher la fonction dans un autre fichier. - Être rigolo.
L'utilisation sporadique de macros prête à de douces facécies puisqu'elles sont nommées en minuscules. On peut ainsi les confondre avec les variables. Quels farceurs ces programmeurs !
Un petit extrait bien drôle également:i = i && 1;
Si c'est faux, c'est faux. Si c'est vrai, c'est vrai.
Le compilateur pourrait dire "statement has no effect" s'il était plus intelligent. Comment ? C'est au programmeur de faire montre d'une once d'intelligence ? Mais alors à quoi ça sert l'informatique ?
Personnellement, j'aurais volontiers remplacé par une macro fonctionLAPALISSE( i ) - Battre des records.
Cerise sur le gâteau: l'extait suivant:if( i == 0 )
{
/* ... */
if( i == 0 )
{
/* ... */
}
}
Oui, oui, c'est bien le même test dans lethendu premierif. Il fallait oser fouler au pied de la sorte les plus élémentaires règles de l'algorithmie. Apparemment certains pseudo-développeurs n'ont pas complètement intégré ce qu'est la récursivité. - Sacrifier à l'empirisme.
Pas de tests, c'est une perte de temps.
Après tout les utilisateurs sont là pour ça, non ?
Pas le temps d'améliorer. Ne faire que du correctif, pas de préventif. Je n'ai mis que mon trigramme pour identifier mes modifications, j'ai trop honte. Avec un peu de chance d'ici quelque temps quelqu'un d'autre aura le même.
Bon voila ... j'en ai encore pondu des quintaux.
Mais pour être tout à fait franc, je préfère ces galères techniques au fardeau de la rédaction d'une pré-étude visée par mon (ir)responsable.
Aucun commentaire:
Enregistrer un commentaire