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
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 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.
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.
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.
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 :
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.
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 :
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
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.
Elles sont passées où les femmes dans la tech ? Entre le manque de représentation…
Dans cette vidéo, on interview Nicolas Grekas, contributeur clé de Symfony, pour discuter de sa…
Comment trouver son job dans la tech ? Marie a la réponse ! Grâce à…
Adobe, l'empire créatif, et pas des moindres ! Belle ascension de la part de ces…
Est-ce plus simple de créer des morceaux avec les outils de Musique Assistée par Ordinateur…
View Comments
C'est un avis plutôt tranché ! Il y a les bons codeurs et les autres, mais c'est oublier les nuances dans ce raisonnement manichéen, la conclusion aurait eu le mérite d'être plus développé.
On ne peut pas être tout le temps un bon codeur et la plupart du temps, nous n'avons pas le choix, le contexte nous imposant une certaine conduite : code historique, contrainte de temps fortes, lead technique hésitant. On peut aussi oublier des choses ou ne pas les connaitre, sans pour autant être j'm'en-foutiste ; nous sommes des êtres humains, y'a des jours avec et des jours sans, manquons d'expérience ou tout simplement habitué à des méthodes différentes.
Certains y mettent de la mauvaise volonté, mais je pense que la plupart manquent simplement de temps et de conseils bienveillants. Notre code parle bien plus de nos expériences passés et de notre motivation à un moment donné que notre personnalité ou notre manière de penser.
Dans le cadre d'un recrutement avec un test technique, c'est un peu différent. Le cadre est controlé, il est plus aisé d'y voir le schéma de pensée utiliser pour résoudre un problème précis dans un contexte fixe. Mais pour cela, il faut laisser au candidat l'occasion d'expliquer sa démarche. Il n'est pas impossible que celui-ci ait simplement eu de la chance et appliquer une solution toute-faite sans pour autant en comprendre la logique.
En bref, il n'est pas si facile de cerner un bon développeur, tout autant qu'un mauvais (les recruteurs n'auraient plus grand chose à faire si c'était le cas ;) )
Où est la satisfaction du client ?
Un outil bien codé mais qui ne répond pas aux besoins du client, est ce un bon développement ?
Exact, d'où l'importance d'un feedback permanent. Cela dit souvent un code crade équivaut à une appli bugguée qui ne satisfait pas le client, et ce quelque soit sa richesse fonctionnelle.
D'accord avec vous Gogul. Je voulais juste réagir à l'article de Julien qui semble évaluer un développeur seulement sur la qualité de son code.
Je suis l'auteur de l'article. ;-)