Як далеко ми повинні перейменовувати код та дані, коли змінюються номенклатури кінцевих користувачів?

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

Змінити Accept to Approve на нашому інтерфейсі досить просто, просто замініть одне слово. Але ми запрограмували всі шари на слово «прийняти», від назви класу CSS до значень бази даних.

• Клас CSS, який перетворює кнопку в зелений колір: ".accepted";
• Метод моделі, який перевіряє та прив'язує атрибут класу до вузла DOM: "isAccepted";
• Атрибут статусу JavaScript: масив із "непереглянутою", "прийнятою" та "опублікованою";
• Стовпець статусу Mysql: ENUM з "непереглянуто", "прийнято" та "опубліковано";
• Імена тестів;

Тривіально (особливо, коли у вас є тести) замінити більшість випадків прийому для затвердження. Трохи важче перенести дані, тим більше, що це потрібно синхронізувати з розгортанням.

Цей конкретний випадок простий, але я зіткнувся з подібними, але складнішими справами протягом своєї кар’єри. Коли файл також перейменований і розгортання відбувається на десятках серверів, або коли задіяно кешування проксі, memcached та mysql.

Залишати "прийнятим" на будь-якому іншому шарі, крім інтерфейсу, це погана ідея, оскільки нові програмісти, які приєднуються до команди, можуть не дізнатися історичних причин, що призвели до цього рішення, і поки прийняти -> схвалити - це близькі за змістом слова, якщо це було перейменовано на "чергову чергову зустріч із керівництвом", це, звичайно, не мало б сенсу. І це відчуває, якщо ми робимо компроміс тут і там, за декілька ітерацій поняття інтерфейсу користувача не матимуть підшипників до внутрішніх систем, і я, звичайно, не хочу працювати в системі, де половина виводу не має зв'язку з її внутрішніми.

Отже, чи завжди ви перейменовуєте все, коли потрібно? Якщо це трапилося з вами, і ви вирішили, що компроміс не вартий, чи повернувся ви, щоб вкусити вас? Чи достатньо коментаря до коду чи документації для розробників, щоб уникнути цього питання?

Для мене, безумовно, найкраще змінити все, що стосується предмета, про який йде мова.

Це форма деградації коду, і хоча 1 елемент, який не змінюється, може не бути великою справою, він задає тон базі коду.

Це також може призвести до плутанини в майбутньому і ускладнить новим розробникам розуміння бази / домену коду.

Зі змісту питання та тегів, я вважаю, ви використовуєте всюдисущу мову.

На мій досвід, UL - це чудово, але, як ви вже згадували, це може призвести до додаткових завдань з технічного обслуговування в міру розвитку мови. Це саме по собі не є поганою справою. Звичайно, це незручно, але це також очікувано.

Що я зазвичай робив (і бачив, що робив):

• 1-кадр переднього рефакторингу: перефактуруйте всі шари програми, щоб прийняти оновлену мову; або
• технічний борг журналу: Ви можете змінити код, орієнтований на користувача, одразу, а потім виконати завдання технічної заборгованості, щоб привести решту шарів програми у відповідність до оновленої мови. Це, як правило, призводить до кількох нудних (але керованих) завдань. (Ідеально для 17:00!)

Я думаю, що головне тут - те, що ви описуєте, - це технічна заборгованість, і її слід визнати такою.

У мене були менеджери, які стверджували, що ми не повинні витрачати час на такі тривіальні завдання, які не додають видимих ​​функціональних можливостей. Це коли корисна заборгованість дійсно стане в нагоді. Це зводиться до цього:

Команда вирішила робити DDD з всюдисущою мовою. Відмова від такого підходу, залишаючи код у непослідовному стані, додає плутанини та усуває багато переваг, які надають DDD та UL. З точки зору менеджера, це додає вартості проекту. Код стає складніше (дорого) в управлінні та більш заплутаним для нових розробників (дорогий).

Ви можете переглянути параметри локалізації (l10n). Хоча це може здатися не таким різким, як перехід з англійської на іспанську, ви маєте справу з іншим терміном для тієї ж концепції. Якщо це, здається, трапляється зазвичай, то використання l10n дозволяє вам швидко змінити те, що відображається в інтерфейсі користувача, не змінюючи термін, що використовується в коді.

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

Як ви це належним чином зображуєте, відстеження змін номенклатури кінцевих споживачів у кожній частині джерела - це цілком інвестиція. Однак це, безумовно, варто, особливо для довгоживучого продукту, розробленого повною інфраструктурою (з гарячою лінією, тестерами тощо).

Відстеження номенклатури кінцевих споживачів у джерелі - це інвестиція, оскільки існує так багато типів компонентів, де вона з'являється, і немає чарівної палички, яка працює одночасно на всіх цих компонентах. Можливо, розробка такої чарівної палички, складової за компонентом, є цікавою інвестицією, яку можна розбавити протягом життя проекту.

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

1. За відсутності відповідної політики нова розробка має тенденцію використовувати номенклатуру кінцевих споживачів. Таким чином, одне і те ж поняття може мати два і більше імен у різних компонентах. Оскільки компоненти взаємодіють разом, це призводить до декількох синонімічних імен, що існують одночасно в деяких локальних частинах коду.

2. Коли телефонує «гаряча лінія» / довідкова служба, вони записують історію користувача за допомогою номенклатури кінцевих користувачів. Розробник, відповідальний за виправлення проблеми, повинен перевести номенклатуру кінцевого користувача на відповідну номенклатурі джерела. Звичайно, це не архівовано, і, звичайно, це безлад. (Див. 1.)

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

4. За відсутності адекватної політики підтримка джерела з використанням застарілої номенклатури час від часу знову поставить цю застарілу номенклатуру перед користувачами. Це справляє слабке враження і спричиняє накладні витрати.

Я вже два дні відстежував місце, де деякі дані зачитуються з бази даних та вводяться в якийсь компонент цієї кодової бази. Оскільки, чи я, ні хтось із компанії, в якій я працював, не зміг зрозуміти ім’я, яке веде до цього місця, я остаточно відмовився і вирішив знайти інше рішення цієї проблеми.

Незважаючи на те, що витрати на обслуговування більше [1], не даючи нічого (не знаючи, не виправляючи, нічого), напевно, такі ж погані, як це може отримати, розбіжності між номенклатурою користувачів та номенклатурою джерел додають накладні витрати на багато рутинних завдань у підтримці програмне забезпечення.

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

[1] Через участь одного розробника.

Я не завжди перейменую код і дані, тому що деякі пакети надаються клієнтам. Вони в основному використовують одне і те ж, але називають це по-іншому. Приклади, в CMS один клієнт називає свого клієнта "Клієнт", а інший використовує "Клієнт". Таким чином, ми замінили клієнта на клієнта на поверхні для одного клієнта, але CMS завжди буде системою управління клієнтами.

Інший приклад - управління користувачами з такими термінами, як дозволи та список контролю доступу, адміністратор проти менеджера тощо. Це може бути заплутано для нових користувачів, але для основних компонентів, таких як, зазвичай, розробники ядер, які гарантують, що ці компоненти працюють для всіх клієнтів і також простий у застосуванні іншими розробниками (наприклад, шляхом створення настроюваних міток).

Це може допомогти подумати, що якщо ви внесете цю зміну, сподіваємось, вам не доведеться робити це знову, якщо той самий фрагмент буде використаний іншим замовником, в основному перетворюючи його на товар.