エンドユーザーの命名法が変更された場合、コードとデータの名前をどこまで変更する必要がありますか？

かなり前に、ワークフローキューに追加された画像をユーザーが「受け入れる」機能を追加しました。結局、間違った用語を使用し、ユーザーは実際に画像を「承認」しました。

インターフェースのAcceptをApproveに変更するのは簡単です。1つの単語を置き換えるだけです。ただし、CSSクラス名からデータベース値まで、すべてのレイヤーを「accept」という単語でプログラミングしました。

• ボタンを緑色にするCSSクラス： ".accepted";
• DOMノードのクラス属性を検証およびバインドするモデルメソッド： "isAccepted";
• JavaScriptステータス属性：「未確認」、「承認済み」、「公開済み」の配列。
• Mysqlステータス列：「未確認」、「承認済み」、「公開済み」のENUM。
• テスト名;

承認する承認のほとんどの出現を置き換えることは簡単です（特にテストがある場合）。特に、展開と同期する必要があるため、データを移行するのが少し難しくなります。

この特定のケースは単純ですが、私のキャリアの中で、同様の、さらに複雑なケースに直面しました。ファイルの名前も変更され、数十台のサーバーで展開が行われる場合、またはプロキシキャッシングの場合、memcachedとmysqlが関係します。

インターフェース以外のすべてのレイヤーに「受け入れられた」ままにしておくのは悪い考えです。チームに参加する新しいプログラマーは、この決定に至った歴史的な理由を学ばない可能性があるためです。 「管理上の次のステータス会議のためにキューに入れられました」に名前が変更されました、それは確かに意味をなさないでしょう。そして、あちこち妥協しても、ユーザーインターフェイスの概念はシステムの内部に影響を与えないことを何度か繰り返しますが、出力の半分が内部に接続されていないシステムで作業したくはありません。

だから、必要なときに常にすべての名前を変更していますか？これがあなたに起こり、トレードオフは価値がないと判断した場合、それはあなたを噛むために戻ってきましたか？この問題を回避するには、コードコメントまたは開発者向けドキュメントで十分ですか？

私にとって、問題のアイテムに関連するすべてを変更することは間違いなく最善です。

これはコードの劣化の一形態であり、変更されていない1つの項目は大した問題ではないかもしれませんが、コードベースのトーンを設定します。

また、将来的に混乱を招き、新しい開発者がコードベース/ドメインを理解しにくくなる可能性もあります。

質問の内容とタグから、ユビキタス言語を使用していると思います。

私の経験では、ULは素晴らしいですが、あなたが言ったように、言語が進化するにつれて追加のメンテナンス作業につながる可能性があります。これ自体は悪いことではありません。確かに、それは不便ですが、それも期待されています。

私が通常やった（そして見た）ことは次のいずれかです。

• 1ショットの事前リファクタリング：アプリケーションのすべてのレイヤーをリファクタリングして、更新された言語を採用します。または
• 技術的負債を記録する：ユーザー向けのコードをすぐに変更し、技術的負債タスクを記録して、残りのアプリケーション層を更新された言語に合わせることができます。これにより、通常、いくつかの退屈な（しかし管理可能な）タスクが発生します。（午後5時に最適！）

ここで重要なことは、あなたが説明しているのは技術的負債であり、そのように認識されるべきだということです。

目に見える機能を追加しないようなささいなタスクに時間を浪費するべきではないと主張したマネージャーがいました。これは、借金のアナロジーが本当に役立つときです。要約すると、次のとおりです。

チームは、ユビキタス言語でDDDを行うことを選択しました。コードを一貫性のない状態のままにしてこのアプローチから逸脱すると、混乱が生じ、DDDとULが提供する多くの利点がなくなります。管理者の用語では、プロジェクトにコストが追加されます。コードの管理はより困難（高価）になり、新しい開発者にとっては混乱（高価）になります。

