Quand un candidat me parle des lambdas en entretien...

Je rencontre régulièrement des développeurs Java experts en entretien mais je reste souvent sur ma faim, notamment lorsqu'on aborde les Lambdas. Dans ce billet, je ne vais pas rechercher d'explication à ce constat. Je vais simplement vous proposer quelques thèmes ou pistes de réponses qui me donneraient envie de recruter un candidat.

Je vais donc me concentrer sur les lambdas sans m'étendre trop longuement sur tous les sujets dont on aurait pu discuter en entretien technique : Base de données, NoSQL*, CQRS*, Design patterns, REST, performances, etc.

Récemment, j'ai fait plusieurs billets d'humeur (notamment ici et ici) et j'ai été surpris de constater de l'intérêt qu'ils ont suscité. Je me propose donc de continuer la discussion, de façon plus détaillée. Je précise qu'il s'agit de mon opinion et qu'elle n'engage que moi. Elle est issu de mon expérience et des retours de mes collègues dans d'autres entreprises. Je noircis volontairement le trait et la caricature. Attention, donc, à ne pas généraliser trop vite.

Contexte

Je travaille comme architecte dans une grande banque, où l'IT occupe une place importante. Plus personnellement, j'ai 40 ans, marié, 2 enfants, et toutes mes dents. Je pratique Java depuis 1996 mais je maîtrise aussi d'autres langages comme Lisp, JS ou PHP*. Je participe à des conférences et j'écris quelques articles. Dans tous les cas, je me considère comme un passionné mais absolument pas comme quelqu'un ayant les réponses à tout.

Mon service est composé d'une cinquantaine de personnes, majoritairement des développeurs. Nous avons une démarche Agile (Scrum), que nous voyons comme un cadre et non comme un objectif. Nos projets sont déployés dans le Cloud. Nous accordons une grande importance à la qualité de nos produits et du code qui les compose. Nous croyons aux TDD*, BDD*, DDD* et Clean code, que nous essayons d'appliquer de notre mieux dans la mesure du raisonnable. Enfin nous voulons être bienveillants.

Nous avons différentes topologies de projet, allant du batch à la SPA* (Single Page Application), en passant par des Web services REST*.

Coté techno, nous sommes Full-stack. On se concentre sur Angular (5-6), JavaScript, Java* (8), Spring Boot, Mongo, PostgreSQL et Maven. Nous ne recevons en entretien que des personnes ayant indiquées maîtriser tout ou partie de cette Stack.

Nous demandons un minimum de 3 ans d'expérience, la tranche plus junior étant occupée par des apprentis. Dernièrement, pour l'anecdote, nous avons rencontré un développeur avec 40 ans d'expérience. C'était enrichissant et impressionnant. Depuis, il a rejoint l'équipe. Sur l'année écoulée, nous avons organisé 4-5 entretiens par semaine mais nous n'avons recruté que deux personnes par mois en moyenne.

Déroulement de l'entretien

Durant l'entretien, je présente rapidement l'équipe et les projets. Nous recrutons des personnes pour rejoindre l'équipe et non pour travailler sur un projet, même s'il faut commencer quelque part. Je décris notre fonctionnement et nos valeurs. Et, bien entendu, je liste nos technos une dernière fois pour être en phase.

Je laisse alors alors le candidat se présenter. Je ne l’interroge qu'en rebondissant sur ce qu'il aura expliqué. Si je sens le candidat trop stressé, j'essai de le mettre à l'aise. Et si nécessaire, il m'arrive de recadrer la discussion en posant des questions orientées vers nos besoins. Dans tous les cas, nous nous interdisons les questions pièges.

Précisons que les candidats sont, dans 95% des cas, des personnes travaillant en SSII/ESN* et accompagnées de leurs commerciaux. C'est aussi à prendre en compte.

Ce dont les candidats me parlent

Comme nous utilisons Java 8 sur tous nos projet, le sujet arrive forcément à un moment ou à un autre. Une question type qu'on a l'habitude de poser pourrait être simplement "Peux-tu me parler de Java 8 ?"... Bien entendu, nous sommes ouverts aux réponses portant sur des versions plus récentes.

Note : Java 8 date de mars 2014. Cette version a donc un peu plus de quatre ans au moment où j'écris (oct 2018). Java 8 était la dernière version LTS (Long Time Support) du langage et a été remplacée il y a seulement quelques jours par Java 11. Java 8 est donc une version majeure et incontournable.

