1. 脳に収まる コードの書き方 2024/7/18 株式会社アトラクタ 吉羽龍太郎
2. 吉羽龍太郎 / Ryutaro YOSHIBA / ryuzee ✤ 株式会社アトラクタCTO /アジャイルコーチ / 翻訳者 ✤ Scrum Alliance 認定スクラムトレーナー ✤ X(Twitter): @ryuzee / https://www.ryuzee.com/ 2
4. 株式会社アトラクタについて ✤ 社名：株式会社アトラクタ 英文表記：Attractor Inc. / https://www.attractor.co.jp ✤ 設立：2016年12月 ✤ 所在：東京都港区 ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティング / ドメインモデリングな どが専門領域 4
5. アトラクタのアジャイルコーチングで 持続的に成果を出し続けるアジャイルチームを作る 「あなたのゴールは、他人から押し付けられるアジャイルの行動規範に依存するのではなく、 自分たちで考えることのできる、生産的なアジャイルチームを育てることです」 書籍『アジャイルコーチング』（Rachel Davies、Liz Sedley 著、永瀬美穂、角征典 訳、オーム社、2017） なぜアジャイル開発では「コーチ」なのか 変化に気づき、対応するを養う 顧客志向の目的と行動様式を獲得する コーチの経験と知見の力を借りた素早い立ち上がり
6. ✤ 脳に収まるコードの書き方 ―複雑さを避け持続 可能にするための経験則とテクニック ✤ Mark Seemann（著）、吉羽龍太郎、原田騎郎 （訳）、Robert C. Martin（まえがき） ✤ 2024年6月18日発売 ✤ オライリー・ジャパン ✤ 3,740円 ✤ 電子書籍（PDFとepub）はオライリー・ジャパンの サイトから購入可能 6
7. 共訳者原田による解説もあります https://www.youtube.com/watch?v=sVlfHMPYrTE 7
8. 本書のタイトルは？ 脳に収まるコードの書き方: 複雑さを避け持続可能にする経験則とテクニック Code That Fits in Your Head: 脳に収まるコード: Heuristics for Software Engineering ソフトウェアエンジニアリングのための経験則 8
9. 経験則(Heuristic)とは？ A heuristic (/hjʊˈrɪstɪk/; from Ancient Greek εὑρίσκω (heurískō) 'method of discovery',[1] or heuristic technique (problem solving, mental shortcut, rule of thumb)[2][3][4][5] is any approach to problem solving that employs a pragmatic method that is not fully optimized, perfected, or rationalized, but is nevertheless "good enough" as an approximation or attribute substitution.[ 経験則とは、発見のための手法というギリシャ語を語源とする。 最適化されておらず、完全でもないし、理論的な裏付けがあるわけでもないが、実用上「使える」 やり方のこと https://en.wikipedia.org/wiki/Heuristic 9
10. まえがきから 「彼とはいろいろなところ 意見 合いません。静的型付けと動的型付けについて意見 違いま す。OSや言語についての意見も違います。知的好奇心を刺激するようなたくさんのこと 意見 違います」 Bob Martin が で が が で 10
11. 著者の使ったことのある経験則の集まり ✤ 今までにない方法を新たに生み出したわけではない ✤ ✤ そんなものがあるはずがない 世の中に散らばっているものを著者が試し、日々の仕事に取り 入れ、その経験から有効と判断した経験則をまとめたもの ✤ ✤ 確立した解決策・方法論というわけではない 合意できないことがたくさんあって当たり前 ✤ むしろ良いこと 11
12. 目次 第I部 1章 2章 3章 4章 5章 6章 7章 8章 9章 加速 アートかサイエンスか チェックリスト 複雑さに対処する バーティカルスライス カプセル化 三角測量 分解 API設計 チームワーク 第II部 10章 11章 12章 13章 14章 15章 16章 持続可能性 コードの増大 ユニットテストを編集する トラブルシューティング 関心事の分離 リズム いつもの顔ぶれ ツアー 12
13. サンプルコード git log --oneline --reverse ✤ 書籍全体で1つのサンプルプロジェクト ✤ C#で書かれたWeb API ✤ ✤ UIはない 読者はリポジトリをダウンロードできる ✤ 544コミット ✤ コミットログも参考になるはず 13
14. 「脳に収まるコードを書く」とは？ ✤ 実際のコーディングの瞬間にとどまる話ではない ✤ 個人での作業の進め方 ✤ チームでの作業の進め方 ✤ ツールの使い方 ✤ 時間の使い方 ✤ … ✤ これらも「脳に収まるコードを書く」ために重要な要素 14
15. 脳とコンピューター ✤ 脳はコンピューターと比べると ✤ 計算能力が低い ✤ 記憶は信頼性が低くあてにならない（別の記憶を作り出すことも） ✤ 大事なことを忘れる ✤ 短期記憶できる量はかなり少ない ✤ ✤ 人間の短期記憶は4〜7個のことしか記憶できない 我々はいつでも間違える 15
16. ✤ システム1 ✤ ✤ ほとん もしくはまったく努力せ 、自発的にコントロールしている感覚もなく、自動的にす やく動く。高速だが正確ではない。今持っている情報をもとにストーリーを作ることには長 けているが、持っていない情報は考慮できない。 今持っている情報がすべてで、そこから結論に飛びつく システム2 ✤ 複雑な計算を含む、努力 必要な精神活動に注意を割り当てる。システム2の動作は、主体 性、選択、集中といった主観的な経験と関連している ず が 16 ど ば システム1とシステム2（カーネマンの思考モデル）
17. ✤ プログラミングではシステム1もシステム2も使われる ✤ システム1は常時バックグラウンドで動作し、見ているコードの意味を理解しようとする ✤ ただし、システム1は ✤ ✤ 目に見える情報から結論を見出そうとする ✤ 高速な反面、正確性は劣る そのため、システム1が暴走しないようなコードにしなければいけない ✤ 関連する情報が活性化するようにコードを整理する必要 17
18. コードは徐々に複雑になりがち ✤ それぞれの変更が小さい ✤ 誰も全体の品質に目を配らない ✤ そしてある日問題に気づく ✤ ✤ 誰もが気づくくらいにコードが複雑になったから（メトリクスを見たわけでなく） いわゆる「茹でガエル」 18
19. 複雑さを防ぐ ✤ ソフトウェアは根本的に複雑 ✤ 「ソフトウェア製品開発に関する古典的問題の多くは、その本質的な複雑性と、ソフトウェア の大きさに従ってその複雑性 非線形に増大することに由来している。複雑性ゆえに ロ ラムのす ての状態を理解することはおろか、列挙することも難しくなる」 （フレデリック・ブ ルックス、1986年） ✤ こうなると組織は持続可能ではなくなる ✤ 人間の脳は限られた複雑さしか扱えない ✤ ソフトウェアエンジニアリングは、複雑さが増すのを防ぐ意図的なプロセスである必要 グ プ が べ 19
22. サイクロマティック複雑度 ✤ 分岐とループの命令の数の合計に1を足した値（3項演算子も含む） ✤ サイクロマティック複雑度をしきい値以下に保つ ✤ 継続的インテグレーションに組み込む ✤ リファクタリングや構造の見直しの指針にする 22
23. 本書で繰り返される主張 「1つのコー のなか ✤ 7を超えることをしてはいけない」 さきほどのコードはこれ以上複雑にはできない で 23 ド ✤
25. ヘックスフラワーとフラクタルアーキテクチャー 25
26. ケント・ベック曰く 「ソフトウェア設計の ールは、人の心に収められるかたまりやスライスを作ること 。ソフトウェ ア 大きくなり続け、人の心に入らなくなっても変更を続けたいなら、別のやり方 かたまりを分 け、スライスを切り分け続けなけれ いけない」 （ケント・ベック） だ で ば ゴ が 26
27. 「オ ェクトの根本的な品質は契約にあります。通常は、基礎となる実装よりも単純 す。 した って脳に収まりやすいの す」 で で ジ 27 ブ が 契約による設計
28. 重要なのは、オ ェクト 決して無効な状態にならないことを保証す き ということ す。 こ れは呼 出し側の責任 はありません。オ ェクト自身 「有効」 何を意味するのか、それを う保証するのかをいち ん知っているから す」 で ど で ゲ だ べ プ が ば が で プ ジ で ド ブ で だ グ が プ ば が で グ が プ ジ ブ グ プ び ジ 28 ブ ど 「オ ェクト指向 ロ ラミン のなか 、カ セル化はいち ん誤解されている概念の1つ す。多くの ロ ラマー 、クラスのフィール を直接公開することを禁止し、 ッターとセッ ター のうしろに隠すこと 「カ セル化」 と思い込ん います。これはカ セル化とはほとん 関係 ありません。
29. ほかにも複雑さを調べる経験則はある ✤ コードの行数（複雑さのいちばん単純な予測因子） ✤ 変数の数（ローカル変数、メソッ 引数、 クラスフィール なども含む） ド ド 29
30. 「しかし、残念な らソフトウェア開発者 1人 仕事をすることはめったにありません。 他の ロ ラマー、 ロ クトオーナー、マネー ャー、運用ス シャリスト、 イナーな と一 緒にソフトウェア開発チーム 仕事します。これは1.3.4 議論した「実際の」エン ニアたちも同 、チーム 働きます」 ど ジ ザ デ ペ で ジ で が で ダ プ が で グ プ 30 で じ チームで働く
31. チームワーク ✤ ✤ チームにはプロセスがあり、メンバーはそれに従う ✤ プロセスとは仕事の進め方やルールのこと ✤ プロセスの背景にある意図を理解しておく必要がある そのプロセスを使って ✤ 自分やチームメイトがコードをもっとすばやく理解できるようにする ✤ コードをチームの他のメンバーの脳にも収まりやすくする 31
32. 本書で繰り返される主張 ✤ 「コードは書く回数より読む回数のほうが多い」 ✤ 「可読性のために最適化せよ」 32
33. 可読性のために使える経験則とテクニック ✤ コードを80x24の幅に収める ✤ コメントよりもわかりやすい名前のコードを ✤ 名前を「X」 置き換えても何をしているのかを想像できるか？ ✤ コマンドクエリ分離（副作用のあるメソッ は、 ✤ メソッ 名 ータを返さない） 伝えられることはコメントに書くな。型 伝えられることをメソッ 名に書くな ド で デ ド で で ド 33
34. 「コン ューター 理解 きるコー は馬鹿 も書ける コー を書く」 （マーティン・ファウラー） 、良い ロ ラマーは人 理解 きる で が グ プ が で ド で が ピ ド 34
35. 読み手を導くのに重要な順に並べると？ 1. APIに明確な型を与えること 2. メソッ にわかりやすい名前をつけること 3. 良いコメントを書くこと 4. 自動テストとしてわかりやすい例を提供すること 5. Git わかりやすいコミットメッセー を書くこと 6. わかりやすい キュメントを書くこと ジ ド ド で 35
36. チームでGitを適切に使う（コミットメッセージ） ✤ 自分 ✤ とはいえ、書くだけではダメで、それがコミュニケーションに役立たないといけない ✤ 書いて保存するものは、す て将来の自分とチームメン ーに対するメッセー 「更新」「updated」「もう一度」「いったんコミット」……どれもひどい ✤ コミット 何 変わったのかを説明するのに多くの時間を使う必要はない（差分からわかる） ✤ コミットメッセー はな 最適 ✤ 50/72ルール その変更をしたのか、な その形になっているのかを説明するのに ジ バ ぜ べ ぜ ジ が で が 36
37. 50/72ルール ✤ サマリーを現在形 50文字以内 書く ✤ それ以上のテキストを書く場合は、2行めを空行にする ✤ 好きな けテキストを追加してよい ✤ git log --oneline ✤ サマリーが見出しになってリポジトリのなかを移動しやすくなる ✤ できるかぎり適切な文章を書く（言語の文法に従う） 、幅 72文字以内になるようにフォーマットする ✤ タイポのせいで情報が見つからなくなる ✤ 雑な文章のせいで誤解したり、理解が遅れたりする が が で で だ 37
38. 継続的インテグレーション ✤ CIサーバがあるだけでは継続的インテグレーションをしていることにはならない ✤ 重要なのは「自分のコードを他の人に頻繁に共有すること」 ✤ 根本にある問題は「並列性」 ✤ ✤ コー を編集するのに使う時間を短くすれ て誰か 変更を加える可能性は下 る するほ 、同時に同 コー の同 場所に対し 小さな変更にして、できるだけ頻繁にマージする ✤ 経験則では最長でも4時間ごと ✤ 4時間で完成できないならフィーチャーフラグを使って機能を隠す じ ド じ ど ば が が ド 38
39. マイクロコミット ✤ 小さなコミットにする ✤ そうすればミスしても痛くない ✤ 雑なコミットをすると、コードの履歴が操作できなくなる ✤ 大きなコミットのなかから不要な部分を取り除くのが難しくなる ✤ コミット履歴は、動作するソフトウェアのスナッ ショットの連続 ある ✤ コードが正しくない時間をなるべく短く保つ き べ で プ 39
40. コードレビュー ✤ 「自分はこれのメンテナンスを問題なく行えるか?」 ✤ レビューアーは自分のペースでコードを読むべき ✤ 対象のコードをコードの作者以外が説明してみるのが有効 40
41. チェン セットを拒否する 「支援の最初のころ、数週間音沙汰のなかったリモート開発者から ルリクエストを受け ました。 巨大な ルリクエスト した。レ ューするコー は50以上のファイルにわたって おり、数千行 ありました。 私はそれをレ ューしません した。大きす るという理由 す にそれを拒否したの す。」 で プ ぐ で ド ぎ ビ で で プ ビ ジ 41
42. ペアプログラミング・モブプログラミング ✤ 参加メンバーの脳に収まったコードを継続的に開発する ✤ 新しく見た大きなコードを脳に収めようとする労力を減らせる 42
43. 本書で紹介している主なプラクティスや経験則 ✤ 50/72ルール ✤ フィーチャーフラグ ✤ セマンティック ー ョニン ✤ 80/24ルール ✤ 関数型コア・命令型シェル ✤ ✤ Arrange-Act-Assert ✤ コミュニケーション階層 テストと ロ クションコー を別々にリファクタリン する ルールの例外を正当化する ✤ スライス 検証せずにパースする ✤ ストラングラー ポステルの法則 ✤ 脅威モデル レッド/グリーン/リファクタリン グ ✤ 変換の優先順位 ✤ X駆動開発 横断的関心事のためのデコ レーター ✤ 依存関係を定期的に更新する ✤ 名前をXで置き換える ✤ 欠陥をテストとして再現する 悪魔の代弁者 ✤ コードをレビューする ✤ ✤ ✤ ✤ ✤ ✤ ✤ 二分法 ✤ チェックリスト ✤ コマンドクエリ分離 変数を数える ✤ ✤ サイクロマティック複雑度 グ ド グ ジ バ ダ プ 43
44. おすすめの読み方 ✤ とりあえず全体を流し読みする ✤ 本書はコレクションなので、さらに詳しいことを知りたい場合はトピックごとの本を探す ✤ C#や他の言語で実装する ✤ チームで読書会をする ✤ 使えそうな経験則があったらチームで試す ✤ 自分たちのコードがどうなっているかを議論する ✤ 付属のリポジトリを味わう 44