ローカリゼーション（l10n）オプションを調べてください。英語からスペイン語に行くほど劇的ではないように思えるかもしれませんが、同じ概念に対して異なる用語を扱っています。これが一般的に発生するように思われる場合、l10nを使用すると、コードで使用される用語を変更せずに、ユーザーインターフェイスに表示される内容をすばやく変更できます。

これを設定したら、コードで最も広く理解されている用語を使用してください。開発者がそれを知っており、期待するかもしれないように、ドメインから名前を選択します。

これを適切に表すと、ソースのすべての部分でエンドユーザーの命名法の変更を追跡することは、かなりの投資です。ただし、完全なインフラストラクチャ（ホットライン、テスターなど）で開発された長寿命の製品では特に価値があります。

ソースでエンドユーザーの命名法を追跡することは投資です。なぜなら、非常に多くの種類のコンポーネントが表示され、これらすべてのコンポーネントで同時に動作する魔法の杖がないからです。コンポーネントごとにこのような魔法の杖を開発することは、プロジェクトの存続期間にわたって希釈できる興味深い投資かもしれません。

私は、エンドユーザーの命名法と内部の命名法の間のドリフトが特に大きくなった30年前のコードベースで作業しました。以下に、この状況のいくつかの欠点を示します。これらはすべて、全員の作業のオーバーヘッドに追加されます。

1. 適切なポリシーがない場合、新しい開発では現在のエンドユーザーの命名法を使用する傾向があります。したがって、同じ概念が異なるコンポーネントに2つ以上の名前を持つ場合があります。コンポーネントは相互作用するため、コードの一部のローカル部分に複数の同義名が擬似的に存在します。

2. ホットライン/ヘルプデスクが呼び出されると、エンドユーザーの命名法を使用してユーザーストーリーを書き留めます。問題の修正を担当する開発者は、エンドユーザーの命名法をソースの命名法に一致するように翻訳する必要があります。もちろん、アーカイブされていませんし、もちろん混乱しています。（1を参照）

3. プログラマーがコードをデバッグするとき、彼女は関連する関数にブレークポイントを設定したいと考えています。エンドユーザーの命名法とソースの命名法が一致しない場合、適切な関数を見つけるのは困難です。関連する機能のリストが完全であることを確信することは、困難または不可能でさえあるかもしれません。（1を参照）

4. 適切なポリシーがない場合、廃止された命名法を使用したソースの保守により、この廃止された命名法がユーザーの前に再び表示されることがあります。これにより印象が悪くなり、オーバーヘッドが発生します。

データベースからデータが読み取られ、このコードベースの一部のコンポーネントに注入される場所を、2日間追跡しました。私も私が働いていた会社の誰もがこの場所に通じる名前を把握できたので、私は最終的に却下し、その問題の別の解決策を見つけることにしました。

何ももたらさずに2日間を超えるメンテナンス（知識なし、修正なし、何もない）がかかるのはおそらく悪いことですが、ユーザーの命名法とソースの命名法の不一致は、メンテナンスの多くのルーチンタスクにオーバーヘッドを追加しますソフトウェア。

大規模な組織では、ソフトウェアを製造する会社によってオーバーヘッドコストが増大することに注意することが重要です。大規模な組織では、問題レポートが複数の同僚によって検討される前にデスクに届かず、修正がテストされる可能性があります。

[1]複数の開発者が関与しているため。

一部のパッケージは顧客間で共有されるため、コードとデータの名前を常に変更するとは限りません。彼らは基本的に同じものを使用していますが、異なる呼び方をしています。たとえば、CMSでは、あるクライアントが顧客を「顧客」と呼び、別のクライアントが「クライアント」を使用します。そのため、1つのクライアントについては、顧客を表面的にクライアントに置き換えましたが、CMSは常に顧客管理システムになります。

別の例は、アクセス許可対アクセス制御リスト、管理者対マネージャーなどの用語を使用したユーザー管理です。新規参入者を混乱させる可能性があります。他の開発者も簡単に実装できます（構成可能なラベルを作成するなど）。

この変更を行った場合、同じ作品が他の顧客によって使用され、基本的には製品になったとしても、再度行う必要はないと考えてください。