Ce que votre code peut dire de vous… ou de votre organisation

Pendant longtemps on prétendait pouvoir définir la psychologie de quelqu’un à travers la graphologie. Il semblerait que cette pratique soit tombée en désuétude, on demande en effet de moins en moins souvent aux postulants une lettre manuscrite. Et dans le cas où celle-ci est demandée, soyez sûr que c’est pour une expertise graphologique !

Par contre, en regardant du code, on peut analyser assez vite votre manière de penser vos algorithmes, ou à défaut les conditions dans lesquelles ce code a été produit.

Débloque les + belles offres tech en 10 mins

Le truc le plus voyant : les hésitations

Lors du développement d’un logiciel, les développeurs sont fréquemment amenés à faire des hypothèses sur ce qu’on attend d’eux. Ou alors les donneurs d’ordres ne savent franchement pas ce qu’ils veulent. Toujours est-il que ça finit toujours par se voir dans le code surtout si vous ne prenez pas le temps de faire du refactoring à mesure.

Parmi les perles que j’ai vues dans ma carrière il y avait notamment celle-ci :

// ... 200 lignes de code dans la méthode
if (a) {
   if (b) {
      if (c) {
         if (d) {
            // Continuer comme ça sur 20 if imbriqués, avant d'avoir enfin du code qui fait quelque chose
         }
      }
   }
}

// ... 150 autres lignes de code

Il s’agit bien évidemment d’un cas extrême. Mais le souci est que ces hésitations feront tôt ou tard que vous oublierez des cas et donc aurez des comportements inattendus, à moins de tenir le code d’une main de fer… ce qui n’est manifestement pas le cas si vous avez laissé une horreur telle que ci-dessus se produire.

Bref s’il y a de trop nombreuses hésitations qui apparaissent dans le code cela indique deux choses :

• La personne qui l’a écrit s’est lancée dedans sans trop réfléchir. Ca arrive hélas trop souvent.
• La personne qui l’a écrit manque de rigueur au niveau de la maintenance du code. Là encore c’est trop fréquent.

La seule excuse valable pour trouver ceci viendrait d’un management déficient qui se fiche éperdument de connaître l’état réel de ses applications, du moment que les fonctionnalités sont faites pour la veille. Et ça arrive là encore trop souvent.

Le copier-coller : ou comment vous griller comme mauvais codeur

Si vous êtes un accro au copier-coller vous pouvez être sûr d’une chose, c’est que vous serez immédiatement grillé comme mauvais codeur. En fait le seul cas où ça peut être tolérable est si vous devez copier une ou deux fonctions d’une dizaine de lignes de code entre différents projets indépendants, mais sinon cette pratique est à bannir.

Faites plutôt en sorte d’écrire du code réutilisable. Ca simplifiera d’autant les choses le jour où vous devrez corriger un bug dans celui-ci. Et d’autre part ça montrera que vous avez vraiment réfléchi à ce que vous écriviez et pas simplement que vous avez « pissé du code » sans comprendre. Quoique certaines entreprises en sont encore à mesurer les performances des développeurs au nombre de lignes de code…

Bref si vous voyez beaucoup de copier-coller dans votre projet vous pouvez en déduire les choses suivantes :

La personne qui l’a écrit est j’en-foutiste ou démotivée.
La personne qui l’a écrit ne sait tout simplement pas coder.
Là désolé mais contrairement au premier cas il n’y a jamais de raison valable de faire du copier-coller au niveau d’un projet. Don’t repeat yourself, que dit Robert C. Martin.

Les fonctions de deux mille lignes

Petite fonction deviendra grande
Pourvu que dév lui prête vie

On trouve régulièrement des fonctions de plusieurs milliers de ligne. Il s’agit quelque part d’un effet de bord des hésitations sans refactoring, qui devient horrible à maintenir, et ce particulièrement avec des langages non compilés ou d’autres comme le C. Eh oui en terme de débogage Java c’est plutôt pour les fillettes, les vrais y vont avec gdb, en ligne de commande. :-p Enfin bref il m’est déjà arrivé d’avoir à faire face à une fonction C de 3000 lignes avec un segfault qui intervenait au niveau du return. La pile d’appels ne signifiait strictement rien, et après une semaine de recherche on a pu identifier qu’un tableau de caractères n’était pas suffisamment grand.

