ケント・ベックに学ぶ『良いコード』の書き方

『良いコード』というテーマに対して自分がケント・ベックから学んだことをまとめました

Transcript

1. ケント・ベックに学ぶ 『良いコード』の書き方 2024.08.17 Kansai Dev Garage しが あきとし
2. 自己紹介 　 • なまえ ◦ しが あきとし(@akitoshiga) • 普段何してる？ ◦ 医療系HR企業のWebエンジニア ◦ 主にRuby on Railsアプリの開発 • 好きなプログラマー ◦ ロバート・C・マーティン ◦ ケント・ベック
3. 目次 　 1. ケント・ベックについて 2. ケント・ベックの『良いコード』 3. パターン 4. パターンの具体例 5. まとめ
4. 1. ケント・ベックについて
5. ケントベックとは 1. ケント・ベックについて • プログラマー • アジャイル開発におけるエクスト リーム・プログラミング(XP)の考案 者 • テスト駆動開発(TDD)の第一人者と しても有名 • 代表的な著書 ◦ 「エクストリームプログラミング」 ◦ 「テスト駆動開発」
6. なぜケント・ベックから学ぶのか？
7. ケント・ベックの『良いコード』に対する熱量がすごい 1. ケント・ベックについて 『 70年の人生は、20億秒を少し超えるに過ぎない。誇りの持てない仕事で無駄にする時 間はない。良いコードを書くこと自体が喜びであり、そのコードを他の人が理解し、評価 し、使用し、拡張してくれればさらに喜びは増す。 』 ケント・ベック「実装パターン」より引用
8. ケントベックの凄いところ 1. ケント・ベックについて • 職業人生を捧げるほどの『良いコード』に対する熱量 • コーディングに対する深い洞察 • 後述する『パターン』を用いてコーディングにおける個々の課題とその解決方法を抽 象化して再利用可能にするアプローチを推進した
9. 2. ケント・ベックの『良いコード』
10. ケント・ベックの考える『良いコード』とは？ 2. ケント・ベックの『良いコード』 『 70年の人生は、20億秒を少し超えるに過ぎない。誇りの持てない仕事で無駄にする時 間はない。良いコードを書くこと自体が喜びであり、そのコードを他の人が理解し、評価 し、使用し、拡張してくれればさらに喜びは増す。 』 ケント・ベック「実装パターン」より引用
11. コミュニケーション・シンプル・柔軟性
12. コミュニケーション・シンプル・柔軟性 2. ケント・ベックの『良いコード』 『 卓越したプログラミングにおいて必要とされる価値は、コミュニケーション、シンプル、 柔軟性である。これらの価値は互いに衝突するときもあるが、補完し合うことの方が多 い、拡張方法が数多く存在し、余分な要素が存在せず、読みやすく、理解しやすいのが 最高のプログラムだ。 』 ケント・ベック「実装パターン」より引用
13. コミュニケーション 2. ケント・ベックの『良いコード』 • 読み手が理解できるコード • 実装意図を正しく伝えらえるコード • 人間とコミュニケーションができるコードは保守のコストを大きく減らすことができる ◦ コードは書いた時間より読まれる時間の方が長い • ケント・ベックは開発をコードと人間のコミュニケーションと捉えた
14. シンプル 2. ケント・ベックの『良いコード』 • 『余分な複雑性』のないコード • 『余分な複雑性』とは ◦ 動作に影響のないコード ◦ 一生懸命動かそうとした痕跡のあるコード ◦ メンテナンス（リファクタ）されていないコード • 複雑なコード全てが悪というわけではない ◦ 解決すべき問題が複雑な場合はその複雑さが反映される →『本質的な複雑さ』 ◦ プログラミングには複雑さの玉と石を分ける作業が必要 • 何をシンプルとするかは個人による所がある ◦ ベテランにとってのシンプルは、初心者には難しすぎることも ◦ 読み手を意識した時に良いプログラムは生まれる
15. 柔軟性 2. ケント・ベックの『良いコード』 • 変更を容易に行えるコード • 柔軟性は非効率なコードや設計を正当化するために悪用されがちなので注意 ◦ プログラムが柔軟であるべきなのは、プログラムがその方向に変更される場合だけ ◦ 明日必要と思われた柔軟性すら必要とされない場合が多い • 凝った設計から得られる柔軟性よりも、シンプルと包括的なテストから得られる柔軟 性の方が効果的 • 「YAGNI」・「KISS」の原則を尊重する ◦ YAGNI →「You Ain’t Gonna Need It」 ◦ KISS →「Keep It Simple, Stupid」
16. これらの要素にケント・ベックは どうアプローチしたのか？
17. 3. パターン
18. パターンについて 3. パターン • ソフトウェア設計上の課題とその有効な解決策を再利用可能なように一般化したも の ◦ 例 GoFのデザインパターン • ケント・ベックはこのパターンの先駆け ◦ 1987年のOOPSLAで 「Using Pattern Languages for Object-Oriented Programs」を発表 • ケント・ベックはパターンを用いて『良いコード』を書くことを推進した
19. ケント・ベックの用いるパターンの特徴 3. パターン • 粒度が細かく幅広い ◦ ケント・ベックは多くのパターンを組み合わせてプログラミングをした ◦ クラスやメソッドの命名までにもパターンの考え方を取り入れている • どのパターンも必ずコミュニケーション・シンプル・柔軟性のいずれかの価値を反映 している • どのパターンも以下の6つの原則に従っている 1. 結果の局所化 2. 繰り返しの最小化 3. 対称性 4. ロジックとデータの一体化 5. 宣言型の表現 6. 変更頻度
20. 4. パターンの具体例
21. 注意 4. パターンの具体例 • 以降のパターンは全てRubyで書いています • Rubyに馴染みがない人向けに一般的なイディオムからは外れた書き方をしている 部分があります
22. パターン1. Composed Method
23. パターン1. Composed Method 4. パターンの具体例 Before After
24. パターン1. Composed Method 4. パターンの具体例 • プログラムを一つの事のみにするメソッドに 分割する • メソッド内部のメッセージは 同じ抽象度になる ようにする • メソッド内部の対称性が保たれ、かつ宣言型 で意図が表現されるため読みやすく、意図が 伝わりやすくなる • Beforeではメソッドの処理を追わなければな らないが、Afterではメソッドの呼び出しを見る だけで何をやっているかわかるようになる
25. パターン2. Double Dispatch
26. パターン2. Double Dispatch 4. パターンの具体例 Before After
27. 2. Double Dispatch 4. パターンの具体例 • オブジェクト指向的なパターン • 異なる2つの関心事の変更頻度を分割 • 多態性を用いて冗長な 『余分な複雑性』の排 除
28. パターン3. Method Object
29. パターン3. Method Object 4. パターンの具体例 Before After
30. パターン3. Method Object 4. パターンの具体例 • Composed Methodでも単純化できないほど メソッドが大きい場合は、そのメソッド自体を オブジェクトにしてしまう • 関連するデータをプロパティとして持つことで ロジックとデータを一体化 する • 多くの引数を持つ場合は、メソッドから引数が なくなることで可読性も向上する • Composed Methodと組み合わせて使うこと でより明確でシンプルなコードになる
31. 5. まとめ
32. まとめ 5. まとめ • ケント・ベックの考える『良いコード』はコミュニケーション・シンプル・柔軟性から成り 立つ • パターンを積極的に再利用し、効率的で的確なコーディングを行っている • ケントベックのパターンは6つの原則に従っている ◦ 結果の局所化・繰り返しの最小化・対称性 ◦ ロジックとデータの一体化・宣言型の表現・変更頻度 • 本日紹介したパターンやその他のパターンを学んだり、普段コーディングを行う中で パターンを発見することは良いコードを書くことに繋がっていく • 普段コードを書く中でパターンの6つの原則を意識するのも効果的
33. ご清聴ありがとうございました
34. Appendix パターンが従う6つの原則
35. 本編で割愛したパターンが従う6つの原則について紹介 Appendix パターンが従う6つの原則 1. 結果の局所化 2. 繰り返しの最小化 3. 対称性 4. ロジックとデータの一体化 5. 宣言型の表現 6. 変更頻度
36. 原則1. 結果の局所化 Appendix パターンが従う6つの原則 • コードの変更の結果が一箇所に留まるようにコードを構成すること • コードの変更が想定外の場所に影響するとその変更コストは劇的に上昇する • 結果の局所化ができているコードであれば、コード全体を把握しなくても段階的に 理解すれば良くなる
37. 原則2. 繰り返しの最小化 Appendix パターンが従う6つの原則 • 同じ目的の下に同じ処理を行うコードは一箇所にまとめて共通化すること • （当たり前だけど）コードが重複していると一つを変更すると他のすべても変更しな ければいけなくなる ◦ 重複したコードの分だけ変更コストは増大する • ただし、必ずしも重複を排除すれば良いのではなく、目的が異なれば同じ処理で あってもコードは共通化しない方が良い ◦ 参考「クソコード動画『カプセル化 Mk-II』で考える、上手くカプセル化できない理由 ミノ駆動 @MinoDriven #ooc_2024」
38. 原則3. 対称性 Appendix パターンが従う6つの原則 • 対称性を意識するとコードは劇的に読みやすくなる • コードの粒度や行える操作を対称的にする ◦ クラス内のプロパティの生存期間を同一にする ◦ あるメソッドのグループがあれば全て同じ引数を取るようにする ◦ 長い処理のメソッドを均一の粒度に分割する ◦ etc…
39. 原則4. ロジックとデータの一体化 Appendix パターンが従う6つの原則 • ロジックとそのロジックが操作するデータは近くに置くこと • 結果の局所化を順守すると必然的にロジックとデータは一体化する • 関連するロジックとデータは同じタイミングで変更することが多くなる ◦ これらが同じ場所にあれば変更の結果も局所化が保たれる • ただし、ロジックとデータをどこに置くべきかは最初から明確ではない場合がある ◦ コードに対する継続的な責務の見直しは大事だなというのが個人的な所感
40. 原則5. 宣言型の表現 Appendix パターンが従う6つの原則 • 実装の詳細を書くよりこの処理が何をするかという意図を宣言する ◦ JavaScriptを例にすると、for文よりforEachメソッド ◦ Javaを例にすると、for文よりStream • 命令型のプログラミングは制御とデータのフローを頭の中でイメージしながら読む 必要がある • 宣言型で表現されていれば読み手の認知負荷を大幅に抑えられる
41. 原則6. 変更頻度 Appendix パターンが従う6つの原則 • 変更されるタイミングが異なるロジックやデータは分けておく • 変更されるタイミングが同じロジックやデータは同じ場所に置いておく • クラス内のプロパティはなるべく一緒のタイミングで変更されるべき ◦ あるメソッドの実行中にだけ変更されるプロパティは、プロパティにせずローカル変数にすべき • 税額計算のソフトウェアを例にすると... ◦ 一般的な計算ロジックのコードと、年ごとに固有なコードは一緒にせず分けておく