Le nommage doit être ennuyeux

A mon arrivée chez un client Rennais, j'ai passé plusieurs semaines à me perdre dans les abréviations qui étaient compliquées à retenir.De nombreuses bases de données et projets legacy avaient des noms comme : CSP, CSM, CG, GIV, etc...Je me souviens avoir tenté de sensibiliser les personnes sur le fait que le nommage devait refléter l'intention des composants (bdd ou service). Le CTO de la boite avait également passé le message. 1 an plus tard, lors d'une réorganisation, les noms d'équipes ont changé. Les personnes aiment que leurs équipes soient funs et donc ont cherché des noms appropriés. Ainsi nous avons eu droit à des choses comme M&Ms ou Nemo...

Comment ne PAS nommer (et architecturer) ses services :

‍

‍

Si je vous dit "ARTEFIS". Pensez-vous tout de suite à l'application d'échanger de fichier de votre banquier ?

Nope.

Et pourtant :

On notera aussi le "zephyr" dans l'URL publique, qui est sans doute un autre nom de code interne 😅

‍

En bon français:

https://fichiers.credit-agricole.fr/

‍

Voici un court exemple et contre exemple de comment bien nommer un service ou une API.

A mon arrivée chez un client Rennais, j'ai passé plusieurs semaines à me perdre dans les abbréviations qui étaient compliquées à retenir.
De nombreuses bases de données et projets legacy avaient des noms comme : CSP, CSM, CG, GIV, etc...
Je me souviens avoir tenté de sensibiliser les personnes sur le fait que le nommage devait refléter l'intention des composants (bdd ou service). Le CTO de la boite avait également passé le message.
1 an plus tard, lors d'une réorganisation, les noms d'équipes ont changé. Les personnes aiment que leurs équipes soient funs et donc ont cherché des noms appropriés. Ainsi nous avons eu droit à des choses comme M&Ms ou Nemo...

/

"There is a creeping tendency to use made up acronyms at SpaceX. Excessive use of made up acronyms is a significant impediment to communication and keeping communication good as we grow is incredibly important. Individually, a few acronyms here and there may not seem so bad, but if a thousand people are making these up, over time the result will be a huge glossary that we have to issue to new employees. No one can actually remember all these acronyms and people don't want to seem dumb in a meeting, so they just sit there in ignorance. This is particularly tough on new employees."

"That needs to stop immediately or I will take drastic action - I have given enough warning over the years. Unless an acronym is approved by me, it should not enter the SpaceX glossary. If there is an existing acronym that cannot reasonably be justified, it should be eliminated, as I have requested in the past.

For example, there should be not "HTS" [horizontal test stand] or "VTS" [vertical test stand] designations for test stands. Those are particularly dumb, as they contain unnecessary words. A "stand" at our test site is obviously a test stand. VTS-3 is four syllables compared with "Tripod", which is two, so the bloody acronym version actually takes longer to say than the name!

The key test for an acronym is to ask whether it helps or hurts communication. An acronym that most engineers outside of SpaceX already know, such as GUI, is fine to use. It is also ok to make up a few acronyms/contractions every now and again, assuming I have approved them, e.g. MVac and M9 instead of Merlin 1C-Vacuum or Merlin 1C-Sea Level, but those need to be kept to a minimum."