Jusqu'où faut-il renommer le code et les données lorsque la nomenclature des utilisateurs finaux change?

Il y a longtemps, nous avons ajouté une fonctionnalité permettant à nos utilisateurs d'accepter une image après son ajout à une file d'attente de flux de travail. Il s'avère que nous avons utilisé le mauvais terme et que les utilisateurs "approuvent" l'image.

Changer d'accepter pour approuver sur notre interface est facile, il suffit de remplacer un mot. Mais nous avons programmé toutes les couches avec le mot "accept", du nom de la classe CSS aux valeurs de la base de données.

• La classe CSS qui fait passer le bouton en vert: ".accepted";
• La méthode de modèle qui vérifie et lie l'attribut de classe sur le noeud DOM: "isAccepted";
• Attribut d'état de JavaScript: Tableau avec "non examiné", "accepté" et "publié";
• Colonne Mysql status: ENUM avec "non examiné", "accepté" et "publié";
• Noms de test;

Il est trivial (surtout lorsque vous avez des tests) de remplacer la plupart des occurrences d’accepter d’approuver. Un peu plus difficile consiste à migrer les données, en particulier car elles doivent être synchronisées avec le déploiement.

Ce cas particulier est simple, mais j’ai été confronté à des cas similaires mais plus complexes au cours de ma carrière. Lorsqu'un fichier est également renommé et qu'un déploiement est effectué sur des dizaines de serveurs, ou lorsque la mise en cache du proxy, memcached et mysql sont impliqués.

Laisser "accepté" sur toutes les autres couches, à l'exception de l'interface, est une mauvaise idée, car les nouveaux programmeurs qui rejoignent l'équipe risquent de ne pas connaître les raisons historiques qui ont conduit à cette décision. a été renommé "mis en file d'attente pour la prochaine réunion sur le statut de la direction", cela n'aurait aucun sens. Et nous pensons que si nous faisons des compromis ici et là, dans quelques itérations, les concepts d'interface utilisateur n'auront aucune incidence sur les internes du système, et je ne souhaite certainement pas travailler sur un système où la moitié de la sortie n'a aucun lien avec ses entrailles.

Alors, est-ce que vous renommez toujours tout quand vous en avez besoin? Si cela vous arrivait et que vous décidiez que le compromis ne valait pas la peine, est-ce que cela vous est arrivé de vous mordre? Les commentaires de code ou la documentation destinée aux développeurs sont-ils suffisants pour éviter ce problème?

Pour moi, il est définitivement préférable de changer tout ce qui concerne l'article en question.

C'est une forme de dégradation du code, et bien qu'un élément non modifié ne soit pas très grave, il donne le ton pour la base de code.

Cela pourrait également créer de la confusion dans le futur et rendre plus difficile la compréhension de la base de code / domaine par les nouveaux développeurs.

D'après le contenu et les balises de la question, je suppose que vous utilisez un langage omniprésent.

D'après mon expérience, UL est formidable mais, comme vous l'avez mentionné, peut entraîner des tâches de maintenance supplémentaires à mesure que la langue évolue. Ceci, en soi, n'est pas une mauvaise chose. Bien sûr, c'est peu pratique, mais c'est aussi prévu.

Ce que j'ai généralement fait (et vu faire) est soit:

• Refactoring immédiat: refactorisez toutes les couches de l'application pour adopter le langage mis à jour; ou
• journalisation de la dette technique: vous pouvez modifier immédiatement le code destiné aux utilisateurs, puis journaliser les tâches de la dette technique pour aligner le reste des couches de l'application sur la langue mise à jour. Cela se traduit généralement par une poignée de tâches ennuyeuses (mais gérables). (Parfait pour 17h!)

Je pense que l’essentiel, c’est que ce que vous décrivez est une dette technique qui devrait être reconnue comme telle.

Certains gestionnaires ont fait valoir que nous ne devrions pas perdre de temps sur des tâches aussi triviales qui n’ajoutent aucune fonctionnalité visible. C'est à ce moment que l' analogie de la dette est vraiment utile. Cela se résume à ceci:

L’équipe a choisi de faire de la DDD avec un langage omniprésent. S'éloigner de cette approche en laissant le code dans un état incohérent ajoute à la confusion et supprime de nombreux avantages procurés par DDD et UL. En termes de gestion, cela ajoute des coûts au projet. Le code devient plus difficile (coûteux) à gérer et plus confus pour les nouveaux développeurs (coûteux).

