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

Slide 1

Slide 1 text

ケント・ベックに学ぶ『良いコード』の書き方 2024.08.17 Kansai Dev Garage しがあきとし

Slide 2

Slide 2 text

自己紹介　 ● なまえ ○ しがあきとし(@akitoshiga) ● 普段何してる？ ○ 医療系HR企業のWebエンジニア ○ 主にRuby on Railsアプリの開発 ● 好きなプログラマー ○ ロバート・C・マーティン ○ ケント・ベック

Slide 3

Slide 3 text

目次　 1. ケント・ベックについて 2. ケント・ベックの『良いコード』 3. パターン 4. パターンの具体例 5. まとめ

Slide 4

Slide 4 text

1. ケント・ベックについて

Slide 5

Slide 5 text

ケントベックとは 1. ケント・ベックについて ● プログラマー ● アジャイル開発におけるエクストリーム・プログラミング(XP)の考案者 ● テスト駆動開発(TDD)の第一人者としても有名 ● 代表的な著書 ○ 「エクストリームプログラミング」 ○ 「テスト駆動開発」

Slide 6

Slide 6 text

なぜケント・ベックから学ぶのか？

Slide 7

Slide 7 text

ケント・ベックの『良いコード』に対する熱量がすごい 1. ケント・ベックについて『 70年の人生は、20億秒を少し超えるに過ぎない。誇りの持てない仕事で無駄にする時間はない。良いコードを書くこと自体が喜びであり、そのコードを他の人が理解し、評価し、使用し、拡張してくれればさらに喜びは増す。』ケント・ベック「実装パターン」より引用

Slide 8

Slide 8 text

ケントベックの凄いところ 1. ケント・ベックについて ● 職業人生を捧げるほどの『良いコード』に対する熱量 ● コーディングに対する深い洞察 ● 後述する『パターン』を用いてコーディングにおける個々の課題とその解決方法を抽象化して再利用可能にするアプローチを推進した

Slide 9

Slide 9 text

2. ケント・ベックの『良いコード』

Slide 10

Slide 10 text

ケント・ベックの考える『良いコード』とは？ 2. ケント・ベックの『良いコード』『 70年の人生は、20億秒を少し超えるに過ぎない。誇りの持てない仕事で無駄にする時間はない。良いコードを書くこと自体が喜びであり、そのコードを他の人が理解し、評価し、使用し、拡張してくれればさらに喜びは増す。』ケント・ベック「実装パターン」より引用

Slide 11

Slide 11 text

コミュニケーション・シンプル・柔軟性

Slide 12

Slide 12 text

コミュニケーション・シンプル・柔軟性 2. ケント・ベックの『良いコード』『卓越したプログラミングにおいて必要とされる価値は、コミュニケーション、シンプル、柔軟性である。これらの価値は互いに衝突するときもあるが、補完し合うことの方が多い、拡張方法が数多く存在し、余分な要素が存在せず、読みやすく、理解しやすいのが最高のプログラムだ。』ケント・ベック「実装パターン」より引用

Slide 13

Slide 13 text

コミュニケーション 2. ケント・ベックの『良いコード』 ● 読み手が理解できるコード ● 実装意図を正しく伝えらえるコード ● 人間とコミュニケーションができるコードは保守のコストを大きく減らすことができる ○ コードは書いた時間より読まれる時間の方が長い ● ケント・ベックは開発をコードと人間のコミュニケーションと捉えた

Slide 14

Slide 14 text

シンプル 2. ケント・ベックの『良いコード』 ● 『余分な複雑性』のないコード ● 『余分な複雑性』とは ○ 動作に影響のないコード ○ 一生懸命動かそうとした痕跡のあるコード ○ メンテナンス（リファクタ）されていないコード ● 複雑なコード全てが悪というわけではない ○ 解決すべき問題が複雑な場合はその複雑さが反映される →『本質的な複雑さ』 ○ プログラミングには複雑さの玉と石を分ける作業が必要 ● 何をシンプルとするかは個人による所がある ○ ベテランにとってのシンプルは、初心者には難しすぎることも ○ 読み手を意識した時に良いプログラムは生まれる