Il y a de nombreuses façons de répondre. On pourrait parler de l'arrivée de G1, le nouveau Garbage Collector qui remplace CMS comme GC par défaut dès Java 9. On pourrait aussi parler des changements et ajouts dans les APIs. Je pense par exemple aux dates (inspirées de Joda Time), aux nouvelles fonctionnalités des Strings, aux IOs, à la programmation concurrente, aux collections qui évoluent encore ou même aux CompletableFuture... Pour en savoir plus, je vous recommande l’excellente présentation* de José Paumard, intitulée "50 nouvelles choses que l'on peut faire avec Java 8".

Sans surprise, la plupart des candidats répondent les Lambdas, les Streams ou encore la Programmation Fonctionnelle* et il serait difficile de les en blâmer. Tout au plus aimerais-je un peu plus d'originalité, mais impossible de faire l'impasse. Dans tous les cas, ça me convient si c'est ce dont veut parler le candidat ; c'est aussi son entretien.

Ce que les candidats me disent à propos des lambdas

Presque tous les candidats abordent la syntaxe des expressions lambdas, sans forcément employer les termes "syntaxe" et "expression", préférant parler de "flèche" ou de "fonction flèche". Certains disent simplement "les lambdas, c'est les flèches" ou encore "les lambdas, c'est la programmation fonctionnelle". Vous comprendrez aisément que, même si la réponse n'est pas complètement fausse, je vais avoir du mal à m'en satisfaire tant cela mériterait quelques développements...

Mais, à quoi ça sert ? Pour de nombreux candidats, il s'agit principalement d'un sucre syntaxique permettant d'écrire du code plus lisible et plus concis. Pour l'aspect "plus concis", je suis globalement d'accord, même si je n'y accorde qu'assez peu d'importance. Pour l'aspect "plus lisible", j'imagine que c'est une question d'habitude. La mise au point des lambdas dans Java a nécessité des années de travail et s'est étalée sur plusieurs versions. C'est donc (très) réducteur de cantonner les Expressions Lambdas à une syntaxe.

En ce qui concerne la programmation fonctionnelle, j'entend régulièrement que ce sont les lambdas. CQFD... On reviendra là-dessus plus bas. L'article dédié sur Wikipedia sera un bon point d'entrée pour en savoir plus.

Les Streams, quant à eux, servent, d'après de (trop) nombreux candidats, à réaliser des opérations sur les collections. Ici, il y a une confusion légitime. Les Streams ne sont absolument pas liés aux collections, mais j'admet que c'est probablement le cas d'usage le plus courant. Quels types d'opérations les streams permettent-ils ? Ça sert à filtrer et à transformer me dit-on... À ce stade, il serait logique d’enchaîner sur le pattern "Filter-Map-Reduce", si on veut aller plus loin, mais c'est un pas rarement franchi.

À titre illustratif, voici à quoi ça ressemble en Java. La première instruction (ligne) définie une liste de prénoms. La deuxième instruction crée un Stream à partir de la liste, puis filtre les prénoms commençant par un "F", puis prend la longueur (length) de chaque prénom avant d'en faire la somme (sum). Enfin, la dernière instruction permet d'afficher le résultat, ici 29.

final List<String> prenoms = Arrays.asList(
    "Anne", "Daniel", "Franck", "Elodie", "Martin", "Thierry");

final int total = prenoms.stream() // Création du stream
    .filter(prenom -> !prenom.startsWith("F")) // Ignore les prénoms commençant par F
    .mapToInt(prenom -> prenom.length()) // Transformation en longueur
    .sum(); // somme

System.out.println(total); // total = 29 

Quand je sens que le candidat est un juste un poil timide malgré un potentiel évident, j'aborde le sujet des performances. Ah oui, pour sûr, les streams c'est plus performant et c'est mieux, m'affirme-t-on. Mais plus perforant et mieux que quoi ?

Enfin, et c'est un sujet facile, j'aborde les variables finales et effectivement finales. Presque tous les candidats savent que les variables d'une lambda sont finales. Les implications sur le reste du code ou encore la finalité (sans jeu de mot) sont plus vagues.

À ce jour, la réponse qui m'a le plus impressionnée, et scotchée, venait d'une candidate junior que je n'attendais pas. La Programmation Fonctionnelle, m'a-t-elle dit sans préliminaire, c'est éviter les effets de bord. C'était la p****n de meilleur réponse que j'avais entendu depuis longtemps, bien qu'incomplète.

