У нас был долгоживущий продукт уже около 8 лет. Со временем названия понятий и сущностей меняются. Должны ли мы провести работу по переименованию всех таблиц кода, а также таблиц и столбцов базы данных в соответствии с этими новыми именами?
Было ли проведено исследование по этому вопросу или опубликованы некоторые лучшие практики?
Благодарность
Ответы:
Несоответствие между внутренними и внешними именами определенно пахнет. Как указывает Ринзвинд, гомофоны и синонимы пахнут хуже всего.
Реальный вопрос, на который вам нужно ответить: каков компромисс между затратами и выгодами при внесении изменений?
Стоимость отсутствия изменений - более крутая кривая обучения для новых членов команды и повышенная вероятность будущих ошибок. Стоимость изменения - это очевидное время, новая кривая обучения для старожилов проекта и возможность появления новых ошибок.
Если вы ожидаете, что у вас будет относительно большое количество новых членов команды, более вероятно, имеет смысл внести изменения. Если вы не ожидаете какого-либо оборота, текущая команда не запутывается, и команда удовлетворена статус-кво, тогда переименовать вещи не имеет смысла.
Если ожидается, что код будет работать долго, и над ним будут работать новые разработчики, я бы внес изменения.
Для нового разработчика может быть очень запутанным и трудоемким войти в проект и обнаружить, что названия объектов вводят в заблуждение.
Есть также действительный аргумент ... Если это не сломано, не исправляйте это.
Что касается вашего второго вопроса, мне не известны какие-либо опубликованные исследования или лучшие практики. Что касается первого вопроса, я могу предложить некоторые наблюдения из личного опыта с похожим долгоживущим продуктом, где «внутренние» и «внешние» имена иногда различаются.
Имена , которые я бы очень хотел , чтобы исправить являются «омофонами», где одно имя используется как внутри , так и снаружи для различных вещей. Это может быть действительно запутанным, особенно если две вещи не полностью различаются (так что контекст помогает устранить неоднозначность). Одним (абстрактным) примером этого в моем личном опыте является то, что внутренне у вас есть что-то вроде a, Fooкоторое представляет собой совокупность нескольких FooEntity; внешне только последний виден и называется «Foo». Мне потребовалось некоторое время, чтобы понять, что, когда в руководстве пользователя говорилось о нескольких «Foo», это фактически означало «несколько» FooEntity(в одном Foo), если это все еще имеет какой-то смысл для вас.
Во-вторых, я хотел бы исправить любые «синонимы», где какое-то внешнее имя использовалось внутренне. Как в именах переменных, частях имен методов / функций и так далее. Это часто случается, когда разработчики внедряют что-то непосредственно из описания требований клиента и забывают «переводить» имена. Как только это происходит, «неправильное» имя также имеет тенденцию распространяться, потому что другие разработчики копируют / вставляют часть этого кода для использования в качестве шаблона для нового кода, например. Эти синонимы не так запутаны, но они могут раздражать, потому что, если вы ищете в коде какие-либо ссылки на Barвас, возможно, следует иметь в виду, что некоторые части могут ссылаться на него какQuxтак что вам придется искать дважды. (Это может быть хуже в динамически типизированных языках, чем в статических, хотя, поскольку вы должны искать по частям имени переменных / функций / ..., а не по имени их типа.) Что касается обратного случая «синонимов» ”, Где внутреннее имя использовалось внешне: это происходит не так часто, так как сотрудники службы поддержки клиентов и т. Д. Обычно менее осведомлены о внутренних именах, хотя я предполагаю, что это сбивает с толку клиентов, когда это происходит.
Если вы можете избежать или исправить хотя бы две вышеупомянутые ситуации, я не уверен, стоит ли вам заходить так далеко, чтобы все внутренние имена совпадали с внешними. Вероятно, есть веская причина, по которой внутренние имена также не изменились, когда внешнее имя было изначально отличным от внутреннего. По моему личному опыту, эта веская причина - необходимость поддержки более старых версий продукта; может быть трудно объединить исправление ошибки из версии, предшествующей очистке имен, с самой последней версией, если потребуется изменить большой объем кода.
Это довольно распространенная проблема. Ряд проектов, над которыми я работал, используют кодовые имена вместо названий продуктов (которые, возможно, не были решены в тот момент), и используют совершенно другую терминологию в коде, чем то, что отображается пользователю. Я бы, вероятно, оставил все как есть, если только вы не подвергаетесь массивной повторной переработке кода или если есть что-то конкретное, вызывающее проблемы. Нет смысла расстраивать яблочную корзину. Кроме того, кто скажет, что через 5 лет не будет больше изменений? И тогда вам придется пройти через переименование снова. И не забывайте, что это также влияет на любую отдельную документацию кода, которую вы можете иметь (опубликованные API-интерфейсы), что может быть особенно дорогостоящим вопросом, если его распечатать (печатная копия).
Я нахожу, что часто «маркетинговые» сущности не совсем соответствуют внутренним сущностям. В таких случаях имеет смысл представить сущность на другом уровне абстракции, что делает споры по терминологии спорным.
Например, у нас есть модель, которая представляет иерархию. С каждым уровнем в иерархии связан термин, основанный на том, как иерархия используется для моделирования реальных отношений, но внутренне нет различий в поведении от одного уровня иерархии к следующему. Терминология по сути является просто именем для этого уровня в иерархии, поэтому для конкретного узла в дереве имя просто описывает, что это за узел; это не предписывает никакого определенного поведения.
Кроме того, дерево многокорневое, поэтому есть несколько узлов без родителя. Несмотря на то, что концептуально корень существует (он, по сути, представляет собой вселенную), и включение его в модель значительно упростит многие операции, для него нет «маркетингового термина».
Конечно, разные компоненты нашей системы используют разную терминологию. Они были разработаны в разное время разными командами, и мы не можем контролировать их все. На самом деле, в какой-то момент кто-то добавил или удалил уровень в одном компоненте, и поэтому другие уровни смещены относительно друг друга. Те же три уровня представлены буквами A, B и C в одном компоненте, но обозначены как B, C и D в другом.
Сделав шаг в абстракции и просто смоделировав все как «узел» или что-то столь же общее, можно гораздо легче рассуждать о таких моделях. Каждый узел знает, каков его «маркетинговый термин», и тип, который представляет определенный маркетинговый термин, может знать, что этот термин означает в каждом контексте.