Slide 15

Slide 15 text

柔軟性 2. ケント・ベックの『良いコード』 ● 変更を容易に行えるコード ● 柔軟性は非効率なコードや設計を正当化するために悪用されがちなので注意 ○ プログラムが柔軟であるべきなのは、プログラムがその方向に変更される場合だけ ○ 明日必要と思われた柔軟性すら必要とされない場合が多い ● 凝った設計から得られる柔軟性よりも、シンプルと包括的なテストから得られる柔軟性の方が効果的 ● 「YAGNI」・「KISS」の原則を尊重する ○ YAGNI →「You Ain’t Gonna Need It」 ○ KISS →「Keep It Simple, Stupid」

Slide 16

Slide 16 text

これらの要素にケント・ベックはどうアプローチしたのか？

Slide 17

Slide 17 text

3. パターン

Slide 18

Slide 18 text

パターンについて 3. パターン ● ソフトウェア設計上の課題とその有効な解決策を再利用可能なように一般化したもの ○ 例 GoFのデザインパターン ● ケント・ベックはこのパターンの先駆け ○ 1987年のOOPSLAで「Using Pattern Languages for Object-Oriented Programs」を発表 ● ケント・ベックはパターンを用いて『良いコード』を書くことを推進した

Slide 19

Slide 19 text

ケント・ベックの用いるパターンの特徴 3. パターン ● 粒度が細かく幅広い ○ ケント・ベックは多くのパターンを組み合わせてプログラミングをした ○ クラスやメソッドの命名までにもパターンの考え方を取り入れている ● どのパターンも必ずコミュニケーション・シンプル・柔軟性のいずれかの価値を反映している ● どのパターンも以下の6つの原則に従っている 1. 結果の局所化 2. 繰り返しの最小化 3. 対称性 4. ロジックとデータの一体化 5. 宣言型の表現 6. 変更頻度

Slide 20

Slide 20 text

4. パターンの具体例

Slide 21

Slide 21 text

注意 4. パターンの具体例 ● 以降のパターンは全てRubyで書いています ● Rubyに馴染みがない人向けに一般的なイディオムからは外れた書き方をしている部分があります

Slide 22

Slide 22 text

パターン1. Composed Method

Slide 23

Slide 23 text

パターン1. Composed Method 4. パターンの具体例 Before After

Slide 24

Slide 24 text

パターン1. Composed Method 4. パターンの具体例 ● プログラムを一つの事のみにするメソッドに分割する ● メソッド内部のメッセージは同じ抽象度になるようにする ● メソッド内部の対称性が保たれ、かつ宣言型で意図が表現されるため読みやすく、意図が伝わりやすくなる ● Beforeではメソッドの処理を追わなければならないが、Afterではメソッドの呼び出しを見るだけで何をやっているかわかるようになる

Slide 25

Slide 25 text

パターン2. Double Dispatch

Slide 26

Slide 26 text

パターン2. Double Dispatch 4. パターンの具体例 Before After

Slide 27

Slide 27 text

2. Double Dispatch 4. パターンの具体例 ● オブジェクト指向的なパターン ● 異なる2つの関心事の変更頻度を分割 ● 多態性を用いて冗長な『余分な複雑性』の排除

Slide 28

Slide 28 text

パターン3. Method Object

Slide 29

Slide 29 text

パターン3. Method Object 4. パターンの具体例 Before After

Slide 30

Slide 30 text

パターン3. Method Object 4. パターンの具体例 ● Composed Methodでも単純化できないほどメソッドが大きい場合は、そのメソッド自体をオブジェクトにしてしまう ● 関連するデータをプロパティとして持つことでロジックとデータを一体化する ● 多くの引数を持つ場合は、メソッドから引数がなくなることで可読性も向上する ● Composed Methodと組み合わせて使うことでより明確でシンプルなコードになる

Slide 31

Slide 31 text

5. まとめ

Slide 32

Slide 32 text