Par contre, je n'apprécie vraiment pas lorsqu'un candidat amalgame les lambdas aux classes anonymes. Même si ce n'était pas complètement faux dans les premières versions de Java 8, pour des raisons de calendrier, il y a longtemps que ce n'est plus le cas.

Ce que j'aurais aimé entendre

Je ne m'attend pas à ce qu'un candidat aborde tous les points qui vont suivre, faute de quoi l'entretien durerait des heures. Il y a toutefois matière à piocher.

Note : Au moment où j'écris ce billet, je découvre que des collègues ont publié un article intitulé "Refactoring de Legacy Code avec Programmation Fonctionnelle en pur JavaScript" que je vous encourage à parcourir.

Historique rapide de la programmation fonctionnelle

Je ne souhaite pas qu'un candidat me fasse un cours d'histoire. Ça aurait même tendance à me gonfler. J'écris toutefois ce petit bloc pour fixer les choses et les remettre dans le contexte, principalement pour les lecteurs non familliés du sujet.

La programmation fonctionnelle s'inspire des calculs lambda, un système formel né dans les années 30s. Le langage Lisp, encore enseigné dans la plupart des écoles, a été créé durant la même décennie. La programmation fonctionnelle n'est donc absolument pas récente et encore moins une invention de Java/JS. Elle est même plus ancienne que la Programmation Orientée Objet (OO).

Pure Vs Impure

Une fonction est dite "pure" si son résultat ne dépend que des paramètres (arguments) qui lui sont passés et qu'elle n'a pas d'effet de bord. Dans le cas contraire, elle est dite "impure".

Dans l'exemple, ci-dessous, la première méthode est "pure" car elle dépend exclusivement des paramètres qui lui sont passés. La seconde méthode fonctionne grâce à un effet de bord. Elle dépend d'une variable extérieure, ici "value", sur laquelle elle effectue une "mutation" ; elle est donc "impure".

// Pure
public int add(final int a, final int b) {
  return a + b;
}


// Impure
private int value;

public int add(final int a) {
  value += a; // value = value + a

  return value;
} 

Attention, il est facile de rendre impure une fonction pure, même par inattention. Dans l'exemple suivant, le simple fait de loguer la valeur du résultat depuis la méthode provoque un effet de bord, petit mais bien présent. Cela résulte ici d'un mauvais design.

// Pure --> Impure
public int add(final int a, final int b) {
  final int result = a + b;
  System.out.println("result: " + result); // Effet de bord

  return result;
}

Transparence référentielle, immutabilité et effets de bords

La transparence référentielle est un principe selon lequel le résultat d'un appel à une méthode sera toujours le même quelque soit le nombre d'appels qu'on fera. Par exemple que vous calculiez Fibonacci au rang 5 une fois ou mille fois, le résultat sera toujours 8. Certains préféreront les termes "reproductivité" ou "idempotence". Ce concept apporte de nombreux avantages comme la possibilité de paralléliser les calculs ou encore la facilité d'employer des techniques de mémoïsation. Cela permet généralement de décomposer un gros problème en plusieurs problèmes plus petits et plus faciles à traiter.

L'immutabilité est une des clés de la programmation fonctionnelle. Elle s'appuie sur des variables qui seront traitées comme des constantes. Attention, on ne parle ici ni de "final" ni de "const", qui ne garantissent que la "non modification" des références, mais bel et bien du contenu. Le DDD encourage notamment cette pratique. Cela conduit généralement à créer plus d'objets mais ceux-ci seront plus faciles à nettoyer, privés de mutabilité et de références qui trainent. Partant d'un objet déjà existant, on préférera créer un nouveau objet à partir du premier que de le modifier. Reconnaissons toutefois que ce n'est pas toujours aisé à faire, en particulier dans un petit projet avec peu de moyens.

Enfin, les effets de bords sont à proscrire, comme on l'a déjà vu. De manière générale, ils arrivent lorsqu'on modifie des éléments extérieurs à la fonction : variables statiques, arguments, appels externes (base de données, web service, file system, etc.), exceptions ou même simple log.

Streams

En français, le mot "stream" pourrait se traduire par "courant", "flot" ou même "flux".

Dans les opérations courantes qu'on effectue sur les streams, on notera filter et map dont on a déjà parlé, mais aussi flatMap, distinct, sorted, peek, limit ou encore skip. En ce qui concerne les opérations terminales, on emploiera forEach, forEachOrdered, toArray, reduce, collect, min, max, count, anyMatch, allMatch, noneMatch, findFirst, findAny, etc. Bien entendu, pour des raisons de performance évidentes, on préférera effectuer les filtres avant les transformations.

