Как бороться с изменением названия функции и продукта в исходном коде?

Question

Какая хорошая стратегия для работы с изменением названий продуктов и функций в исходном коде. Вот ситуация, в которой я нахожусь снова и снова (большинство из вас могут рассказать о ней?) ...

1. Название продукта начинается с «DaBomb»
2. Основные функции: "Взрыватель", "Фонарь" и "Флаг".
3. Проходит время, и названия функций меняются на "Boom", "Lighthouse" и "MarkMan"
4. Проходит время, и название продукта меняется на "DaChronic"
5. ...
6. ...
7. Бла, бла, бла ... снова и снова и снова

И теперь у нас есть большая кодовая база с 50 различными именами, разбросанными по дереву каталогов и исходным файлам, большинство из которых устарели. Только ветераны помнят, что означает каждое имя, полную этиологическую историю и т. Д.

Каково решение этого беспорядка?

Пояснение: Я не имею в виду имена, которые видят клиенты, я имею в виду имена каталогов, исходных файлов, классов, переменных и т. Д., Которые разработчики видят, откуда берутся названия меняющихся продуктов и функций. вплетены в.

Answer 1

Учитывая ваше пояснение, что вы «не имеете в виду имена, которые видят клиенты, [вы] имеете в виду имена каталогов, исходных файлов, классов, переменных и т. Д., Которые видят разработчики», да, это может раздражать проблема.

То, как команды, в которых я был, справлялось лучше всего, когда у нас была политика всегда использовать только одно имя для каждой вещи в базе кода. Если имя изменится позже, мы либо останемся со старым именем в коде, либо перенесем все экземпляры старого имени в новое имя. Важно никогда не начинать использовать новое имя в коде, если не перенесены все экземпляры старого имени. Таким образом, вам нужно всего лишь сохранить два имени для чего-то в своей голове: "старое" name ", используется в коде, и имя, которое используют все остальные.

Мы также часто выбирали очень общее / описательное имя для вещей при запуске, если мы знаем, что «фирменное наименование» может измениться.

Answer 2

Решение проблемы - не создавать ее в первую очередь. Как только путь к коду назван, редко есть веская причина для его изменения, а никогда - веская причина использовать новое имя вместе со старым. Когда «Exploder» становится «Boom», у вас есть два варианта: либо продолжать использовать исключительно Exploder и нигде не упоминать Boom, либо поменять все экземпляры Exploder на Boom, а затем продолжить использовать исключительно Boom и никогда больше не упоминать Exploder.

Если вы используете Exploder и Boom в одной кодовой базе, вы делаете это неправильно.

Кроме того, я знаю, что вы пояснили, что вы не говорите о видимых для пользователя именах, но, если вы начинаете работать со своими собственными внутренними именами, которые имеют отношение к тому, что делает код, и полностью независимы от того, что маркетинг хочет Назовите продукт / функцию, тогда это менее вероятно, станет проблемой. Если вы уже называете Exploder внутренне как TNT, то какая разница, если Exploder сменится на Boom?

Answer 3

Я считаю, что переименование для лучшего соглашения об именах - просто еще одна форма рефакторинга. Создать ветку, выполнить переименования, запустить модульные / интеграционные тесты, зафиксировать, объединить, повторить. Все дело в управлении процессом, чтобы сохранить согласованность в проекте.

Answer 4

Просто используйте внутренние имена и игнорируйте изменения в маркетинговых / официальных именах: https://softwareengineering.stackexchange.com/a/208578/55472.

Answer 5

Мы используем внутреннее и внешнее имя. Это может быть так же просто, как определение статической переменной, например

public static final String EXPLODER = "Boom";

И в коде вы всегда будете использовать ссылку на EXPLODER. То же самое для имен путей и тому подобного - жесткое кодирование этих путей в разных местах в любом случае запрещено. Если некоторые ребята начинают копаться во внутренних вещах (например, исходники JS, ini-файлы или что-то еще), кого волнует, обнаружат ли они Exploder?

Answer 6

Как вы справляетесь с локализацией? То же самое; тот же метод.