Refacto de la table Location

[mmarchois]

Description du problème

La table Location stock de plus en plus d'informations au fur et à mesure que le projet avance. Nous avons pour le moment deux types de localisations :

• Voie nommée
• Route départementale

Solution proposée

L'objectif de cette PR est de séparer la table Location, qui continuera de stocker l'information sur la géométrie. Les informations propres au type de localisation seront stockés dans deux autres tables Road et Lane qui hériteront de Location.

Contexte supplémentaire

https://github.com/MTES-MCT/dialog/pull/693#issuecomment-2037319735

[florimondmanca]

@mmarchois Je pense qu'il faudrait se départir du terme Lane. C'est un traduction calque qui n'est pas correcte car en anglais "lane" signifie "voie" au sens de "voie de circulation" comme dans "une 4-voies". Donc ça va nous poser problème si/quand on s'attaquera à #424.

Je pense aussi qu'on devrait avoir des noms + spécifiques

qui hériteront de Location.

Je ne pense pas qu'il faille hériter ? Il ne vaut pas mieux composer ? Une localisation pourrait avoir soit une NamedStreet soit un NumberedRoad (et imposer un check de type XOR sur les clés étrangères en base pour le garantir)

Location 0,1----1,1 NamedStreet 
    0,1
     |
     +---1,1 NumberedRoad

Donc je proposerais par exemple :

• Location
  • uuid
  • measure_uuid
  • ?named_street_uuid
  • ?numbered_road_uuid
• NamedStreet - "voie" (chaussée ?) nommée
  • uuid
  • location_uuid
  • name
  • cityLabel
  • cityCode
  • ?fromHouseNumber
  • ?toHouseNumber
  • fullGeometry
  • geometry
• NumberedRoad - route numérotée
  • uuid
  • location_uuid
  • administrator
  • number
  • (type) (Pour l'instant on n'a que le type départementale, à l'avenir on pourra en ajouter d'autre -- peut-être que ce champ sera calculé à partir de number vu que ça aura le format Dxxx, Nxx, Axx, Mxx)
  • fromPointNumber
  • fromSide
  • ?fromAbscissa
  • toPointNumber
  • toSide
  • ?toAbscissa
  • (fullGeometry)
  • geometry

[mmarchois]

Je ne pense pas qu'il faille hériter ? Il ne vaut pas mieux composer ? Une localisation pourrait avoir soit une NamedStreet soit un NumberedRoad (et imposer un check de type XOR sur les clés étrangères en base pour le garantir)

Exact, c'est le concept auquel je pensais que j'ai mal nommé du coup. Je pensais bien à faire de la composition.

Je suis OK pour renommer Lane et Road en NamedStreet & NumberedRoad, mais concernant la géométrie calculée, je pense qu'elle aurait toute sa place dans la table Location. À la limite, pour le cas de NumberedRoad, on pourra y laisser la géométrie complète (fullGeometry).

[florimondmanca]

concernant la géométrie calculée, je pense qu'elle aurait toute sa place dans la table Location. À la limite, pour le cas de NumberedRoad, on pourra y laisser la géométrie complète (fullGeometry).

Oui :+1:

[johanricher]

Je me demande si traduire ces termes en Anglais a un sens, cf. l'échange informel qu'on avait eu avec Florimond sur Mattermost à propos de ce thread Twitter.

[florimondmanca]

Oui, perso je ne serais toujours pas choqué d'utiliser les termes métier en français pour les noms de ces entités

• Location
  • uuid
  • measure_uuid
  • ?voie_nommee_uuid
  • ?route_numerotee_uuid
• VoieNommee
  • uuid
  • location_uuid
  • name
  • cityLabel
  • cityCode
  • ?fromHouseNumber
  • ?toHouseNumber
  • fullGeometry
  • geometry
• RouteNumerotee
  • uuid
  • location_uuid
  • administrator
  • number
  • (type) (Pour l'instant on n'a que le type départementale, à l'avenir on pourra en ajouter d'autre -- peut-être que ce champ sera calculé à partir de number vu que ça aura le format Dxxx, Nxx, Axx, Mxx)
  • fromPointNumber
  • fromSide
  • ?fromAbscissa
  • toPointNumber
  • toSide
  • ?toAbscissa
  • (fullGeometry)
  • geometry

[mmarchois]

Je suis assez allergique au mélange anglais - français :smile: (avis très perso) et je préfèrerai conserver la notion de NamedStreet / NumberedRoad. Cette politique (du tout anglais) est utilisée partout ailleurs, ce serait donc bizarre d'avoir une seule partie en "franglais".

Si vous tenez absolument à utiliser les termes métiers (et donc en français), il faudra repasser sur l'ensemble du code applicatif.

[florimondmanca]