Un stream n'est pas nécessairement issu d'une collection. Ses éléments peuvent provenir d'un fichier dont on parcours les lignes au fur et à mesure, d'une réponse d'un Web service, d'une autre partie du programme, etc. Un stream ne possède pas les données (la source) qu'il traite. Certains verront les streams comme des vues, même si c'est un peu rapide. Le stream peut même être généré à la volée, comme dans l'exemple suivant.

final List<Integer> maListe = Stream.iterate(0, i -> i + 1) // Entiers
    .filter(i -> i % 2 == 0) // Pairs
    .limit(10) // Limit aux 10 premiers
    .collect(Collectors.toList());

System.out.println(maListe); // liste = 0, 2, 4, 6, 8, 10, 12, 14, 16, 18

Un stream se termine lorsque l'événement de fin est reçu. Pour une collection, on comprend que cela se produit lorsqu'on arrive en bout de liste. Dans certains cas, on parlera de "stream infini" et je pense que cela ne nécessite pas d'explication supplémentaire.

Lazzy

Reprenons le code déjà proposé plus tôt. Dans l'exemple, les opérations "filter" et "mapToInt" sont "lazzy". On parlera aussi d'opérations "intermédiaires". C'est l'appel terminal à "sum" qui déclenche le travail.

final List<String> prenoms = Arrays.asList(
    "Anne", "Daniel", "Franck", "Elodie", "Martin", "Thierry");

final int total = prenoms.stream() // Création du stream
    .filter(prenom -> !prenom.startsWith("F")) // Ignore les prénoms commençant par F
    .mapToInt(prenom -> prenom.length()) // Transformation en longueur
    .sum(); // somme

System.out.println(total); // total = 29 

On pourrait décomposer le code comme suit. Les filtres et maps sont créés instantanément. Ils renvoient des streams et ne sont pas exécutés immédiatement. C'est seulement lors de l'appel à "sum" que la chaîne (entière) de traitement sera déclenchée, sur chaque élément de la liste, de manière indépendante.

final IntStream partie1 = prenoms.stream()
    .filter(prenom -> !prenom.startsWith("F"))
    .mapToInt(prenom -> prenom.length());

final int total = partie1.sum();

System.out.println(total); // total = 29

Plus concrètement, la première instruction (ligne) ne fait "rien" d'autre que créer le stream intermédiaire "partie1" mais aucun calcul n'est encore effectué à cette étape.

Streams parallèles

Dans certains cas, il sera judicieux de paralléliser le stream, soit à l'aide de la méthode parallelStream, soit à l'aide de parallel si le stream est déjà existant. On pourra alors préciser le nombre de coeurs qui seront utilisés ainsi que le Fork Join employé.

Avec les streams parallèles arrivent toutes les difficultés liées au parallélisme et plus spécifiquement aux threads, notamment lorsqu'on travaille avec des objets dit "thread safe". Il faut en particulier être attentif aux contentions, sous peine de voir les performances s'écrouler, ce qui est à l'opposé de l'effet recherché.

Il faudra également être attentif à la réorganisation des données. Mais de manière générale, si vous travaillez de façon fonctionnelle, vos données doivent être indépendantes et l'ordre ne compte pas. Enfin normalement...

Coût

On s'imagine, à tort, que la mécanique des streams et des lambdas est transparente. Mais, comme n'importe quelle stratégie, elle a un coût (mémoire, performance, lisibilité). Il sera ainsi contreproductifs d'abuser des streams sur les petites collections. Il est difficile de positionner le curseur. Cela dépendra de votre programme particulier. Pour une liste d'une dizaine d'éléments, un cas relativement fréquent, on sera surement bien inspiré de préférer une boucle for classique. Avec plusieurs milliers d'items, on n'hésitera pas. Entre les deux, à vous de voir...

Interface fonctionnelles SAM (Single Abstract Method)

Ce type d'interface, que vous pouvez annoter avec @FunctionalInterface de manière facultative, contient une, et une seule, méthode abstraite. À l'exécution, la JVM pourra déterminer la signature de la méthode que la lambda remplace.

@FunctionalInterface
public interface Fibonacci {

  // Méthode par défaut (autre nouveauté) autorisée...

  default void foo() { 
    ...
  }

  // Seule méthode abstraite...

  int calculer(final int n); 
}

Référence de méthode

J'avoue que je ne sais pas très bien comment l'expliquer avec des mots. Je vous propose donc de partir d'un exemple :

final List<Personne> personnes = ...

