Blog

12 November 2018

Retour sur Scala.io

Tout ce que vous avez toujours voulus savoir sur la programmation fonctionnelle sans jamais oser le demander 

Xavier Detant a décidé ici de présenter les grands principes de la programmation fonctionnelle à travers une petite séance de live Coding dynamique et plaisante. Il part d’une collection de films en JS et de fonctions simples pour la manipuler (findByTitleadd…) en programmation impérative. Verbeux et gourmand en terme de nombres de lignes, le code permet en l’état de faire passer les tests unitaires. Il décide alors de se lancer dans un refactoring de son code afin d’en simplifier l’expression. Pas à pas, il donne des astuces pour repérer les effets de bord puis utiliser predicates, lambdas et closures. Il définit la curryfication et l’application partielle ainsi que leur intérêt dans notre exemple concret. Il termine sa présentation par la transposition en Haskell - un langage purement fonctionnel- de ses fonctions qu’il exécute dans la console. Les tests passent et le nombre de lignes est réduit de plus de moitié ! Bref, un avant-goût pour les débutants dans l’univers Scala, de ce paradigme si différent de la POO mais néanmoins plus qu’attrayant.

Tu penses quoi de mon Scala ? Parlons code review !

Y a le bon et le mauvais reviewer : cela pourrait être le début de ce talk sur l’importance de la review de code. Mais il y a surtout le bon et le mauvais état d’esprit : oubliez vos idées reçues sur la revue de code et organisez votre quotidien pour y intégrer cette tache primordiale au sein des équipes de développement tel était le message principal apporté par Tristan Sallé, employé chez Teads. Il passe en revue les avantages et les challenges à surmonter dans cet exercice, puis dresse les droits et les devoirs du reviewer et du committer. Si de prime abord la revue de code peut paraître chronophage, bloquante pour le déploiement de correctifs et de nouvelles fonctionnalités, source de conflits entre les développeurs ou impressionnante -surtout pour des profils junior qui ne se sentent pas toujours légitimes quant à la formulation de remarques techniques- c’est un outil efficace pour renforcer la cohésion d’équipe et l’organisation au sein d’un projet. 

Mais pour permettre à chaque membre de l’équipe de relire avec attention et efficacité les pull requests déposées, le speaker nous apporte quelques astuces simples : séparer le code en plusieurs sous-taches, faire attention au nommage de sa pull request et penser à joindre une description claire de la tâche et des changements apportés ainsi que du rôle du morceau de code produit. Et parce qu’en temps que développeur nous sommes amenés à être quotidiennement committer mais aussi reviewer, Tristan Sallé nous encourage à améliorer notre organisation quotidienne en se réservant jusqu’à 1h par jour à un moment fixe de la journée pour la révision de code, à formuler des commentaires clairs et exhaustifs en prenant garde à toujours rester positifs et respectueux et à vérifier avec une attention toute particulière la présence de tests unitaires afin d’optimiser la couverture. L’occasion d’accompagner positivement les membres de l’équipe qui n’ont pas forcément le réflexe test unitaire !

Au delà des bonnes pratiques techniques, des avantages d’uniformisation syntaxique du code et la limitation des éventuels effets de bord inhérents à l’intégration de nouvelles fonctionnalités, la revue de code c’est avant tout l’occasion de renforcer la communication au sein d’une équipe. Il faut pour cela garder l’esprit ouvert, être capable de se remettre en question et favoriser l’échange avec ses collaborateurs à toutes les étapes du développement : durant l’analyse du besoin, pendant la production du code, à l’envoi de la pull request et à la réception d’avis et de commentaires. La formation dans ce domaine est importante au même titre que toutes les autres taches qui composent le métier (on a parfois tendance à considérer que la revue de code peut se limiter à une approche au feeling). Vivement la prochaine pull request !

Back to school : des exercices pour monter en compétence en FP

Si de prime abord on pouvait penser à l’énoncé du titre que cette présentation invitait les débutants à effectuer quelques exercices pour monter en compétence dans le domaine de la programmation fonctionnelle, François Sarradin nous livre ici un retour d’expérience positif sur l’utilisation d’exercices de programmation fonctionnelle au sein d’équipes de développement. Les bénéfices en seraient nombreux : amélioration de la qualité du code, création d’une émulation au sein de l’équipe, regain de motivation et multiplication des discussions et des interactions. Pourquoi faire des exercices lorsqu’on est dans un cadre de projet ? Il arrive que l’équipe soit sous tension, stressée par l’enjeu que leurs développements représente. Sur des projets de longue durée, une lassitude peut s’installer. Les exercices sont un bon moyen de s’entrainer dans un environnement bienveillant. Ils permettent l’acquisition de certains concepts et méthodes de pensée, renforcent l’estime de soi par la réalisation d’objectifs. C’est l’occasion de confronter différentes façons de développement et de provoquer des discussions. François Sarrasin a utilisé pour sa part un format hebdomadaire, avec un exercice donné en début de semaine et une correction collective à la fin. A l’arrivée de nouveaux membres dans l’équipe, la liste des exercices est reprise du début, ce qui permet aux anciens de gagner en autonomie et aux nouveaux de s’intégrer dans la bonne humeur. Une forme de mentoring a alors tendance à se mettre naturellement en place. A tester ?