Bonjour, bienvenue pour l’épisode 6, l’épisode philosophie.

Pas de métaphore principale à filer tout le long de l’épisode, parce qu’à chaque fois que je trouvais une formulation, elle semblait aussitôt évidente ou idiote. Mais commençons.

Pour moi, il y a trois “quantités” en informatique, que vous trouverez à la fois dans votre code, vos bases de données, et même votre design et vos aspects métier :

• 0. rien du tout
• 1. une chose
• N. une liste d’éléments

Quand on parle d’une chose, on doit souvent envisager qu’elle soit présente ou absente. Quand on parle d’une liste, elle peut bien sûr être vide ou contenir un seul élément, plusieurs éléments, voire… une infinité.

Questions pièges et découverte du métier

À titre personnel et professionnel, ces nuances m’ont beaucoup aidé à communiquer, et parfois soulever des problèmes ou proposer des solutions. Ce sont des recettes et astuces que j’essaie de ne jamais oublier.

Quand on vous parle d’une seule chose, demandez s’il y en a aucune ou plusieurs.

Imaginez qu’on vous montre un prototype d’interface et qu’on vous dise “et ici on affiche l’adresse du client”. Essayez toujours d’envisager les cas :

• du client qui n’a pas d’adresse connue (ça vous aidera à gérer les cas des NPAI, des incontactables, des données invalides)

• du client qui a plusieurs adresses (ça vous aidera à parler des déménagements, des résidences secondaires… et des données en doublon !)

Le Code et l’unité

Les structures de code de presque tous les langages usuels reflètent cela : les if then else parlent d’un prédicat vrai ou faux, les variables peuvent être vides ou remplies, quand on a un objet dans une variable, on peut aller chercher une propriété ou appeler une méthode sur cet objet, et ça peut marcher ou non.

Dans tous ces cas-là, on parle du cas “UN” où il y a une chose au départ, une méthode à appliquer, et une chose à l’arrivée (fut-elle une liste).

On commence en général à enseigner cette façon de voir dans les tout premiers paragraphes et cours d’algo ou de code : les variables et les structures de contrôle.

Le Code et la Pluralité

Juste après, vient l’une des constructions les plus importantes : les listes, les boucles, etc.

Dans tous ces cas-là, on parle du cas où “N” éléments au départ, mais à l’arrivée, on peut vouloir plein de choses différentes.

Par exemple, sur “N” éléments, voulez-vous : * compter ce nombre d’éléments (et on retrouve les cas intéressants 0, 1 ou N)

• conserver une liste à l’arrivée, transformée d’une certaine manière :
  • les trier (renvoyer la même liste mais rangée différemment)
  • appliquer à tous les éléments le même traitement (appliquer une remise, une taxe)
  • conserver ou retirer uniquement les éléments selon une certaine règle (publiés ou non par exemple)
• avoir un seul résultat, comme
  • voir le premier ou dernier élément (selon un certain critère)
  • agréger : faire un traitement de groupe pour ressortir un résultat (une somme par exemple)
• travailler avec plusieurs listes pour
  • les “additionner”, disons plutôt faire l’union des deux listes
  • ressortir la liste des éléments communs, ou différents de ces listes
  • faire un traitement se basant sur plusieurs listes, par exemple le zip qui prend, comme une fermeture éclair (“zip”) le 1er élément de la liste A et de la liste B pour travailler sur cette paire, puis le 2e de chaque et ainsi de suite… Bien sûr ce dernier cas a autant de variantes que vous voulez, mais à part zip ça commence à devenir très dur d’en parler dans un podcast.

Et les structures de données de base de tant de langages sont alors - le tableau (qui associe un élément à un nombre, sa position dans le tableau) - le dictionnaire, souvent appelé Hash (qui associe un élément “clé” à un élément “valeur”) et parfois des structures plus exotiques, qui vont proposer différentes propriétés.

Dans mon univers de Rubyiste, je recommande toujours de lire intégralement les pages de documentation de Array, Hash et Enumerable, qui aideront à faire de vous meilleur développeur, capable d’utiliser au bon moment le bon outil de base. Mais chaque langage a les siens.

La base de données

Je vais passer rapidement sur la base de donnés, qui a aussi ces constructions, et sur chacune de vos requêtes vous allez vous retrouver à prendre le premier, le dernier, trier dans un sens ou l’autre, compter les nombre d’éléments qui sont dans un certain cas, limiter vos recherches pour prendre seulement les 10 ou 100 premiers, proposer une pagination en BDD ou dans votre interface…

Expérience utilisateur, ergonomie, métier…

Pour recentrer tout cela et ressortir du code, revenons aux questions pièges.

On a vu au début de l’épisode qu’elles peuvent lancer une discussion sur le métier et les cas à gérer, donc dessiner le périmètre de votre travail, des évolutions très ou peu probables (je dis peu probable car je ne vous crois presque jamais quand vous me dites “impossible, ça n’arrivera jamais”) et donc d’une possible architecture logicielle.

Ça marche aussi sur des écrans ou dessins, et pour l’ergonomie : devant une belle image de votre future appli, dessinée avec un cas moyen ou idéal en tête, il est très utile de poser ce genre de questions. Et si on a plus ou moins d’informations ? Et si on doit caler une liste de plusieurs numéros de téléphone au lieu d’un seul ?

Bref, n’hésitez pas à utiliser cette technique à fond, pour l’instant je n’ai perdu que très peu de temps cumulé à envisager des cas tordus, qu’on a très vite identifiés comme “inutiles, à voir plus tard, à voir tout de suite”, ou “critiques”.

Expression

Pour finir, on ne fait que répéter que le code est une activité humaine et la qualité principale d’un ingénieur, la communication. Dijkstra disait que la qualité principale d’un programmeur est une excellente maîtrise de sa langue natale. “À part un léger goût pour les mathématiques,” disait-il, ce dont personnellement je ne suis même pas sûr.

J’ai longtemps été pédant sur la langue française, allant jusqu’à dire qu’un mail avec trop de fautes était éliminatoire. Je n’en suis plus là, même si écrire un français correct est une marque de respect et d’attention, et qu’un mail plein de fautes note un manque de l’un et/ou de l’autre. Prenez vos responsabilités.

Ce que je tiens à dire sur le sujet, en revanche, c’est que je reste attentif aux fautes d’accord. Oui, c’est aussi simple que mettre ou oublier des S au pluriel : car si quand vous écrivez, vous ne savez même pas si vous parlez d’un ou de plusieurs objets, comment voulez-vous programmer correctement ? Et même plus fondamental : comment voulez-vous raisonner correctement ?

Bref : zéro, Un, ou Plusieurs. Ne perdez jamais cela de vue.

Ruby on Rails et les associations

Et voilà, c’est tout pour aujourd’hui ! Autant j’étais peu inspiré par la philosophie la dernière fois, autant j’ai écrit aujourd’hui de quoi faire deux épisodes et j’ai dû couper.

Alors, prochain épisode : les associations dans Rails.