Как далеко мы должны переименовывать код и данные при изменении номенклатуры конечных пользователей?

Давным-давно мы добавили функцию, с помощью которой наши пользователи могли «принять» изображение после его добавления в очередь рабочего процесса. Оказывается, мы использовали неправильный термин, и пользователи фактически «одобряют» изображение.

Изменить Accept для Approve в нашем интерфейсе легко, просто замените одно слово. Но мы запрограммировали все слои со словом «принять», от имени класса CSS до значений базы данных.

• Класс CSS, который превращает кнопку в зеленый цвет: ".accepted";
• Метод модели, который проверяет и связывает атрибут класса на узле DOM: "isAccepted";
• Атрибут статуса JavaScript: Массив с «не просмотрено», «принято» и «опубликовано»;
• Столбец состояния Mysql: ENUM с "не просмотрено", "принято" и "опубликовано";
• Тестовые имена;

Это тривиально (особенно если у вас есть тесты), чтобы заменить большинство случаев принятия для утверждения. Немного сложнее перенести данные, тем более что их необходимо синхронизировать с развертыванием.

Этот конкретный случай прост, но я сталкивался с подобными, но еще более сложными случаями, в моей карьере. Когда файл также переименовывается и развертывание происходит на десятках серверов или когда используется кэширование прокси, memcached и mysql участвуют.

Оставлять «принятым» на любом другом уровне, кроме интерфейса, - плохая идея, так как новые программисты, присоединяющиеся к команде, могут не узнать исторических причин, по которым это решение было принято, и хотя принять -> одобрить - близкие слова с точки зрения смысла, если это было переименовано в «Очередь для очередного управленческого совещания», это, конечно, не имело бы никакого смысла. И кажется, что если мы пойдем на компромисс, то через несколько итераций концепции пользовательского интерфейса не будут иметь отношения к внутренним частям системы, и я, конечно, не хочу работать в системе, где половина вывода не имеет связи с внутренностями.

Итак, вы всегда переименовываете все, когда нужно? Если это случилось с вами, и вы решили, что компромисс не стоит, он вернулся, чтобы укусить вас? Достаточно ли комментариев к коду или документации для разработчиков, чтобы избежать этой проблемы?

Для меня, безусловно, лучше всего изменить все, что касается данного вопроса.

Это форма деградации кода, и хотя 1 элемент, который не был изменен, может не иметь большого значения, он задает тон для базы кода.

Это может также привести к путанице в будущем и усложнить для новых разработчиков понимание кодовой базы / домена.

Из содержания вопроса и тегов я предполагаю, что вы используете вездесущий язык.

По моему опыту, UL великолепен, но, как вы упомянули, может привести к дополнительным задачам по обслуживанию по мере развития языка. Это само по себе неплохо. Конечно, это неудобно, но тоже ожидаемо.

То, что я обычно делал (и видел, сделал):

• Предварительный рефакторинг в один прием: выполните рефакторинг всех уровней приложения, чтобы принять обновленный язык; или же
• регистрация технического долга: вы можете сразу изменить код пользователя, а затем зарегистрировать задачи технического долга, чтобы привести остальные уровни приложений в соответствие с обновленным языком. Обычно это приводит к скучным (но выполнимым) задачам. (Идеально для 5 вечера!)

Я думаю, что ключевым моментом здесь является то, что вы описываете технический долг и должны быть признаны в качестве таковых.

У меня были менеджеры, которые утверждали, что мы не должны тратить время на такие тривиальные задачи, которые не добавляют никакой видимой функциональности. Это когда аналогия долга действительно пригодится. Это сводится к этому:

Команда решила сделать DDD с Ubiquitous Language. Отклонение от этого подхода путем оставления кода в несогласованном состоянии добавляет путаницу и устраняет многие преимущества, которые предоставляют DDD и UL. С точки зрения менеджера, это увеличивает стоимость проекта. Код становится более сложным (дорогим) для управления и более запутанным для новых разработчиков (дорогим).