まとめ 5. まとめ ● ケント・ベックの考える『良いコード』はコミュニケーション・シンプル・柔軟性から成り立つ ● パターンを積極的に再利用し、効率的で的確なコーディングを行っている ● ケントベックのパターンは6つの原則に従っている ○ 結果の局所化・繰り返しの最小化・対称性 ○ ロジックとデータの一体化・宣言型の表現・変更頻度 ● 本日紹介したパターンやその他のパターンを学んだり、普段コーディングを行う中でパターンを発見することは良いコードを書くことに繋がっていく ● 普段コードを書く中でパターンの6つの原則を意識するのも効果的

Slide 33

Slide 33 text

ご清聴ありがとうございました

Slide 34

Slide 34 text

Appendix パターンが従う6つの原則

Slide 35

Slide 35 text

本編で割愛したパターンが従う6つの原則について紹介 Appendix パターンが従う6つの原則 1. 結果の局所化 2. 繰り返しの最小化 3. 対称性 4. ロジックとデータの一体化 5. 宣言型の表現 6. 変更頻度

Slide 36

Slide 36 text

原則1. 結果の局所化 Appendix パターンが従う6つの原則 ● コードの変更の結果が一箇所に留まるようにコードを構成すること ● コードの変更が想定外の場所に影響するとその変更コストは劇的に上昇する ● 結果の局所化ができているコードであれば、コード全体を把握しなくても段階的に理解すれば良くなる

Slide 37

Slide 37 text

原則2. 繰り返しの最小化 Appendix パターンが従う6つの原則 ● 同じ目的の下に同じ処理を行うコードは一箇所にまとめて共通化すること ● （当たり前だけど）コードが重複していると一つを変更すると他のすべても変更しなければいけなくなる ○ 重複したコードの分だけ変更コストは増大する ● ただし、必ずしも重複を排除すれば良いのではなく、目的が異なれば同じ処理であってもコードは共通化しない方が良い ○ 参考「クソコード動画『カプセル化 Mk-II』で考える、上手くカプセル化できない理由ミノ駆動 @MinoDriven #ooc_2024」

Slide 38

Slide 38 text

原則3. 対称性 Appendix パターンが従う6つの原則 ● 対称性を意識するとコードは劇的に読みやすくなる ● コードの粒度や行える操作を対称的にする ○ クラス内のプロパティの生存期間を同一にする ○ あるメソッドのグループがあれば全て同じ引数を取るようにする ○ 長い処理のメソッドを均一の粒度に分割する ○ etc…

Slide 39

Slide 39 text

原則4. ロジックとデータの一体化 Appendix パターンが従う6つの原則 ● ロジックとそのロジックが操作するデータは近くに置くこと ● 結果の局所化を順守すると必然的にロジックとデータは一体化する ● 関連するロジックとデータは同じタイミングで変更することが多くなる ○ これらが同じ場所にあれば変更の結果も局所化が保たれる ● ただし、ロジックとデータをどこに置くべきかは最初から明確ではない場合がある ○ コードに対する継続的な責務の見直しは大事だなというのが個人的な所感

Slide 40

Slide 40 text

原則5. 宣言型の表現 Appendix パターンが従う6つの原則 ● 実装の詳細を書くよりこの処理が何をするかという意図を宣言する ○ JavaScriptを例にすると、for文よりforEachメソッド ○ Javaを例にすると、for文よりStream ● 命令型のプログラミングは制御とデータのフローを頭の中でイメージしながら読む必要がある ● 宣言型で表現されていれば読み手の認知負荷を大幅に抑えられる

Slide 41

Slide 41 text

原則6. 変更頻度 Appendix パターンが従う6つの原則 ● 変更されるタイミングが異なるロジックやデータは分けておく ● 変更されるタイミングが同じロジックやデータは同じ場所に置いておく ● クラス内のプロパティはなるべく一緒のタイミングで変更されるべき ○ あるメソッドの実行中にだけ変更されるプロパティは、プロパティにせずローカル変数にすべき ● 税額計算のソフトウェアを例にすると... ○ 一般的な計算ロジックのコードと、年ごとに固有なコードは一緒にせず分けておく