У нас довгий живий продукт вже близько 8 років. З часом назви понять і сутностей змінюються. Чи слід поставити роботу над перейменуванням всіх таблиць та стовпців бази та коду, щоб відповідати цим новим іменам?
Чи було опубліковано дослідження з цього питання чи опубліковано найкращі практики?
Спасибі
Відповіді:
Невідповідність внутрішніх та зовнішніх назв безумовно пахне. Як зазначає Рінцвінд, омофони та синоніми пахнуть найгірше.
Справжнє питання, на яке вам потрібно відповісти, таке: яка компенсація витрат / вигод від внесення змін?
Вартість не змінюється - це більш крута крива навчання для нових членів команди та підвищена ймовірність виникнення майбутніх помилок. Вартість змін - це очевидний час, що склався, нова крива навчання старожилів проекту та можливість нових помилок.
Якщо ви очікуєте мати відносно велику кількість нових членів команди, швидше за все, має сенс внести зміни. Якщо ви не очікуєте жодного обороту, нинішня команда не заплутається, а команда задоволена статусом, то перейменувати речі не має сенсу.
Якщо очікується, що код буде тривалий час існувати, і над ним працюватимуть нові розробники, я б вніс зміни.
Це може бути дуже заплутаним і забирає багато часу для нового розробника, щоб увійти в проект і виявити, що назви організацій вводять в оману.
Є також дійсний аргумент ... Якщо він не зламався, не виправляйте його.
Що стосується вашого другого питання, я не знаю жодного опублікованого дослідження чи найкращої практики. Що стосується першого питання, я можу запропонувати деякі спостереження з особистого досвіду щодо подібного довгоживучого продукту, де «внутрішні» та «зовнішні» назви іноді різняться.
Імена, які я дуже хотів би виправити, - це «гомофони», де одне ім’я використовується як внутрішньо, так і зовні для різних речей. Це може бути дуже заплутаним, особливо якщо дві речі не зовсім різні (такий, що контекст допомагає роз'єднуватись). Один (абстрагований) приклад цього в моєму особистому досвіді - це те, коли внутрішньо у вас є щось на кшталт, Fooяке є сукупністю множин FooEntity; зовні видно лише останнє і називається "Foo". Мені потрібно було деякий час, щоб зрозуміти, що коли в керівництві замовника говорили про декілька "Foo", це насправді означало кілька FooEntity(в одному Foo), якщо це все-таки має для вас сенс.
По-друге, я хотів би виправити будь-які «синоніми», де якесь зовнішнє ім’я було використано внутрішньо. Як і у назвах змінних, частинах назв методу / функцій тощо. Це часто трапляється, коли розробники реалізують щось безпосередньо з опису вимог замовника і забувають "перекласти" імена. Як тільки це станеться, «неправильне» ім'я також має тенденцію до поширення, оскільки іншим розробникам трапляється копіювати / вставляти частину цього коду для використання в якості шаблону для нового коду, наприклад. Ці синоніми не так заплутані, але вони можуть дратувати, тому що якщо ви шукаєте код для будь-яких посилань на Barвас, можливо, потрібно мати на увазі, що деякі частини можуть посилатися на нього якQux, тому вам доведеться шукати двічі. (Це може бути гірше в динамічно набраних мовах, ніж статичні, оскільки вам потрібно шукати по частинах імені змінних / функцій / ..., а не по імені їх типу.) Що стосується зворотного випадку "синонімів ", Де внутрішнє ім'я використовується зовні: це, як правило, не так часто, оскільки працівники служби підтримки клієнтів і так далі, як правило, менш обізнані про внутрішні імена, хоча я припускаю, що це заплутає клієнтів, коли це відбувається.
Якщо ви можете уникнути або виправити принаймні дві вищезгадані ситуації, я не впевнений, чи варто вам зайти так, щоб усі внутрішні імена були однаковими із зовнішніми. Напевно, є вагома причина, чому внутрішні імена також не були змінені, коли зовнішнє ім'я в першу чергу було відмінним від внутрішнього. На мій особистий досвід, цією вагомою причиною є необхідність підтримувати старіші версії продукту; може бути важко об'єднати виправлення помилки від версії очищення до імен до останньої версії, якщо багато коду потрібно змінити.
Це досить поширена проблема. Ряд проектів, над якими я працював над використанням кодових назв замість найменувань продуктів (які, можливо, не вирішено в той момент), і використовують диво іншу термінологію в коді, ніж те, що відображається користувачеві. Я, ймовірно, залишу речі такими, як є, якщо тільки ви не зазнаєте масового переназначення коду або якщо у вас виникнуть якісь конкретні проблеми. Немає сенсу засмучувати яблучну кошик. Крім того, хто скаже, що через 5 років не буде більше змін? І тоді вам доведеться знову пройти перейменування. І не забувайте, що це також впливає на будь-яку окрему документацію коду, яку ви могли мати (опубліковані API), що може бути особливо дорогою проблемою, якщо її надруковано (друкована копія).
Я вважаю, що часто "маркетингові" суб'єкти точно не відповідають внутрішнім структурам. У таких випадках має сенс вводити сутність на іншому рівні абстракції, що робить термінологічні відмінності суперечливими.
Наприклад, у нас є модель, яка представляє ієрархію. Кожен рівень в ієрархії має пов'язаний з ним термін, заснований на тому, як ієрархія використовується для моделювання відносин у реальному світі, але внутрішньо немає різниці в поведінці від одного рівня ієрархії до іншого. Термінологія - це по суті лише назва цього рівня в ієрархії, тому для конкретного вузла в дереві ім'я просто описує, що таке вузол; це не передбачає особливої поведінки.
Також дерево багатокореневе, тому без батьків є кілька вузлів. Хоча концептуально корінь існує (він би по суті представляв Всесвіт), і включення його до моделі було б багатьма операціями набагато простішими, "маркетингового терміна" для нього немає.
Звичайно, різні компоненти в нашій системі використовують різну термінологію. Їх розробляли в різний час різними командами, і ми не маємо контролю над усіма ними. Власне, в якийсь момент хтось додав або видалив рівень в одному компоненті, і тому інші рівні зміщуються відносно один одного. Ті ж три рівні представлені A, B і C в одному компоненті, але як B, C і D в іншому.
Якщо зробити крок в абстракції і просто моделювати все як "вузол" або щось настільки ж загальне, це робить такі моделі набагато простішими. Кожен вузол знає, що таке його "маркетинговий термін", і тип, який представляє конкретний маркетинговий термін, може знати, що означає цей термін у кожному контексті.