項目名と変数名のジレンマ

Transcript

1. © Cake.jp Co.Ltd. All Right Reserved.｜Confidential 2024/5/23
 項目名と変数名のジレンマ
 
 釘野　雅史

2. 2 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential 自己紹介 • 名前 ◦ 釘野 雅史 / Masafumi Kugino • 業務 ◦ 会員のサイト利用率向上 ▪ 記念日登録推進 ▪ くじ引き機能の実装 ▪ 新規メールバッチの実装 • おすすめ🍰 生チョコケーキ by L'AURA(ローラ) 生チョコをそのままケーキにしました！ という圧倒的なチョコ感が良かったです。
3. 3 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential userId というカラムが、order（注文）テーブルにあります。 さて、何の番号でしょうか？ 前提
4. 4 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential 注文のuser（使用者）だから、お客さんの番号っぽい？ 前提
5. 5 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential 注文のuser（使用者）だから、お客さんの番号っぽい？ 違います。 前提
6. 6 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential 注文のuser（使用者）だから、お客さんの番号っぽい？ 違います。 システムのuserなら、社員スタッフの番号っぽい？ 前提
7. 7 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential 注文のuser（使用者）だから、お客さんの番号っぽい？ 違います。 システムのuserなら、社員スタッフの番号っぽい？ 違います。 前提
8. 8 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential 注文のuser（使用者）だから、お客さんの番号っぽい？ 違います。 システムのuserなら、社員スタッフの番号っぽい？ 違います。 答えは、ケーキ屋さんの店舗番号です。 前提
9. 9 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential なるほど システム的にはケーキ屋さんをuserとして、userテーブルで管理しているのですね！ 前提
10. 10 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential なるほど システム的にはケーキ屋さんをuserとして、userテーブルで管理しているのですね！ 違います。 前提
11. 11 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential なるほど システム的にはケーキ屋さんをuserとして、userテーブルで管理しているのですね！ 違います。 ケーキ屋さんはcompanyテーブルで管理しています！！ 前提
12. 12 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential つまり ケーキ屋さんの店舗番号 ＝ orderテーブルのuserId = companyテーブルのid となっています。 そして、ここまでは「前提」です。 私が入社する前から、サイトは運用されており、 今お話した内容は、すでに実装されている状況でした。 前提
13. 13 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential 不満のポイント システムのコードでは、カラム名に合わせて $userIdという変数が利用されていました。 しかし、仕様書や管理画面など実態に即した項目名は、 ケーキ屋さんの店舗番号です。 この項目名と変数名の不一致に、開発をしていく上での不満を感じました。 どうすれば、この不満が改善されるか、当時の私は３つほど案を考えました。 問題編
14. 14 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential 【案１】 データベースのテーブル名、カラム名を実態に即したものに変更する。 不採用の理由 データベースの構成を変更すると影響範囲が広すぎるため、改修のための工数がかかりすぎて、実 施が現実的ではない。 解決編
15. 15 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential 【案２】 項目名をカラム名に即したものに変更する。 不採用の理由 「ケーキ屋さんの店舗番号」を「使用者番号」と言い換えても、そもそも、実態はお店の番号であり、項 目名をカラム名に合わせても意味がない。 解決編
16. 16 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential 【案３】 コーディングする際に変数名を項目名に即した名前にして、そこに値を代入する。 例：$shopId = $orderData[‘userId’]; 採用した理由 これならば、大規模な改修の必要がなく、実態が分かりやすい変数名になります。 そして、それ以降のコードの読み解きが楽になることを期待しました。 解決編
17. 17 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential 今回のしくじりポイント 「自分一人が考えた自分ルールで、コーディングをしていた」 項目名と変数名の不一致が不便だと思ったのは、私一人ではなかったようでした。 その結果・・・
18. 18 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential 結果として何が起こったかというと $userId に加えて $shopId $storeId $companyId など、コードの中に、同じ番号に似たような変数名が乱立してしまいました。 新しい混乱を招いた
19. 19 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential 問題点１ 以下のようなカラム名と変数名のことなるコードがシステム全体に分散していた。 例1：$shopId = $orderData[‘userId’]; 例2：$companyId = $Order->getUserId(); 対策 コードの一箇所にデータベースのカラム名を変更するという知識を集積させた。 名前の変更用クラスを作った。 また、それ用のフォルダやネームスペースで区切った。 反省と改善
20. 20 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential 問題点２ 開発フローの中で、動作レビューのみで、コードレビューの文化がなかった。 当時は、開発者の人数も少なく、入れ替わりも多かった。 各々が任意で声を掛け合いながら、コーディングをしていた。 対策 Githubのプルリクエスト機能の利用し、コードレビューを必須にした。 他の開発者のチェックなしに、本番用コードへ修正を追加できなくした。 反省と改善
21. 21 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential その上で、チーム内で事前に問題意識の共有、どう直すかの周知が必要だった。 そして、こんな感じの資料を先に作っておくべきでした。 これを今後どのような文言を使うか、チーム内の指針とした。 反省と改善
22. 22 © Cake.jp Co.Ltd. All Right Reserved.｜Confidential • 今回の課題 ◦ 『カラム名や変数名が、項目名や実態と一致していない』 • 影響 ◦ チームへの参入者への教育コストが増える。 ◦ コードを読む際に、言葉を変換する認知負荷が増える。 ▪ コードレビューが面倒なものになってくる。 • 教訓 ◦ コーディングにおいて命名は大事。 ◦ ただし既存の命名に不満があっても、良かれと勢いで変えない。 ▪ 事前に課題意識の共有や知識の集積をする。 - まとめ -