睦勝 Geek
Qui sait quand il faut combattre et quand il faut s'en abstenir sera victorieux.

[METHODOLOGIE] Evaluez rapidement un programmeur


04/03/2015

Il y a un certain temps - en l'an 2000 pour être exact - Joel Spolsky a publié un post intitulé The Joel Test: 12 Steps to Better Code. Beaucoup d'ingénieurs et de développeurs utilisent ce test pour évaluer une entreprise afin de déterminer s'il est bon de travailler pour celle-ci.

En réalité, beaucoup d'entreprises spécialisées dans le développement logiciel emploient le Test de Joël pour s'auto-évaluer et déterminer les points sur lesquels elles doivent encore travailler.

Au cas où vous ne connaîtriez pas ce test, voici les questions qui y figurent :

  1. Utilisez-vous un système de gestion de version ?
  2. Pouvez-vous effectuer une compilation (Software build) en une seule étape ? 
  3. Faites-vous des compilations journalières (Daily build) ?
  4. Avez-vous un logiciel de suivi de problèmes ?
  5. Corrigez-vous les bugs avant d'écrire de nouvelles fonctionnalités ?
  6. Avez-vous un planning de développement à jour ?
  7. Avez-vous des spécifications fonctionnelles ? (« spec »)
  8. Les programmeurs ont-ils un environnement de travail calme (facilités à la concentration, etc.) ?
  9. Utilisez-vous les meilleurs outils que vous puissiez vous payer ? (le matériel, notamment)
  10. Avez-vous des testeurs ?
  11. Les candidats doivent-ils écrire du code pendant leur entretien d'embauche ?
  12. Faites-vous des tests utilisateur complets ? (hallway ou Hall Intercept Testing, c'est-à-dire en testant l'application sur des utilisateurs finaux pris au hasard, et non uniquement sur les membres de l'équipe de développement et de tests)

Et, d'après Joël, voici comment il s'applique :

The neat thing about The Joel Test is that it's easy to get a quick yes or no to each question. You don’t have to figure out lines-of-code-per-day or average-bugs-per-inflection-point. Give your team 1 point for each "yes" answer. The bummer about The Joel Test is that you really shouldn’t use it to make sure that your nuclear power plant software is safe.
 

A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.

Ce qui est bien avec le Test de Joël, c'est qu'il est très facile d'obtenir rapidement un oui ou un non à chacune de ces questions. Vous n'avez pas à déterminer des paliers sur le nombre de lignes de code journalier ou le nombre de bugs par procédure. Accordez 1 point à votre équipe pour chaque oui. Le point faible de ce test est qu'il ne faut juste pas l'employer pour déterminer si votre usine à gaz est sécurisée.

Un score de 12 est parfait, 11 est acceptable mais 10 ou moins et vous avez de gros problèmes. La vérité, c'est que la plupart des éditeurs de logiciels ont un score de 2 ou 3 et ils ont vraiment besoin d'aide, parce que des entreprises comme Microsoft ont 12 en permanence.

 

Mais quid d'un "Test de Joël" pour les programmeurs ?

Le Test de Joël est excellent pour pour les programmeurs qui veulent évaluer rapidement l'environnement de développement d'une entreprise mais qu'en est-il des développeurs eux-mêmes ?

Un certain nombre (et un nombre certain) de personnes - des clients, des prestataires, des partenaires, des managers... - se sont posé la question de savoir s'il y avait un équivalent de ce test pour effectivement évaluer les compétences d'un développeur. La réponse est, pour faire simple, non. Mais cela ne veut pas dire qu'on ne peut pas essayer d'en concevoir un.

Voici ce que je vous propose (les commentaires sont ouverts, n'hésitez pas à vous exprimer.) :

  1. Utilisez-vous efficacement la gestion de versions ?
  2. Pouvez-vous résoudre des problèmes algorithmiques ?
  3. Pouvez-vous programmer dans plus d'un langage ou technologie ?
  4. Faites-vous quelque chose pour améliorer vos connaissances ou compétences tous les jours ?
  5. Nommez-vous les choses de manière pertinente ?
  6. Pouvez-vous communiquer efficacement vos idées ?
  7. Comprenez-vous les bases des motifs de conceptions (design patterns en bon Français) ?
  8. Savez-vous débugguer efficacement ?
  9. Testez-vous votre propre code ?
  10. Partagez-vous vos connaissances ?
  11. Employez-vous les meilleurs outils pour votre job ?
  12. Pouvez-vous compiler une véritable application (complète) ?

Bien évidemment, ce test très simple n'est absolument pas exhaustif dans la liste des compétences qui font un bon développeur mais vous pouvez utiliser ce test pour vous auto-évaluer ou pour avoir une idée générale de l'aptitude d'un candidat lors d'un entretien.

Pour s'auto-évaluer, il convient, bien sûr, d'être honnête et de ne s'accorder un point que si le critère est pleinement rempli et que vous n'avez aucun doute à ce sujet (féliciter une compétence incomplète n'a jamais aidé personne sur le long terme).

Si, en étant honnête, vous obtenez un score en dessous de 8, ne désespérez pas. Cela signifie juste qu'il y a encore du boulot. A mon humble avis, quelqu'un qui atteint un score de 8 ou plus ne devrait pas avoir trop de mal à trouver un emploi comme développeur.

Utilisez-vous efficacement la gestion de versions ?

[Je ne suis pas un grand fan du terme "efficacement" mais je vais l'employer tout au long de cet article parce que savoir faire est une chose mais c'est un tout autre sujet de savoir faire efficacement. Alors bien que le terme "efficacement" soit subjectif, je tenterai de le définir le plus objectivement possible dans chacun des points]

Oui, à peu près n'importe quel développeur est capable de récupérer et d'envoyer des fichiers vers un outil de gestion de versions mais le faire efficacement signifie bien plus que de récupérer du code depuis un dépôt et de le pousser. Les technologies de gestion de versions (CVS, SVN, Git, Mercurial...) ont des spécificités et des utilisations diverses mais quelle que soit celle que vous employez, vous devez savoir l'utiliser pour faire plus qu'un simple check-out/commit.

Pour employer efficacement la gestion de versions, vous devez comprendre les concepts de branches et de fusion. Vous devriez savoir comment revenir en arrière et récupérer les différentes révisions pour pouvoir les comparer. Vous devriez aussi savoir comment résoudre les conflits de fusion et comprendre comment vous pouvez employer les branches ou les espaces de travail pour travailler dans un environnement isolé d'une part ou avec une équipe entière d'autre part.

Etant donné que la gestion de version est capitale pour tout développeur, vous devriez être un expert dans l'utilisation de l'outil de gestion que vous utilisez et comprendre les concepts de base qui s'applique à tous les systèmes de versionning.

Pouvez-vous résoudre des problèmes algorithmiques ?

Je suis épaté par le nombre de programmeurs qui sont incapables de résoudre des problèmes algorithmiques relativement simples - surtout au regard du fait que ces types de problèmes sont très souvent posés lors des entretiens d'embauche.

En tant que développeur, vous devriez être en mesure de résoudre des problèmes basiques comme :

Écrire une fonction qui détermine si deux chaines de caractères sont anagrammes l'une de l'autre.

Et vous devriez être capable de résoudre des problèmes bien plus complexes que ce dernier... sur un tableau blanc.

C'est un peu le gagne-pain du développeur. Même si la plupart des problèmes de la vie réelle ne ressemble pas à ces problèmes algorithmiques qu'on vous pose lors des entretiens d'embauche, ces types de problèmes existent dans la "vraie vie". Dans les faits, la seule façon de les identifier est d'avoir de l'expérience dans leur résolution dans des cas abstraits, génériques.

De nombreuses personnes ont déjà écrit au sujet de la résolution de problèmes, nous ne nous y éterniserons pas pour le moment. Un petit guide sur la résolution de problème se cache dans mes cartons, soyez patients.

Pouvez-vous programmer dans plus d'un langage ou technologie ?

Plus vous travaillez dans l'industrie informatique, plus vous vous rendez compte qu'il est futile d'être sectaire à propos de la technologie et à quel point maîtriser plusieurs langages et technologies est bénéfique.

Les meilleurs développeurs emploient les meilleurs outils pour le job. Ils ont conscience que des problèmes différents sont résolus avec des technologies différentes. Ils n'essaient pas d'employer le seul contenu de leur (dans un premier temps) maigre boîte-à-outils et ils ne sont pas mariés à une techno ou un langage particulier seulement parce que c'est l'étendu actuel de leurs connaissances.

Un développeur vraiment bon essaiera d'acquérir la plus large palette possible d'expériences et de connaissances en apprenant plus d'un langage de programmation et investira du temps à s'instruire dans les arcanes des technologies qu'il ne connait pas encore.

Oui, vous avez raison, la spécialisation est importante mais il est également important d'être familier avec les différents secteurs de la technologie, même si vous n'employez pas ces connaissances au quotidien.

Avec un peu de recul, je constate que ce qui m'a fait le plus progresser en tant que développeur, c'est de sortir de ma zone de confort en faisant du JSP, du Java et en m'intéressant au front-end (JS, CSS, microdata...) bien que l'écrasante majorité de mon expérience soit en PHP.

Après avoir franchi le pas de l'apprentissage d'un autre langage de programmation (bien que ma maîtrise de ces langages reste limitée), je me suis rendu compte que mon champ de vision pour les projets futurs s'était grandement élargi, ne souffrant plus (beaucoup moins en tout cas) des limitations imposées par les œillères de l'ignorance.

Faites-vous quelque chose pour améliorer vos connaissances ou compétences tous les jours ?

Une des questions premières questions qu'on pose à un développeur est comment ils restent à jour sur l'évolution de la technologie.

Je me suis rendu compte que les programmeurs qui ont une forme de programme d'auto-formation (et qui s'y tiennent !) sont ceux qui se révèlent être les plus performants (qualitativement parlant), les plus productifs (rapport qualité/temps) et surtout, ceux avec qui il est le plus agréable de travailler.

En ces temps de chamboulement technologique à grande vitesse,

il est impossible de rester pertinent si on n'a pas un plan, une routine qui permet de se maintenir dans ce train en marche.

Vous devriez faire quelque chose tous les jours - même un tout petit truc - pour augmenter vos capacités ou apprendre quelque chose de nouveau. 15 petites minutes par jour pour lire un blog de programmeur ou de technophile (comme celui-ci ou celui de mon ami Geoffrey Dorne), lire un livre de programmation ou expérimenter de nouvelles techonologies peut faire une grosse différence sur plusieurs années.

Nommez-vous les choses de manière pertinente ?

Une des tâches les plus difficiles, et pourtant importante, de votre métier est de nommer les choses. Un bon développeur écrit du code qui est propre, lisible et facilement compréhensible.

Il est impossible d'écrire du code propre, lisible et compréhensible si vous êtes incapable de nommer vos variables, vos méthodes, vos classes et tout autre élément que vous créez et qui doit être nommé.

Si je jette un œil à votre code et que je vois comment vous avez nommé vos éléments, je suis en mesure de déterminer comment vous pensez et surtout combien vous comprenez l'importance de produire du code simple à comprendre et donc à maintenir.

A ce sujet, je vous invite à lire le livre Tout sur le code : Pour concevoir du logiciel de qualité, dans tous les langages de Steve McConnell ou Clean Code: A Handbook of Agile Software Craftsmanship (en anglais) de Robert C. Martin.

Comprenez-vous les bases des design patterns ?

Vous n'avez pas forcément besoin d'employer des design patterns souvent pour être un bon développeur mais vous vous devez au moins de comprendre les design patterns les plus courants qui sont employés dans les technos et les langages que vous employez au jour le jour.

Les design patterns sont le plus souvent employés dans les langages de programmation orientée objet seront différents que ceux utilisés avec des langages fonctionnels - enfin, disons plutôt qu'ils seront souvent exprimés à l'usage du langage lui-même - mais vous devriez au moins connaître la plupart des design patterns courants.

Si vous n'avez pas encore lu Design patterns. Catalogue des modèles de conception réutilisables de Richard Helm, Ralph Johnson, John Vlissides et Eric Gamma, il n'est pas trop tard. Mais si vous ne en sentez pas le courage, il y a aussi Tête la première Design Patterns de Eric Freeman, Elisabeth Freeman, Kathy Sierra et Bert Bates

Savez-vous débuguer efficacement ?

Alors là, j'avoue, c'est un peu piégeur. Beaucoup de développeurs pensent qu'ils savent débuguer mais en réalité, ce qu'ils savent, c'est se servir d'un débogueur [je hais ce terme francisé]. Comprenez-moi bien, vous devez savoir comment utiliser un debugger mais débuguer est un peu plus complexe que juste exécuter pas à pas un programme et chercher ce qui a pu dérailler.

Un bon codeur sait que débuguer implique de démarrer avec une hypothèse sur la cause du déraillement et de n'utiliser le debugger que pour confirmer ou infirmer cette supposition. Il arrive qu'on perde des heures à essayer de résoudre un problème qu'on aurait pu corriger en deux fois moins de temps si on avait eu la bonne approche.

Etant donné que la plupart des développeurs passent plus de temps à débuguer qu'à produire du nouveau code, un codeur qui est capable de débuguer efficacement est un atout de poids.

Testez-vous votre propre code ?

La qualité et les tests ne sont pas la responsabilité des testeurs et du département Assurance Qualité. La qualité est l'affaire de tout le monde et plus particulièrement celle du développeur.

Un bon développeur assumera la responsabilité de son propre code et s'assurera de le tester avant de le livrer à l'Assurance Qualité ou tout autre personne. Il doit toujours y avoir quelqu'un d'autre pour tester votre code mais vous devez mener vos tests du mieux possible avant de le livrer.

Je crois fermement que

pour être un bon développeur, on doit absolument être un bon testeur.

Bien qu'un peu daté, et uniquement en anglais de surcroît, Testing Computer Software de Cem Kaner, Jack Falk et Hung Q. Nguyen reste une bonne base de lecture.

Partagez-vous vos connaissances ?

Une des caractéristiques d'un excellent développeur, c'est qu'il partage ouvertement et librement ses connaissances. Cela aide, non seulement, son équipe et ses collègues mais je suis intimement convaincu qu'on n'apprend pas réellement les choses avant de les enseigner.

Les meilleurs développeurs sont constamment en train de partager leur savoir avec les autres. Ils n'ont pas peur pour la sécurité de l'emploi ou de dévoiler leurs secrets. Si en plus, on tient compte du fait que 90% du code d'un programme est issu d'un copier-coller-adapter, on se rend vite compte que ce qui nous apparaît comme un secret est en réalité un secret de Polichinelle.

La personne la plus précieuse d'une équipe est celle qui rend tous les autres plus précieux, pas celle qui en sait le plus.

Savoir beaucoup mais ne pas partager ne fait de bien à personne à part vous-même. 

Employez-vous les meilleurs outils pour votre job ?

Un très bon développeur emploiera toujours les meilleurs outils pour être le plus efficace dans leur job. Peu importe les outils que vous préférez. Vous devez juste avoir une panoplie que vous estimez être les meilleurs pour votre métier et vous devez avoir investi du temps à les maîtriser.

Un développeur qui tient vraiment à ce qu'il fait prendra du temps pour trouver les outils qui lui permettront de le faire encore mieux.

Prenons l'exemple de Scott Hanselman, programmeur, professeur et conférencier, faisant partie de l'équipe de la plateforme Web de Microsoft. Il a constitué sa propre boîte-à-outils (pour Windows).

Votre arsenal sera probablement différent mais les outils sont importants. Qu'est-ce qu'on dit toujours ? 

le bon outil pour le bon usage

Vous pouvez passer des heures à serrer un joint en essayant les différentes clés et pinces de votre attirail ou le faire en quelques secondes avec votre clé anglaise.

Pouvez-vous communiquer efficacement vos idées ?

Vous pouvez être le meilleur ingénieur logiciel du monde mais, comme dirait ma belle-sœur,

si vous ne parvenez pas à communiquer efficacement vos idées vous ne servez à rien

La communication est une compétence critique qui influe sur à peu près tout ce qui nous entoure dans le monde du développement. De la rédaction d'emails à la présentation d'une idée d'architecture sur tableau blanc en passant par la communication avec les clients et les décideurs, le développement requiert beaucoup de communication.

Une des façons de développer vos capacités de communication est d'écrire régulièrement. Mes propres compétences de communication ont pris un coup de boost lorsque je me suis mis à tenir ce blog et je sais que de nombreux autres développeurs ont eu des résultats similaires.

Pouvez-vous produire une véritable application (complète) ?

Etre capable de produire du code ne suffit pas.

Il y a des tas de développeurs qui peuvent apporter des modifications de code ou corriger des bugs mais il y a beaucoup moins de développeurs qui peuvent déployer une application complète, from scratch.

Un bon développeur ne pourra peut-être pas développer une énorme application d'entreprise ou une suite logicielle complète tout seul mais il doit pouvoir produire une application simple. Etre capable de produire une application, même la plus petite, montre que le développeur a une véritable compréhension fondamentale de la façon dont un projet fonctionne et comment il doit être construit.

Pendant très longtemps, je n'ai eu aucune idée de la façon de faire. Je pouvais débuguer, modifier le comportement de certaines fonctionnalités d'une application/d'un site et même ajouter des fonctionnalités mais créer de toute pièce une application... ? Ce n'est qu'en me lançant dans des side-projects et en me mesurant aux différents aspects d'un projet que je me suis rendu compte de toutes les facettes qu'un système complexe et de leur articulation les unes avec les autres.

Est-ce que cette liste est complète ? et est-ce que je devrais rabâcher les oreilles de quelqu'un avec ?

Non! et non!

Ce sont juste des guidelines pour vous aider à vous situer et peut-être à vous améliorer en comblant les points qui vous font pour l'instant défaut. Je vais être honnête, je n'atteins pas le score de 12 à ce test mais j'y travaille.

Le développement est un territoire vaste et complexe. Il n'existera jamais de checklist pour déterminer si vous ou un autre est un bon développeur mais je pense qu'un petit guide pour se faire une idée générale de votre situation (ou de celle d'un candidat) est utile. Et je crois que cette liste est une manière rapide d'identifier les points faibles que vous pourriez avoir.

Est-ce que j'ai oublié quelque chose ? n'hésitez pas à partager vos impressions.

A propos de Young Sun TAN :

Young Sun TAN est un geek webophile, technophile, bidouilleur et gourmet.

Sur la toile depuis 1995 avec sa première page web (une biographie de Beaumarchais pour le compte du collège Beaumarchais de Paris), il revendique une identité de "digital native". Après une Terminale S au Lycée Louis-le-Grand à Paris et un Master en Informatique option Ingénierie Informatique - Systèmes d'Information, il a entamé une carrière d'analyste web et est désormais Project Leader pour le Groupe Lagardère. Il compte parmi ses réalisations les sites de Celebrity Cruises, Royal Caribbean ainsi que Gulli, Canal J, Tiji et Europe 1.

Menant un veille constante sur les évolutions du web et du développement, son expertise couvre le PHP-MySQL, le framework jQuery ainsi que le CMS eZPublish et Symfony pour lequel il a une affection toute particulière.

Côté détente, il affectionne tout particulièrement les bonnes tables et les bons plans foodista. Bien que la street food occupe une place de premier choix dans son cœur ventre, il n'est pas allergique à une excursion gastronomique ou bistronomique.

Retrouvez Young Sun TAN sur :