Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
責務と認知負荷を整える! 抽象レベルを意識した関心の分離
Search
y_ahiru
February 21, 2025
Programming
10
1.8k
責務と認知負荷を整える! 抽象レベルを意識した関心の分離
PHP Conference 名古屋 2025 の登壇資料です
https://phpcon.nagoya/2025/
y_ahiru
February 21, 2025
Tweet
Share
More Decks by y_ahiru
See All by y_ahiru
さいきょうのレイヤードアーキテクチャについて考えてみた
yahiru
3
830
フロントエンドエンジニアも知っておきたい HTTP/3 で変わること
yahiru
16
13k
ゆるふわCQRS入門
yahiru
2
620
設計におけるソリューションドメイン
yahiru
3
1.6k
PHPで始めるGitHub Actions
yahiru
1
750
5ヶ月でカバレッジを20%から90%にあげた話
yahiru
2
6.7k
入門ミューテーションテスト/ A bigginer's guide to Mutation testing
yahiru
0
1.5k
Eloquentに別れを告げるタイミングについて考えた
yahiru
2
2k
DDDについて勉強したので5分でまとめる
yahiru
0
320
Other Decks in Programming
See All in Programming
Preact、HooksとSignalsの両立 / Preact: Harmonizing Hooks and Signals
ssssota
1
670
Node.js, Deno, Bun 最新動向とその所感について
yosuke_furukawa
PRO
6
3k
安全に倒し切るリリースをするために:15年来レガシーシステムのフルリプレイス挑戦記
sakuraikotone
5
2.2k
Compose Navigation実装の見通しを良くする
hiroaki404
0
180
イベントソーシングによってインピーダンスミスマッチから解放された話
tkawae
1
330
マルチアカウント環境での、そこまでがんばらない RI/SP 運用設計
wa6sn
0
560
ステートソーシング型イベント駆動の視点で捉えるCQRS+ES
shinnosuke0522
1
320
snacks.nvim内のセットアップ不要なプラグインを紹介 / introduce_snacks_nvim
uhooi
0
330
Windows版PHPのビルド手順とPHP 8.4における変更点
matsuo_atsushi
0
360
2025/3/18 サービスの成長で生じる幅広いパフォーマンスの問題を、 AIで手軽に解決する
shirahama_x
0
160
OpenTelemetryを活用したObservability入門 / Introduction to Observability with OpenTelemetry
seike460
PRO
0
280
Django for Data Science (Boston Python Meetup, March 2025)
wsvincent
0
230
Featured
See All Featured
A Tale of Four Properties
chriscoyier
158
23k
Thoughts on Productivity
jonyablonski
69
4.5k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
11
610
Code Review Best Practice
trishagee
67
18k
Visualization
eitanlees
146
15k
What's in a price? How to price your products and services
michaelherold
245
12k
Git: the NoSQL Database
bkeepers
PRO
429
65k
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
Rails Girls Zürich Keynote
gr2m
94
13k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.5k
Optimizing for Happiness
mojombo
377
70k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
2.9k
Transcript
責務と認知負荷を整える ! 抽象レベルを意識した関心の分離 PHPカンファレンス名古屋 2025
名前: 吉田あひる (@strtyuu) 仕事: エンジニア 所属: スターフェスティバル株式会社 自己紹介
こんなことありませんか? • 「この関数の実装、頭に入りきらないな...」 • 「結局このコード何がしたいんだ...?」
それ、抽象レベルが 合ってないせいかも
このセッションでお話しすること • 抽象レベルを整えることによって読み手の認知負荷を下げることができる • 抽象レベルを整えることで関心の分離を進めることができる
抽象レベルと認知負荷 〜自然言語編〜
今日の夜、友達とご飯にいってくるわ • 家族との日常会話であれば違和感のない、適切な抽象レベルの文章
2025年2月22日17時15分に家を出て 17時30分発◦◦行き の電車に乗って ◦◦駅で中学の頃から仲の良い ◦◦くんと合 流した後、愛知県名古屋市 ◦◦の1−2−3◦◦ビル6Fにある ◦◦っていう中華料理屋に行ってエビチリを食べてくる • いや、要点を話してくれ!
• 抽象レベルが下がりすぎた例 • 抽象度が下がり具体的になってくると情報が増えていき、情報が多すぎると認知 負荷がかかってくる
今年中に生き物と愛を実感してくるわ • (困惑) • 抽象度が上がると情報量が削られる • そのため、抽象度が高すぎると必要な情報が消えて理解不能になる ◦ 今日の夜 ->
今年 ◦ 友達 -> 生き物 ◦ 食事 -> 愛を実感する行為※1 • 一方で、情報が削られた代わりに包含される具象の数は増える ※1 wikipedia 「食事」より
ここまでのまとめ • 抽象レベルは高い・低いでグラデーションがある • 抽象レベルは情報量を変える力を持つ • 抽象レベルが低すぎると不要な情報が多くなり認知負荷が上がる • 抽象レベルが高すぎると必要な情報が消えて理解が難しくなる •
日常の会話は情報の過不足が少ない適切な抽象度であることが多い
抽象レベルと認知負荷 〜プログラム編〜
会員登録ロジック 1. メールアドレスの重複がないか確認 2. 重複があればエラーを返す 3. 重複がなければパスワードをハッシュ化 4. 入力値から会員を作成する
実際に書くと こうなりがち
実際に書くと こうなりがち users テーブルから email カラムの値 が一致するレコードを取得
実際に書くと こうなりがち users テーブルから email カラムの値 が一致するレコードを取得 レコードが空でない場合は 例外を投げる
実際に書くと こうなりがち users テーブルから email カラムの値 が一致するレコードを取得 レコードが空でない場合は 例外を投げる パスワードをハッシュ化
実際に書くと こうなりがち users テーブルから email カラムの値 が一致するレコードを取得 レコードが空でない場合は 例外を投げる パスワードをハッシュ化
入力値を元に users テーブル にレコードを追加する
自然言語の説明と乖離が発生している 自然言語 1. メールアドレスの重複がないか確 認 2. 重複があればエラーを返す 3. 重複がなければパスワードをハッ シュ化
4. 入力値から会員を作成する プログラム 1. users テーブルから email カラム の値が一致するレコードを取得し、 レコードが空であるか確認する 2. 空でない場合は例外を投げる 3. 重複がなければパスワードをハッ シュ化 4. 入力値を元に users テーブルにレ コードを追加する
自然言語の抽象レベルが低すぎた例 に似ていませんか?
何が問題か ? このサンプルコードレベルであれば大きく問題にはならないものの... • 「やりたいこと」と「書かれていること」に抽象レベルのギャップが生まれている • そのため作者の気持ちを考えて意訳するコストが発生する ◦ レコードが空ではない状態は何を意味するのか?など •
これが認知負荷の上昇につながる ◦ 意訳コスト ◦ それに伴う脳のメモリ圧迫
なぜ認知負荷が向上するのか? 脳のメモリ問題
読み手の気持ちを 考えてみる
読み手の気持ちを 考えてみる なんでいきなりクエリを投げてる んだろうか?
読み手の気持ちを 考えてみる records が空でない状態は 何を意味するんだろうか? なんでいきなりクエリを投げてる んだろうか?
読み手の気持ちを 考えてみる records が空でない状態は 何を意味するんだろうか? なんでいきなりクエリを投げてる んだろうか? なるほど records が空でない状態はメアド
が重複しているということか!
意訳できるまでコードを忘れられない • この例では Exception を投げている行を読むまでそれ以前のコードを意訳できな いことがわかる • そのため、それ以前のコードを全て覚えておく必要がある • これによって脳のメモリを消費するので、認知負荷の上昇につながる
ここまでのまとめ • 「やりたいこと」と「コードで書かれていること」の抽象レベルのギャップが発生する と、認知負荷の上昇につながる • コードの抽象レベルが低すぎる場合の認知負荷上昇の原因は以下の2つがある ◦ 意訳コスト ◦ 脳のメモリ圧迫
どうすればいいか
自然言語を手がかりに抽象レベルを整える • もしそのロジックを自然言語で説明するとしたらどのような文章になるか • その文章に近づけるためにどのようなコードを書けばいいのか
なぜ自然言語? • 読みやすさ・読みにくさは読み手に依存している ◦ 関数型に慣れていると map や reduce は読みやすい ◦
そうでない人は for 文の方が読みやすい • そのため、ある程度多くの人が馴染みやすいコードを目指していきたい • 自然言語との乖離が少ないものは多くの人に馴染みやすいのでは?
コードの抽象レベルを整える 3つのアプローチ • 別クラス(あるいは関数)化 • プライベート関数化 • コメント追加
別クラス化 抽象レベルの異なる部分を 別クラスとして切り出す 自然言語を元にこういう書き方が できると良さそうという API を考え る それに合わせた API
を作る
プライベート関数化 再利用性を考える必要のない場合に 有効。 切り出す際の考え方はクラス化と ほぼ同じ
コメント追加 • 意訳を読み手にさせない • 対象となるコードの行数が 少ない場合に有効
3つのアプローチのフローチャート
抽象レベルと関心の分離
抽象レベルに応じた関心の分離 会員登録ロジック メールアドレスの重複がないか確認 重複確認ロジック users テーブルから email カラムの値が一致するレコー ドを取得し、レコードの件数を確認する 重複しているかどうかだけが関心に
どのように重複チェックをするかが関心 に
ロジックが「何をしたいのか」にフォーカスされる • 自然言語で考えるとその抽象レベルにおいて関心のない情報が自然と省かれや すくなる • 省かれる情報はその抽象レベルからすると How に見えることが多い • その結果「つまり何がしたいんだっけ?」をロジックが端的に表現してくれるように
なる
抽象レベルを揃えると 抽象レベルに応じた関心の分離ができる ※あくまで抽象レベルの観点からの話あって、関心の分離自体はもっとさまざまな軸からアプ ローチされるべきではある
まとめ • 抽象レベルにギャップがあると認知負荷が高い • 自然言語に頼ると抽象レベルを整えやすい • 抽象レベルが整うと認知負荷が下がり、ついでに関心の分離も少しできる
We Are Hiring !!