良い名前をつける

命名の基本: オブジェクト指向の基礎

名前の付け方: オブジェクト指向の基礎

例を用いてオブジェクト/クラス設計を見てみましょう…

状況

コード、SQL、またはエクセルシートでdata modelを設計した経験はありませんか？以下のような例は見たことがありますか？

*** anti-pattern - don't copy-paste ***
* User
  - id
  - avatarUrl
  - name
  - email
  - password

* Agent
  - id
  - primaryPhoto
  - name
  - email
  - agentEmail
  - agentPhoneMain
  - agentEmailPrimary
  - agentPhonePrimary
  - agentAddressFull
  - agentCompanyName
  - agentCompanyAddress
  - *userEmail* - 'Pointer' to User table ^^^

問題はどこに？

技術的にはバグは存在しません。単にデータの再構成が必要なだけです。

以下のような状況はよくあることではありませんか？

アプリケーションの変更は、何時間もの地道なデバッグを必要とします。
要件の変化は、以下のような結果をもたらします：

../schema_refactor

agentEmailPrimaryというフィールド名をなぜ悪いと呼ぶのでしょうか？

まず、あなたは宇宙に新たな存在を生み出しているわけではないということです。過剰な具体的な名前にはいくつかの罠があります：

非常に具体的な名前に「ロック」されていると、agentEmailPrimaryはビューと関連するコードの0%の再利用性を生み出し、以下のようなうっかりミスの再発を引き起こします：

テーブル間でのデータ同期が行われていない（user.emailがagent.agentEmailに伝播する必要があるのか、その逆なのかが明確でなく、手動で実装すべきロジックの場所や方法の複雑さも無視されている…）
バリデーションルール/ロジックが重複・不整合になりがち
プロジェクトは次第に傾いたジェンガの塔のように崩れやすくなる
新しいファイルごとに脆さが積み重なる。些細な変更にも極めて細心の注意を払う必要がある

agentEmailPrimaryという名前は複数の意味を持つ可能性がある。短い名前で曖昧さを排除する

過剰な表現に注意。Primary？これにより新たな疑問が生まれる：Secondaryもあるのか？これは主な相続人用なのか？

ダン、じゃあどうすればいいの？

解決策

// 統合されたスキーマ:

User
  - id
  - role: ['agent', 'lead', 'admin']
  - name
  - phone
  - address
  - email
  - password
  - company
    - name
    - address

Agentテーブルを削除した。なぜなら、エージェント特有のフィールドが含まれていなかったからだ。命名を整理したことで、User.companyオブジェクト（.name, .address）が自然に現れた。

いくつかの指針：

不要なテーブルを削除する。本当にstatusesテーブルが必要か？Userテーブルにstatus::VARCHAR(8)フィールドを追加するだけでも十分かもしれない。行あたりのバイト数が増えることは問題ではない。
関連するテーブルを統合する。Data
重複するデータ収集を削除する（例：Analyticsソリューションに置き換わった場合、ActivityLogsテーブルを削除する）。
すべてのフィールド名を単語/名詞/代名詞に統一する。テーブルが提供する文脈に依存しても構わない。（例：PersonalAccount.emailとBusinessAccount.email - テーブル名が文脈を提供する）
Agent.agentEmailやAgent.agentPhonePrimaryのような名前は存在しない。です。一緒に言いなさい：「emailとphoneです」。
高度に具体的な名前を使うと、コード再利用性や耐久性のレベルを石に刻むことになり、具体的にはゼロパーセントになる。
User.profileSummaryEmailのような馬鹿げた名前を使うのはやめろ。💞

おすすめの読書リスト：

良い名前をつける

名前の付け方: オブジェクト指向の基礎

状況

問題はどこに？

解決策

Share Stats