D’autre part de telles fonctions contiennent bien souvent des duplications de code, souvent nécessaires pour traiter les erreurs. Enfin bref c’est franchement moche, horrible, tout ce que vous voudrez, et vous pouvez sans problème insulter le ou les dévs qui en sont coupables. Et s’ils ne sont pas contents, dites-leur que c’est de ma faute (en plus ça augmentera toujours plus le trafic sur JobProd, c’est donc tout bénef’ :-p )

Une autre possibilité est tout simplement que la personne qui a fait ça a tout simplement voulu verrouiller son poste, en étant sûre qu’elle serait la seule à être en mesure de maintenir cette partie du code. Dans certaines organisations on comprend sans problème la pertinence de ce genre de comportement, hélas…

Bref si vous remarquez que quelqu’un écrit de nombreuses fonctions de plusieurs centaines ou milliers de lignes de code, ça peut signifier les choses suivantes :

– Cette personne ne s’est jamais posé la question de savoir comment coder correctement, bref là encore un certain j’en-foutisme.
– Cette personne veut verrouiller son poste.

Les utilisations franchement incorrectes de librairies

Un grand classique qu’on trouve aussi est l’utilisation incorrecte de librairies ou de frameworks. Les plus couramment utilisés sont bien évidemment les plus frappés, aussi on peut donner deux exemples pour le monde Java :

– En Spring, la personne qui n’a pas compris le concept d’IoC et utilise des getBean partout.
– Le mélange d’Hibernate avec du SQL natif parce que c’est plus « rapide ». Et oui pour info je trouve Hibernate horriblement compliqué à maîtriser aussi j’évite de l’utiliser dès que possible..
Enfin bref il apparaît dans les deux cas un manque clair de curiosité. En effet il n’est intéressant d’utiliser une librairie ou un framework que si vous vous en imprégnez, sinon passez votre chemin ! D’ailleurs de trop nombreux développeurs ne savent qu’assembler des librairies entre elles, mais sont incapables de coder quoi que ce soit par eux-mêmes. Par ailleurs bien peu auront la curiosité d’aller voir ce qui se passe sous le capot de celles-ci, ce qui est fort regrettable évidemment.

Bref une mauvaise utilisation récurrente de librairies signifie plusieurs choses :

• La personne qui a écrit ce code manque patent de curiosité. Si vous voulez utiliser une librairie commencez par prendre un peu de temps pour jouer avec, lire des publications et autres dessus pour vous en imprégner.
• La personne qui a écrit ceci a une volonté de faire « cool », mais au final vous passez pour des nuls. C’est un peu comme toutes ces entreprises soi-disant agiles.
• La personne qui a écrit ceci veut remplir son CV avec de nouveaux mots clef ou a un certain orgueil. A ce niveau c’est de la publicité mensongère. Sans vouloir me mettre en avant je suis d’ailleurs très loin de mettre toutes les technos que j’ai touchées sur mon CV, mais uniquement celle que je pense maîtriser un minimum…

Bref, pour résumer : il ne faut utiliser une librairie ou un framework que s’il/elle répond à un besoin précis du projet et pas juste pour se faire plaisir.

La documentation

On l’a déjà dit, vous devez a minima documenter vos APIs, ne serait-ce que parce que les dévs qui les utiliseront n’ont pas toujours que ça à f… de creuser votre code pour comprendre ce que vous voulez faire.

Un code qui n’est pas documenté signifie soit que la personne qui l’a écrit a un sérieux manque de rigueur, soit qu’elle cherche à verrouiller son poste. Ce dernier point sera d’autant plus visible si on observe par ailleurs une manière très particulière d’organiser le code, par exemple tout mettre dans un seul fichier comptant des dizaines de milliers de lignes.

Bref un code absolument pas documenté peut signifier deux choses :

• Un certain j’en-foutisme du développeur.
• Une volonté de verrouiller son poste en se rendant indispensable. C’est un comportement clairement anti-social mais qui peut hélas se comprendre dans de nombreuses entreprises…

En bref…

En relisant votre code, on pourra clairement savoir si oui ou non vous êtes curieux et savez chercher par vous-même. On peut aussi avoir une idée de votre niveau de rigueur et d’exigence envers vous. Pour le reste c’est plus compliqué.

Débloque les + belles offres tech en 10 mins

•  Les développeurs ne souhaitent pas tous devenir chefs de projet !
• Le recrutement en SSII
• Et vous faites-vous du beau code ?

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.

Son Twitter – Son LinkedIn