Возможно, вы захотите взглянуть на параметры локализации (l10n). Хотя это может показаться не таким существенным, как переход с английского на испанский, вы имеете дело с другим термином для той же концепции. Если это обычно происходит, то использование l10n может позволить вам быстро изменить то, что отображается в пользовательском интерфейсе, без необходимости менять термин, используемый в коде.

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

Как вы правильно изобразите это, отслеживание изменений в номенклатуре конечных пользователей в каждой части источника - это довольно серьезное вложение. Однако это определенно стоит того, особенно для долгоживущего продукта, разработанного полной инфраструктурой (с горячей линией, тестерами и т. Д.)

Отслеживание номенклатуры конечных пользователей в источнике является инвестицией, потому что существует так много типов компонентов, где она появляется, и нет волшебной палочки, работающей одновременно над всеми этими компонентами. Может быть, разработка такой волшебной палочки, компонент за компонентом, - это интересная инвестиция, которую вы можете разбавить за время существования проекта.

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

1. В отсутствие адекватной политики новые разработки имеют тенденцию использовать текущую номенклатуру конечных пользователей. Таким образом, одна и та же концепция может иметь два или более имен в разных компонентах. Поскольку компоненты взаимодействуют друг с другом, это приводит к тому, что в некоторых локальных частях кода одновременно появляются несколько синонимичных имен.

2. Когда вызывается горячая линия / служба поддержки, они записывают пользовательскую историю, используя номенклатуру конечного пользователя. Разработчик, отвечающий за исправление проблемы, должен перевести номенклатуру конечного пользователя в соответствие с исходной номенклатурой. Конечно это не заархивировано, и конечно это беспорядок. (См. 1.)

3. Когда программист отлаживает код, он хочет установить точки останова в соответствующих функциях. Трудно найти соответствующие функции, если номенклатура конечного пользователя и номенклатура источника не согласуются. Может быть даже трудно или невозможно быть уверенным, что список соответствующих функций даже завершен. (См. 1.)

4. В отсутствие адекватной политики сохранение источника с использованием устаревшей номенклатуры будет время от времени снова ставить эту устаревшую номенклатуру перед пользователями. Это производит плохое впечатление и вызывает накладные расходы.

Я уже два дня отслеживал то самое место, где некоторые данные считываются из базы данных и внедряются в какой-то компонент этой кодовой базы. Поскольку, ни я, ни кто-либо в компании, в которой я работал, не могли определить имя, ведущее к этому месту, я, в конце концов, уволился и решил найти другое решение этой проблемы.

Хотя затраты на [1] обслуживание в течение более двух дней без каких-либо результатов (без знаний, без исправлений и ничего), вероятно, настолько плохи, насколько это возможно, несоответствия между пользовательской номенклатурой и исходной номенклатурой увеличивают накладные расходы на многие рутинные задачи в обслуживании программное обеспечение

Важно отметить, что накладные расходы растут вместе с компанией, производящей программное обеспечение. В большой организации отчет о проблеме не появится на вашем столе, пока он не будет рассмотрен несколькими коллегами, и исправление может быть подвергнуто тестированию.

[1] Из-за участия более одного разработчика.

Я не всегда переименовываю код и данные, потому что некоторые пакеты распределяются между клиентами. Они в основном используют одно и то же, но называют это по-другому. Например, в CMS один клиент называет своего клиента «клиент», а другой использует «клиент». Таким образом, мы заменили Клиента клиентом на поверхности для одного клиента, но CMS всегда будет системой управления клиентами.

Другой пример - управление пользователями с такими терминами, как разрешения, список управления доступом, администратор, менеджер и т. Д. Это может вводить в заблуждение новичков, но для основных компонентов, подобных этим, обычно есть основные разработчики, которые следят за тем, чтобы эти компоненты работали для всех клиентов и также легко реализуется другими разработчиками (например, путем создания настраиваемых меток).

Это может помочь вам подумать, что если вы сделаете это изменение, то, надеюсь, вам не нужно будет делать это снова, если тот же элемент используется другим клиентом, в основном превращая его в продукт.