Un truc très difficile à faire pour un développeur est d’évaluer son niveau. En effet il est très difficile d’être objectif sur ce sujet, et dans cet article nous allons tenter d’y répondre.
Débloque les + belles offres tech en 10 mins
Premier moyen : entendre ce que les autres développeurs disent sur soi
Un premier moyen, très peu fiable, consiste à entendre ce que les autres développeurs disent sur soi et son code. Il s’agit néanmoins d’un moyen très subjectif. En effet, au royaume des aveugles les borgnes sont les rois, bref si vous êtes reconnu comme bon développeur parmi un groupe de boulets ça ne veut strictement rien dire, et encore moins que vous êtes bon dans l’absolu.
Bref à titre personnel je ne me fierais strictement jamais à ce qu’on dit de moi au sein d’un groupe, cette mesure est à peu près aussi rigoureuse que l’astrologie. Par contre si vous constatez qu’on dit de vous des choses cohérentes sur votre niveau au sein de plusieurs groupes différents de développeur, ça peut être un indice de votre niveau réel. Mais là encore ce n’est qu’une piste.
Les audits
Les audits permettent d’avoir un avis sur votre code. Il en existe deux types :
– Les audits automatisés, réalisés par des outils
– Les audits par expert
Les deux ont leur usage, mais aucun n’est hélas Vérité. Nous voyons pourquoi.
Les outils d’audit automatisé du code
De nombreux outils émergent depuis quelques années, qui permettent d’analyser votre code et d’en déduire des métriques. Parmi les plus connus dans le monde Java on trouve notamment FindBugs et Sonar, renommé depuis SonarQube. Ce dernier contient en fait un agrégat d’outils, dont FindBugs, afin d’établir différentes métriques sur le code et les conserver au cours du temps pour faire un suivi.
Si vous remarquez que votre code obtient de très bons résultats avec ces outils, à savoir très peu de warnings remontés par FindBugs et Sonar, ça signifie au moins que vous êtes quelqu’un de rigoureux. Or la rigueur est une qualité nécessaire (mais pas suffisante) à un bon développeur, bref c’est un bon début ! Un autre point relevé par Sonar est la couverture de code par des tests automatisés. Si celle-ci est située quelque part entre 80% et 100% c’est encore là un très bon signe, pour peu que vos tests contrôlent effectivement des choses et ne se contentent pas d’appeler des System.out.println… Ne riez pas, je suis encore tombé récemment sur ce dernier cas. Parmi les autres points importants on pourra citer la complexité cyclomatique de vos méthodes, qui doit être la plus faible possible, le LCOM4 pour identifier les God Objects, ou encore la documentation.
Les audits par expert
Un ou plusieurs experts peuvent également auditer votre code. Mais là encore ce n’est pas nécessairement fiable et ce pour plusieurs raisons :
– L’expert en question n’en est pas nécessairement un. Ce n’est pas parce que quelqu’un a le qualificatif d’expert qu’il l’est, de même ce n’est pas parce que quelqu’un a un diplôme d’informatique que cette personne est nécessairement compétente dans ce domaine.
– Le phénomène de copinage, ou du moins d’absence d’indépendance, peut hélas des fois intervenir. Par exemple quelqu’un paie un expert pour certifier que son produit est excellent, il sera difficile à ce dernier d’affirmer le contraire…
Néanmoins des avis convergents de différents experts réellement indépendants les uns des autres deviennent là un avis fiable. Un dernier point à ne pas négliger est qu’en général un audit ne portera que sur un point précis, par exemple les performances, tout simplement parce que ça coûte cher aux entreprises.
Les QCM de code
Les recruteurs adooooooooooooooorent les QCM de code. Ces derniers sont en effet très rapides à corriger, et leur traitement peut même être automatique. Le principal intérêt de ceux-ci est que, si limités en temps, ils pourront révéler si vous connaissez bien la technologie sur laquelle porte le test. Des questions plus poussées pourront aussi donner des indices sur votre curiosité ou votre capacité de compréhension de certains éléments de la technologie utilisée. Vous pouvez par exemple en passer quelques-uns sur JobProd.
Cependant il faut relativiser leur importance. A savoir que si vous répondez bien à ces QCM il y a des chances que vous soyez un bon développeur… mais ce n’est pas forcément le cas. En effet un bon développeur saura s’adapter à différentes technos rapidement, même s’il ne les connaît pas a priori. Google est notre ami… Et même si vous répondez bien, cela ne signifie pas que vous êtes rigoureux ni que vous savez résoudre les problèmes posés par des algorithmiques.
Bref les QCM pourront révéler votre curiosité sur une techno, ou votre capacité à réfléchir sur celle-ci si vous en avez les bases, mais ils élimineront aussi bien les boulets que les gens qui sont capables de maîtriser rapidement la techno et d’apprendre par eux-mêmes. En d’autres termes ils manquent de subtilité.
Débloque les + belles offres tech en 10 mins
Les jeux de code (coding games)
Les jeux de code vous demandent de résoudre en temps limité certains problèmes. Ce sont d’ailleurs de superbes outils pour faire du coding dojo ou monter en compétence sur certains outils. Parmi les plus connus on trouve notamment Coding Game, qui organise justement des concours réguliers et vous propose également de petits jeux pour vous entraîner. Les soirées Dev4Fun vous permettent aussi de vous mesurer dans la bonne humeur à d’autres codeurs venus de tous horizons, justement toujours autour des coding games du site éponyme. Et pour les plus motivés certains samedis le site organise des sessions de deux heures avec des challenges un peu plus poussés. Les vainqueurs de ces derniers peuvent notamment être contactés par les entreprises pour d’éventuels recrutements.
Comme je suis beau joueur je vous donne la solution Java d’un des programmes, qui devait lire un nombre au format hexa et l’afficher au format décimal :
import java.util.*;
import java.io.*;
import java.math.*;
/**
* Auto-generated code below aims at helping you parse
* the standard input according to the problem statement.
**/
class HexaToDecimal {
public static void main(String args[]) {
Scanner in = new Scanner(System.in);
String input = in.next();
// Le deuxième paramètre permet de spécifier la base dans laquelle on compte
System.out.println(Integer.parseInt(input, 16));
}
}
Si vous constatez que vous parvenez sans trop de difficulté à résoudre ces jeux, c’est encore là un signe que vous êtes potentiellement un bon développeur. En effet, un bon développeur sera amené à résoudre de nombreux problèmes avec des algorithmes.
En bref…
Savoir si on est un bon dév est très difficile à déterminer, d’ailleurs même les meilleurs ne le savent pas, cf. l’article de Paul Graham sur le sujet. Toujours est-il qu’en conjuguant les audits, des jeux de code et des QCM vous pouvez commencer à vous faire une idée. Mais là encore ça dépendra du niveau des tests et audits passés.
A défaut de répondre à cette question qui vous taraude tous les outils évoqués ci-dessus vous permettront d’améliorer votre niveau, ce qui n’est en soi déjà pas si mal, pas vrai ? 😉
Débloque les + belles offres tech en 10 mins
Cet article vous a plu ? Vous aimerez sûrement aussi :
- Les bonnes formations pour développeur
- Ce que votre code peut dire de vous… ou de votre organisation
- Vers quel type de société se tourner quand on est dév ?
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.
