Общее программирование - изменить имя переменной или просто отображаемое имя?

Question

Я работаю над почти завершенным проектом, который обрабатывает информацию о клиентах бизнеса.Среди множества переменных: main_phone cell_phone и office_phone для хранения различных телефонных номеров клиента.Эти переменные используются во всем проекте.

Клиент попросил, чтобы мы отобразили их как Phone 1 Phone 2 и Phone 3 вместо Main Phone Cell Phone и Home Phone.Причины, по которым они хотят этого изменения, являются разумными.

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

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

Ваши мысли?

Спасибо

Answer 1

Честно? Я бы заменил три переменные: main_phone, cell_phone и office_phone на одну: phones типа массива. Так как телефоны неразличимы, зачем хранить три разные переменные? Просто позвоните phones[0], phones[1] и т. Д. Это также лучший дизайн, если принять во внимание реляционные базы данных.

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

В будущем рассмотрим перенос массива phones в Phones объект / структуру. Лучшая инкапсуляция предотвратит такие огромные изменения, которые потребуются при изменении требований (см .: операция по дробовику ).

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

Answer 2

Требование об изменении требует списка телефонных номеров, поэтому я бы фактически преобразовал код в набор телефонных номеров, а не в отдельные поля. Затем, когда клиент снова меняет требования, вы можете очень просто добавить тип телефонного номера ... Вы можете добавить дополнительные телефонные номера, удалить их и т. Д. Код, связанный с телефонными номерами, станет вполне поддерживаемым. (Я бы предложил использовать коллекцию телефонных номеров с атрибутом типа телефона, прежде всего, именно для того, чтобы справиться с этими типами сценариев.)

Кроме того, процесс, который вы описываете, называется рефакторингом, и в зависимости от вашего языка и среды разработки существуют функции и / или плагины, которые помогают в этом процессе. Многие современные IDE имеют базовый рефакторинг, такой как Rename встроенный (Eclipse, Idea, Visual Studio.)

Answer 3

Нет, я бы не стал их менять. Через пару месяцев они скажут что-то вроде того, можете ли вы заказать телефоны, работу, мобильный телефон, дом в переменных Phone1, Phone2, Phone3, если, конечно, вы не собираетесь выставлять их за объем работы, который будет потому что у вас нет коллекции телефонов ...

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

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

Это хороший ученик, держу пари, что "ты" больше не допустит этой ошибки.

Answer 4

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

Answer 5

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

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