機能名の変更

ビジネスにおいて、フィーチャーの名前を変更したいと言われることがあります。大まかに言って、このタスクには2つのアプローチがあります。基本的には、目先の労力と将来の複雑さ/バグリスクのトレードです：

  • リポジトリ内のすべての名前を変更します。
    • 長所：コードの複雑さを増加させません。
    • 短所：実行に手間がかかる、即座にバグが発生するリスクが高い。
  • インターフェイス、ドキュメント、エラーメッセージなど、ユーザー向けのコンテンツのみ。
    • 長所：実行する作業が少ない
    • 短所：コードが複雑になり、将来バグが発生するリスクが高くなること。

ファサード・アプローチを選択するタイミング

以下に当てはまることが多いほど、ファサード・アプローチを選択すべきです：

  • 新しい名称が永続的なものであるかどうか確信が持てない場合。
  • バグが発生しやすい機能（大規模、複雑、リファクタリングが必要など）。
  • リネームのレビューが難しい（機能が多くの行、ファイル、リポジトリにまたがっている）。
  • リネームが何らかの形で破壊的である（データベーステーブルのリネーム）。

ファサードファーストアプローチを考えてみましょう

ファサード・アプローチは必ずしも最終ステップではありません。最初のステップとして扱われ、後の反復によって完全なリネームが行われます。