Oui jusqu'ici on utilise du tout-anglais mais on ne s'est jamais vraiment posé pour en décider clairement je trouve (par ex, pas d'ADR sur le sujet). La position "traduisons tout en anglais" l'a emporté par défaut jusqu'ici mais Léa et moi avions déjà argumenté sur pourquoi c'était problématique.

En bref ça ne respecte pas le principe de langage ubiquitaire et ça a des inconvénients concrets dans la pratique : il faut trouver des traductions fidèles, que chaque personne dans l'équipe dev comprenne ces traductions, ce qui n'est pas garanti, etc.

On le voit avec le terme road qu'on utilise pour toute sorte de cas dans le BdTopoRoadGeocoder, on ne sait plus si on écrit road au sens "route numérotée" ou juste comme un terme générique désignant un linéaire de voie...

Autre article : Ubiquitous Language in a non-English domain, cas allemand, je suis d'accord avec tout ce que j'y lis

À commencer par :

Our choice of language aims to minimize cognitive load (e.g. translations).

Ça me semble être une bonne stratégie. Si telle approche crée moins de charge mentale que telle autre, ne vaut-il pas mieux la préférer ?

Quand je dis "utiliser les termes métier" je ne dirai pas écrire du code franglais, mais juste ces termes là, et donc je serais aussi d'accord avec ces points :

• Open source code is written completely in English - unless it is aimed at a non-English domain.

• Set professional expressions and framework conventions are preserved. Examples are get...() , set...() , ...Controller , ...Factory , ...FormType or common usages like click(), toggle(), submit()

Le billet va encore plus loin par exemple sur les commentaires, j'aurais cependant très envie de les écrire en français. Pour la pérennité du projet c'est mieux. On ne peut pas supposer une maîtrise de la langue anglaise dans un contexte très technique de la part des devs qui interviendront dans le futur sur DiaLog...

• Write a comment exactly how you would say it out loud in a conversation with a colleague.

Concernant l'existant :

il faudra repasser sur l'ensemble du code applicatif.

Non je pense qu'on n'est pas obligés.

À terme ça serait bien, mais si on décide de changer d'approche, les termes anglais seront à considérer comme de la dette technique et à prioriser comme telle, je pense ? Ça peut être du "filler work" pour les moments de creux.

En contre-arguments je verrais :

• Mélange de termes métier français et traduits en anglais, par exemple location->getRouteNumerotee() - Ça peut créer une charge mentale supplémentaire, même si l'usage du français la réduira de l'autre côté
• On a toujours fait en anglais jusqu'ici -> Oui mais on peut décider de le remettre en cause pour de bonnes raisons
• ... ? Je n'en vois pas d'autres

[johanricher]

À terme ça serait bien, mais si on décide de changer d'approche, les termes anglais seront à considérer comme de la dette technique et à prioriser comme telle, je pense ? Ça peut être du "filler work" pour les moments de creux.

Je suis d'accord. Il faut prendre une décision (et je considère qu'elle ne l'est pas encore, ça peut toujours se discuter) et le cas échéant il faut associer à cette décision une méthode d'application qui pourrait être celle proposée par Florimond, elle ne se serait engageant que pour le flux, les prochains termes à nommer. Et le traitement du stock serait fait selon une priorisation à définir.

Je pense qu'au-delà des arguments liés au DDD, le fait que les termes utilisés correspondent à ceux dans la BD TOPO (par exemple), sans traduction, rend la compréhension de ces correspondances évidente et sans avoir besoin de lire notre doc (même si ça n'empêche pas qu'il faut que celle-ci soit complète !).

[florimondmanca]

Je pense qu'au-delà des arguments liés au DDD, le fait que les termes utilisés correspondent à ceux dans la BD TOPO (par exemple), sans traduction, rend la compréhension de ces correspondances évidente et sans avoir besoin de lire notre doc (même si ça n'empêche pas qu'il faut que celle-ci soit complète !).

Je clarifierais en disant qu'on ne devrait nommer "comme la BD TOPO" que si on "copie-colle" des objets qui viennent de la BD TOPO.

Mais ça n'est pas ce que DiaLog fait, on "assemble" divers objets BD TOPO dans un nouvel objet DiaLog. Par exemple ce qui s'affiche actuellement dans le formulaire "Route départementale" est l'assemblage d'une section de linéaire, de points de repères, avec côté et abscisse... Toutes ces infos sont dispersées dans la BD TOPO et ne sont pas seulement dans route_numerotee_ou_nommee.

De même notre "Voie nommée" assemble un code Insee venu de l'API Adresse, un nom de voie désormais venu de la BD TOPO, des numéros de maison qu'on localise avec l'API Adresse, etc... Ça n'est pas seulement des données de la table BD TOPO voie_nommee.

Dans la pratique je suis assez convaincu par "Voie nommée" parce que c'est ce qu'on utilise comme appellation au quotidien... Pour "Route numérotée" je ne sais pas encore si c'est un terme qu'on a adopté ? On a juste "Route départementale" pour l'instant...

Ah, autre contre-argument possible

• Les termes anglais permettent d'éviter des renommages si les termes français changent "en surface"
  • -> Oui mais on peut alors avoir une dérive des traductions, et devoir quand même changer si le terme a changé parce que le métier a changé (ex : changement de feature)

[johanricher]

On décidé en réunion d'équipe hier de ne pas se lancer dans l'application des principes DDD pour l'instant. Faire cohabiter pendant trop longtemps le code où l'on appliquerait ces principes (avec notamment des termes en français) avec le code produit jusqu'à présent risque de poser des confusions, or on ne sait pas estimer l'effort que demanderait de renommer les termes dans tout le stock du code. Si on se lance dans un tel chantier, il faudrait qu'il soit mené avec une durée relativement réduite pour limiter les problèmes liés à cette cohabitation.

Florimond a créé un ticket pour qu'à minima on documente la situation actuelle et ce choix du statu quo : #754