Qu'est-ce qu'une bonne stratégie pour traiter les noms de produit et de fonctionnalité dans le code source. Voici la situation que je me trouve encore et encore (la plupart d'entre vous pouvez concerner?) ...
Et maintenant, nous avons une base de code importante avec 50 noms différents saupoudrés autour de l'arborescence de répertoires et des fichiers source, dont la plupart sont obsolètes. Seuls les anciens combattants se souviennent de ce que chaque nom signifie, l'histoire intimologique complète, etc.
Quelle est la solution à ce désordre?
Clarification: Je ne veux pas dire les noms que les clients voient, je veux dire les noms des répertoires, des fichiers source, des classes, des variables, etc. que les développeurs voient où les noms de produit et de fonctionnalités changent être tissé.
6 Réponses :
Comment gérez-vous la localisation? Même chose; même méthode.
Pour clarifier, je ne veux pas dire les noms que les clients voient, je veux dire les noms des répertoires, des fichiers source, des classes, des variables, etc. que les développeurs voient.
Ah, dans ce cas, vous vivez avec elle. Je pense que c'est à peu près une pratique standard.
Je envisage de renommer de mieux nommer des conventions de nommer une autre forme de refactorisation. Créez une succursale, effectuez les analyses Renames, exécuter des tests d'unité / d'intégration, commit, fusionner, répétez. Il s'agit de tout le contrôle des processus pour garder la cohérence dans le projet.
Compte tenu de votre clarification que vous "ne voulez pas dire que les noms que les clients voient, [vous] signifie les noms des répertoires, des fichiers source, des classes, des variables, etc. que les développeurs voient", oui, cela peut être un ennuyeux problème.
La manière dont les équipes que j'ai utilisées ont été gênées de mieux lorsque nous avons eu une politique d'utilisation toujours d'un seul nom pour chaque chose dans la base de code. Si le nom change plus tard, nous restons avec l'ancien nom du code, ou que nous migrent toutes les instances de l'ancien nom au nouveau nom. La chose importante est de ne jamais commencer à utiliser le nouveau nom du code, à moins que toute instance de l'ancien nom n'ait été migrée. De cette façon, vous ne devez jamais garder 2 noms pour quelque chose dans votre tête: le " ancien nom ", utilisé dans le code et le nom de tous les autres utilise.
Nous avons également choisi souvent un nom très générique / descriptif pour des choses lorsque nous savons que le «nom de marque» est susceptible de changer.
Nous utilisons un nom interne et et externe. Il pourrait être aussi simple qu'une définition de variable statique comme et dans le code, vous utiliserez toujours la référence à l'explosion. Même chose pour les noms de chemin et le codage du mal, ces chemins à différents endroits sont de toute façon une personne. Si certains gars commencent à creuser par des éléments internes (comme des sources JS ou des fichiers INI ou autre), qui se soucie s'ils découvrent Exploder?
La solution au mess est de ne pas la créer en premier lieu. Une fois qu'un chemin de code est nommé, il y a rarement une bonne raison de la modifier et jamais une bonne raison d'utiliser un nouveau nom à côté de l'ancien. Lorsque "EXPLODER" devient "BOOM", vous avez deux choix: Continuez à utiliser l'explodataire exclusivement et ne mentionnez jamais la flèche nulle part ou modifier toutes les instances d'explodeur à la flèche, puis continuez à utiliser de la flèche exclusivement et ne mentionnez jamais l'explodataire.
Si vous utilisez à la fois l'explosion et le même boom dans la même base de code, vous le faites mal.
En outre, je sais que vous avez clarifié que vous ne parlez pas des noms visibles par l'utilisateur, mais si vous commencez à travailler avec vos propres noms internes pertinents pour ce que le code fait et totalement indépendant de ce que le marketing veut Appelez le produit / fonctionnalité, alors cela est beaucoup moins susceptible de devenir un problème. Si vous parlez déjà à l'explodataire en interne en tant que TNT, quelle différence est-ce que cela fait si l'explodeur est changé en flèche?
Il suffit d'utiliser des noms internes et d'ignorer les modifications apportées au marketing / noms officiels: https://softwareEngineering.stackexchange.com/a / 208578/55472 .