final List<String> prenoms = personnes.stream()
    .filter(...)
    .map(personne -> Utils.foo(personne))
    .truc(...)
    .collect(Collectors.toList());

Ici, la transformation statique (map) "foo" prend une variable "personne" et l'utilise comme argument. Il sera plus simple d'utiliser une référence de méthode :

final List<String> prenoms = personnes.stream()
    .filter(...)
    .map(Utils::foo) // Method reference
    .truc(...)
    .collect(Collectors.toList());

Et cela marche bien entendu avec plusieurs variables. Ainsi le code suivant :

Arrays.sort(personnes,
    (Personne a, Personne b) -> a.getPrenom().compareTo(b.getPrenom()));

Peut être simplifié, si on crée "comparerParPrenom" avec le code pris plus haut, en :

Arrays.sort(personnes,
    (Personne a, Personne b) -> Personne.comparerParPrenom(a, b));

Et finalement avec une référence de méthode en :

Arrays.sort(personnes, Personne::comparerParPrenom);

Lambda est un objet

Et oui ! Les lambdas sont des objets Java sans identité propre. C'est un statut un peu particulier. Dites-le en entretien et vous allez marquer des points. Bonus, vous n'aurez toutefois pas besoin d'instancier la lambda à l'aide de l'instruction "new". La JVM en profitera pour vous offrir quelques petites optimisations. Certains benchmarks rapportent un gain de performance de l'ordre de 70%, ce qui est loin d'être négligeable.

Fonctions d'ordre supérieur (HOF High Order Function) : bonus

En JavaScript, les fonctions sont des objets de première classe. Et de manière générale en quand on parle de programmation fonctionnelle, y compris en Java, les fonctions d'ordre supérieur sont des fonctions particulières qui prennent des fonctions en paramètre et/ou renvoient des fonctions. Coté JS, on fera facilement le parallèle avec les Composant d'ordre supérieur (HOC High Order Component) en Angular ou React par exemple.

Conclusion

Comme vous le constatez, il y a beaucoup à dire à propos des lambdas, des streams et de la programmation fonctionnelle. Et encore, on est resté à la surface. On n'a même pas discuté des exceptions, un sujet pourtant fort important et complexe...

Vous n'aurez probablement pas le temps de présenter tout ça durant un entretien, qui comportera forcément des questions sur d'autres sujets, mais vous avez une base de travail.

Je précise que l'objectif de ce billet n'était pas de remplacer un tutoriel de programmation mais s'inscrit dans le contexte d'un entretien. Et j'ai bien conscience d'en faire (souvent) trop.

N'hésitez pas à réagir à ce billet. Vos commentaires et partages seront les bienvenus.

Références, pour aller plus loin

TDD : Test Driven Development

BDD : Behavior Driven Development

DDD (Domain Driven Design) : Commencez par une présentation de Cyrille Martraire, intitulée "DDD, en vrai pour le développeur" et enchainez sur celle de Youen Chéné, intitulée "Architecture hexagonale pour les nuls".

Java : TODO. Jetez un rapide coup d'oeil à la roadmap car elle est intéressante.

Java 8 : Présentation de José Paumard, à Devoxx France, intitulée "50 nouvelles choses que l'on peut faire avec Java 8"

Web services REST : Representational State Transfer

SPA : Single Page Application

SSII/ESN : Société de Services et d'Ingénierie en Informatique / Entreprise de Services du Numérique

PHP : Hypertext Preprocessor. Page dédiée au PHP sur Wikipedia

NoSQL : Not Only SQL

CQRS (Command Query Responsibility Segregation) : Vous pouvez commencer par un article de Martin FOWLER, sobrievement intitulé "CQRS". Complétez le avec la page dédiée au CQRS sur Wikipedia. Enfin, une présentation de Clément Heliou, intitulée "CQRS EventSourcing par la pratique" mais vous en trouverez en nombre sur YouTube.

Programmation fonctionnelle : Commencez par la page dédiée à la programmation fonctionnelle sur Wikipedia. Continuez avec un article de Jordan NOURRY et Fouad JADOUANI, magazine Programmez #222 d'octobre 2018, intitulé "Refactoring de Legacy Code avec Programmation Fonctionnelle en pur JavaScript".

Management en couleurs : profil4.com permet aux entreprises et aux particuliers d’établir et d’analyser des profils de comportement et de communication. L'outil utilise le modèle DISC mais traite également du travail en équipe, des émotions et des motivations. Vous ne m'en voudrez pas pour cette petit pub...