長いので章ごとにしてます。
10 名前設計 ーあるべき構造を見破る名前ー
- 名前はとても大事だと思っています。
- 適当な名前しかつけられないときは、多分足りないピースが残っていて、分析しきれないときだと思っています。
- なので、自分は結構ギリギリまでヒアリングしたりいろいろして、名前を決めるようにしています…。
10.1 悪魔を呼び寄せる名前
10.1.1 関心の分離
- 広すぎる関心……めちゃくちゃわかります。まだ上手くいなせてません…。
10.1.2 関心事にふさわしい命名
- 関心事に関する名前をつけて分離してしまう…なるほどです。
- 予約品、注文品…は商品を継承したり関連を持たせたりしないのはなんででしょう？
10.1.3 大雑把で意味が不明瞭な名前
- 「いい加減」と言い切ってしまうのはどうかと思いますが…その名前が存在することで様々な処理を集めてしまう魔力を持っているというのは…実感があります。
10.2 名前を設計する─目的駆動名前設計
- 「名前設計」…自分もこのつもりでやってました。
- 「名前をつける」行為が結構軽んじられていると思っていました。
- 分析・設計の結果でようやく名前が決まるので、「設計」という言葉を入れるのはちょっとマネしていきたいです。
- ja.wikisource.org
10.2.1 可能な限り具体的で、意味範囲が狭い、目的に特化した名前を選ぶ
- 目的に特化した名前、割とよさそう…。
10.2.2 存在ベースではなく、目的ベースで名前を考える
- うーん…こんなに細かくするの？という気持ちと、うまくいくかもなという気持ちと両方あります。
- 試された方います…？
10.2.3 どんなビジネス目的があるか分析する
- みんなで分析しよう！はわかったけど、オススメの手法とか言及がほしかったかも。
10.2.4 声に出して話してみる
- 声に出す、は自分も有効だと思ってます。声の出力を耳で入力するので、頭の中で考えるだけより、刺激が多い印象です。
10.2.5 利用規約を読んでみる
- なるほど、これは思いつきませんでした。
- 主要なオブジェクトについて正確な名前を抽出できるかも…。
- しかも関連が集中しそうなあたりになりそう。
- 参考になります！
- …とはいえ、これはリファクタリングのときのテクニックかなぁ。リリース前にはないもんね…。
- 先に書いてもらえないかなぁ…。
10.2.6 違う名前に置き換えられないか検討する
- 顧客 → [宿泊する人、支払う人] …結構この手のヤツありますね…。
- うちも ユーザー → [チャレンジャー、サポーター、非サポーター] みたいなのがあります…。
- 類語辞典…！
- 今ならChatGPTに訊いてもいいかも。「〜に似た言葉をあげて」とか。
10.2.7 疎結合高凝集になっているか点検する
- 関連の個数を見てチェックするのは確かにいいかも。
- 今すでにめっちゃ多いわけですが…。十分に少なくなったな…と思うくらいまで特化しようということですかね…？
- クラス図の自動生成の混乱具合も参考になるかも…。
10.3 設計時の注意すべきリスク
10.3.1 名前無頓着になるな
- 「チーム内で約束」はたしかにそうかも。
- 約束してないから、無頓着な名前が来る……。
- 自分の常識が他人の常識とは限らないというのは当然なので、ちゃんと共通化したほうがよさそう。
10.3.2 仕様変更時の「意味範囲の変化」に警戒
- 比較的よくありますね…。どこかでがんばって分けないと…！
- あと、時間でビジネスが変わっていくのもあって…やりにくい印象です。
10.3.3 会話には登場するのにコード上に登場しない名前に注意
- わかる…！いっぱいメソッド化しました！
- わりと重要なものが多かった印象…。
- 逆に名前だけあって、定義も対象もないのもありました…。
10.3.4 形容詞で区別が必要なときはクラス化のチャンス
- クラス化…そこまでするかどうかと思いましたが、アリかもしれません。
10.4 意図がわからない名前
- 流石にtmp1〜5まであるのなんて、ないでしょ？（ないといってほしい…。）
10.4.1 技術駆動命名
- ビジネス目的にあってるかどうかはめっちゃ重要な気がしてます。
- しかし…技術駆動命名、個人的にはあんまり見たことがないような…？
Column 技術駆動命名を用いる分野もある
- そりゃデバイスに直接関わるんならねぇ…。
10.4.2 ロジック構造をなぞった名前
- こりゃあかんやろw
- メソッド化するなら、少し上位の概念にしないとね…。
- …！目的が不理解だとなる…同意。
10.4.3 驚き最小の原則
- こんな事ある？？？（見たことある><）