Vous voudrez peut-être examiner les options de localisation (l10n). Bien que cela puisse sembler moins radical que de passer de l'anglais à l'espagnol, vous utilisez un terme différent pour le même concept. Si cela semble se produire couramment, alors utiliser l10n peut vous permettre de changer rapidement ce qui est affiché dans l'interface utilisateur sans avoir à changer le terme utilisé dans le code.

Cela fait, utilisez simplement les termes de votre code les plus largement compris. Choisissez des noms dans le domaine, car les développeurs le savent et peuvent s’y attendre.

Comme vous le décrivez de manière appropriée, le suivi des modifications de la nomenclature de l'utilisateur final dans chaque partie de la source représente un investissement considérable. Cela en vaut néanmoins la peine, surtout pour un produit de longue durée de vie développé par une infrastructure complète (avec hotline, testeurs, etc.)

Suivre la nomenclature de l'utilisateur final dans la source est un investissement, car il y a tellement de types de composants où il apparaît et il n'y a pas de baguette magique fonctionnant simultanément sur tous ces composants. Développer une telle baguette magique, composant après composant, est un investissement intéressant que vous pouvez diluer tout au long du projet.

J'ai travaillé sur une base de code vieille de 30 ans, où la dérive entre la nomenclature de l'utilisateur final et la nomenclature interne s'est accentuée. Voici quelques inconvénients de cette situation, qui ajoutent tous à la charge de travail de chacun:

1. En l'absence d'une politique adéquate, les nouveaux développements ont tendance à utiliser la nomenclature actuelle de l'utilisateur final. Ainsi, le même concept peut avoir deux noms ou plus dans des composants différents. Etant donné que les composants interagissent ensemble, plusieurs noms synonymes existent simultanément dans certaines parties locales du code.

2. Lorsque le service d'assistance téléphonique / d'assistance est appelé, il écrit une histoire d'utilisateur à l'aide de la nomenclature de l'utilisateur final. Le développeur chargé de résoudre le problème doit traduire la nomenclature de l'utilisateur final pour qu'elle corresponde à la nomenclature source. Bien sûr, il n’est pas archivé et, bien sûr, c’est un gâchis. (Voir 1.)

3. Lorsque le programmeur débogue le code, elle souhaite définir des points d'arrêt dans les fonctions pertinentes. Il est difficile de trouver les fonctions appropriées si la nomenclature de l'utilisateur final et la nomenclature de source ne concordent pas. Il peut même être difficile, voire impossible, d’être certain qu’une liste des fonctions pertinentes est complète. (Voir 1.)

4. En l'absence d'une politique adéquate, le maintien de la source en utilisant une nomenclature obsolète remettra de temps en temps cette nomenclature obsolète devant les utilisateurs. Cela produit une mauvaise impression et entraîne des frais généraux.

J'ai déjà repéré pendant deux jours l'endroit même où des données sont extraites de la base de données et injectées dans un composant de cette base de code. Parce que si moi-même ou quelqu'un de la société dans laquelle je travaillais était capable de trouver un nom menant à cet endroit, j'ai finalement renvoyé mon poste et décidé de trouver une autre solution à ce problème.

Tout en coûtant plus de [1] deux jours de maintenance sans rien générer (aucune connaissance, aucune solution, rien) est probablement aussi grave que possible, les divergences entre la nomenclature utilisateur et la nomemclature source ajoutent un surcoût à de nombreuses tâches de routine un logiciel.

Il est important de noter que les frais généraux augmentent avec la société qui fabrique le logiciel. Dans une grande entreprise, un rapport de problème n'arrivera pas sur votre bureau avant d'avoir été examiné par plusieurs collègues et le correctif pourrait être soumis à des tests.

[1] En raison de la participation de plus d'un développeur.

Je ne renomme pas toujours le code et les données car certains packages sont partagés par les clients. Ils utilisent fondamentalement la même chose mais appellent différemment. Par exemple, dans un CMS, un client appelle son client "Client" et un autre utilise "Client". Nous avons donc remplacé client par client à la surface pour un client, mais CMS restera toujours un système de gestion client.

Un autre exemple est la gestion des utilisateurs avec des termes tels que permissions vs liste de contrôle d'accès, admin vs manager, etc. Cela peut être déroutant pour les nouveaux venus, mais pour les composants principaux tels que ceux-ci, certains développeurs font en sorte que ces composants fonctionnent pour tous les clients et également facile à implémenter par d'autres développeurs (par exemple en créant des étiquettes configurables).

Cela pourrait aider de penser que si vous effectuez ce changement, espérons que vous n'aurez plus besoin de le refaire si le même article est utilisé par un autre client, le transformant essentiellement en un produit.