L'open bar à smoothies

Bref, z’avez des nouvelles de zeqL ? Ça fait un moment que je ne le vois plus par ici

Il rode dans les parages mais t’évite on dirait. Je me demande pourquoi.

J’apprends à l’instant que Michel Ocelot (kirikou, Azur et Azmar, Les Contes de la nuit) va sortir un long métrage d’animation se passant à la Belle Époque. Bon, Dilili à Paris ne sortira que fin 2018, mais ça fait toujours plaisir de savoir qu’un nouveau Ocelot va sortir.

Et j’apprends au passage que Princes et Princesse et Les contes de la nuit vont avoir une suite, nommée Ivan Tsarevitch et la princesse changeante dès cette année. Pour ceux qui ne connaissent pas, il s’agit de courtes œuvre d’animation réalisées en ombres chinoises. Et c’est beau.

Mais… Pourquoi ? J’voulais juste un petit bout !

Petite question d’opinion. Supposons que l’on a une base de code absolument dégueu, avec du code inutile depuis 10 ans. Cependant, le tout est géré avec Svn, donc pas de soucis de pas retrouver le code.

Allez-vous supprimer les parties inutiles dans un but de refactoring afin d’améliorer la lecture et les modifications ultérieures ou biennvous soumettre au reste de l’équipe qui prétend que y’a pas besoin de toucher ?

(Ou bien allez-vous démissionner parce que sinon, vous allez les tuer à coup de clavier ?)

Je refactore. Et je montre aux autres comme c’est agréable de maintenir du code bien écrit.

Qui est responsable de la maintenance du code ? Qui est utilisateur du code ?

Si le code fait ce qu’il doit faire, je ne vois pas de problème à enlever des fonctions plus utilisées ou le support de système trop vieux. Pour ajouter ou changer, c’est un autre problème, car il y a des nécessités de documentation, transmission futur, architecture…, mais pour enlever des bouts non utilisés, mais archivés correctement, je ne vois pas le problème.

Je rappelle au passage que le taux de chômage dans le domaine de l’informatique permet de (relativement) facilement changer entreprise.

Mais j’imagine que c’était pour bonne part une question rhétorique, non ?

Toute l’équipe développe et est responsable du code. Mais tous n’ont pas le même niveau. Il y en a une qui a fait des études de réseau et donc n’est pas, à la base, codeuse. Un autre n’a aucun diplôme d’informatique et a tout appris sur le tas. Le dernier est le TechLead, mais aussi un peu manager, du coup je crois que ses priorités ont changé.

Oui, pour la dernière question c’est réthorique. Je compte changer d’ici la fin de l’année, mais pour l’instant j’ai des projets qui font que je n’ai pas le temps de chercher.

Dans ma boite, mon chef paye un coup quand on fait des commit qui vires beaucoup plus de lignes qu’on en ajoute. Si le code est inaccessible, ça ne génère que du bruit quand tu dois chercher quelque chose dans le même coin. Le pire étant quand ce n’est plus utilisé directement mais accessible (ex avec des urls dans une appli web). Là, en plus d’être useless ça augmente la surface d’attaque et de vulnérabilité de l’appli.

Tout code mort doit être supprimé. Une façon un peu moqueuse de le faire comprendre à tes collègues pourrait être de commenter ces parties du code et de commiter ça. Si ça, ça leur prouve pas qu’il vaut mieux supprimer le code en question…

Eh bien, comment dire… Si tu savais la quantité de code commenté mais commité quand même…

Je note vos avis et je vais faire du ménage. Rien à foutre de ce qu’ils diront, ils ont qu’à apprendre à se servir du gestionnaire de code source !

Pas la peine d’aller au conflit directement. Tu peux faire un atelier formation à SVN et montrer comment on peut restaurer le code, notamment avec des outils graphiques . Il faut leur montrer le bénéfice pour eux, pas pour toi.

Je trouve ça juste très … dommage que ce soit le TechLead, celui qui est sensé s’y connaître le mieux, qui autorise ce genre d’horreurs dans le code et que ce soit moi, le junior, qui essaye de faire le plus propre.

Peut-être suis-je encore naïf sur les réalités du développement ?

Je doute que ce genre de situations soit spécifique au métier de développeur en vair.

Profites-en pour passer à git

Ahah, si ça ne tenais qu’à moi, on y serait déjà depuis longtemps. Et en bonne vieille ligne de commande, parce que c’est plus classe.

Ces développeurs là sont vilains avec les écureuils.

Déjà dehors, hein.

Je trouve ça juste très … dommage que ce soit le TechLead, celui qui est sensé s’y connaître le mieux, qui autorise ce genre d’horreurs dans le code et que ce soit moi, le junior, qui essaye de > faire le plus propre.

. Junior, ça n’existe pas, tu es un dev comme un autre. Tu as une bonne idée, tu trouve des arguments et tu le propose.

Tous les projets ont de la dette technique, pour plusieurs raisons, projet fait dans une courte durée, manque d’exp des devs, manque de temps … mais a des niveaux différents.

Un argument sympa et fun, c’est de prendre 15 fichiers différents avec beaucoup de code commentés, et 15 avec aucun code commenté, les premiers qui arrivent à modifier les fichiers ont gagné.

Là, je pense que les tous premiers devs de l’application devaient être des mecs jetés du C ou du SQL dans C#, parce que y’a de ces horreurs. En vrac :

• Des variables toutes préfixées par b, par lbl (pour Label), par i, alors que nous sommes dans un langage typé statiquement.
• Des constantes nommées MA_CONSTANTE voire pire MACONSTANTE, typique des #define du C ou du C++.
• Si si c’est véridique ! Un mec a vraiment écrit une fonction où, à chaque instruction, il incrémentait un entier iLineNumber, entier qui était remonté avec l’exception qui claque.
• Des exceptions les plus génériques possibles, surtout ne précisons pas s’il c’est un argument invalide ou un fichier manquant.
• Des méthodes nommées en français.
• Les membres privés tous préfixés par un underscore, parce que this c’est pour les chiens.
• Des formes de 2500 lignes qui mélangent le code métier avec l’affichage.
• Des paramètres genre date courante écrits en dur dans le code voire pire dans les requêtes SQL, parce que sinon c’est trop facile d’écrire des tests unitaires.
• Bah tiens, pas de test unitaire.
• Le code mort qui reste commenté alors qu’on a SVN.
• Le mec qui s’est cru à écrire du C en 1980 et qui met son nom et la date de création dans un cartouche en tête du fichier.
• Des conventions de nommage inconsistantes (camel case, snake case, pascal case, anglais, français, underscore ou pas).
• Une absence de commentaire parce que commenter c’est perdre du temps.
• Le copier-coller.
• La redondance.

On devrait recenser les pires horreurs tiens.

Un argument sympa et fun, c’est de prendre 15 fichiers différents avec beaucoup de code commentés, et 15 avec aucun code commenté, les premiers qui arrivent à modifier les fichiers ont gagné.

Une façon simple et efficace de prouver son argument.

• Des constantes nommées MA_CONSTANTE voire pire MACONSTANTE, typique des #define du C ou du C++.

C’est pas une convention courante, ça, de nommer une constante en caps lock et en snake case, même en dehors des #define du C ?