Bon, c’est un thread un peu pro et sans doute obscur, mais bon. 😆

Aujourd’hui, ma dev junior est arrivée avec un problème : elle créait puis utilisait des méthodes qui devaient retourner un texte localisé et qui donc prenaient une locale.

Les entités du domaine ont pour ces champs à traduire des dictionnaires avec la locale comme clef. Les clefs de ce tableau sont des symboles ; pour ceux qui ne connaissent pas le Ruby, très grossièrement, il y a deux types de String ; le Symbole, c’est l’autre.

« Oui mais la requête que je reçois me donne une String et pas un Symbol » me dit-elle. « Je ne sais pas si je dois transformer la locale en symbole avant d’appeler la fonction, ou si je dois modifier les fonctions pour à chaque fois y transformer la locale au cas où ». Mais elle préférait changer les méthodes des entités, parce qu’il y en a moins que d’occasions dans le code de les appeler, et donc ça fait moins de changements et de répétition de transtypage.

Je pense que « DRY » a été trop répété aux gens. Bien trop. Je suis probablement vieux, et ça ne devrait pas autant me gêner, mais changer la signature d’une fonction pour faire du transtypage ensuite juste « parce que c’est plus simple et je le fais à moins d’endroits » m’a donné envie de pleurer. Si on n’était pas en Ruby et que le typage était statique, la question ne se poserait pas sous cette forme. Mais bref.

« Mais Lomig, ça serait quoi ta solution ? » Eh bien ton problème, c’est que tu utilises des primitives. Ton problème c’est que « une locale », c’est peut-être un concept. Peut-être qu’une classe Localisation, qui gérerait ta locale par défaut plutôt que ce soit parsemé dans le code, qui sache traduire un champ quand tu lui donnes un dictionnaire de trad, ça permettrait d’évacuer ce problème. Peut-être qu’une telle classe qui permette d’évacuer les triples tests de locale dans tes tests unitaires et d’intégration, pour une langue, une autre langue, une langue qui n’existe pas, ça serait bien.

Et là elle me répond « Oui mais après y a plein de classes et je suis perdue et puis ça fait trop de fichiers et de code en plus comparé à juste transtyper la locale dans ma fonction ». Et je suis resté bête. Parce que finalement c’est courant comme réflexion.

Les gens ne savent pas programmer Orienté Objet. Ils font du procédural caché dans des objets. L’idée même d’injecter une dépendance, d’avoir des petits objets qui communiquent, ça les perturbe. Je sais pas où on a foiré dans l’enseignement en école d’ingé comme à la fac.

Je n’ai rien contre le procédural, ou le fonctionnel (je viens du monde de la programmation fonctionnelle), mais je considère qu’on doit utiliser les forces des langages dans lesquels tu développes. Et forcément que les gens détestent l’OO quand ils ne voient que du OO de merde.

Bref, j’ai passé la fin de ma journée à préparer une présentation sur le sujet avant de me rendre compte que j’allais juste faire un mashup d’Oncle Bob, Martin Fowler et Sandi Metz. Vivement le week-end.