改めて問う「それ、何のため？」

Transcript

1. 改めて問おう ? 「それ、何のため？」 プログラミングによるモノづくりで、本質的に大切なこと 参考：上田勲『プリンシプル オブ プログラミング』
2. 原則やテクニック、たくさんありますよね 『プリンシプル オブ プログラミング』だけでも 101 個 DRY KISS YAGNI SOLID 名前重要 高凝集・低結合 直交性 早すぎる最適化は悪 防御的プログラミング 7つの設計原理 UNIX哲学 コードは設計書 覚えた。守っている。……でも、それは何のため？ 改めて問おう「それ、何のため？」 2
3. 前提① コードは、書かれるより読まれる 10 : 1 読む時間 ： 書く時間 Robert C. Martin『Clean Code』での見積もり 書くコストより、読むコストの方が圧倒的に多い レビュー・バグ調査・機能追加・引き継ぎ…… コードは何度も「入力」される。 書くコスト1回に対して、読むコストは複数回 だから、最適化すべきは「書きやすさ」ではなく 「読みやすさ」 『プリンシプル オブ プログラミング』の前提 「コードは必ず読まれる」「コードは設計書」 ——読み手を想定して書く。 改めて問おう「それ、何のため？」 3
4. 前提② 読むコードのほとんどは「他人由来」 プロダクトは一人では作れない チームメイトのコード ライブラリ・OSS・フレーム ワーク 半年前の自分のコード 同じリポジトリの別モジュール、 レビュー依頼、ペア作業 Spring の内部、標準ライブラリ、 依存パッケージ 文脈を忘れた自分は、もはや他人 つまり開発とは、他人由来の情報を「入力」して、プロダクトを「出力」する営み 改めて問おう「それ、何のため？」 4
5. 主張 原則やテクニックは、すべて “他人“由来の情報の「取得」を スムーズにするためにある コードに関する情報 原則・テクニック プロダクト コード・設計・意図 認知負荷を下げる装置 速く・正しく・変えられる 読み手の認知負荷が下がる → 理解が速く正確になる → プロダクトを速く正しく育てられる
6. 検証：DRY を「読み手の入力」で見直す Don't Repeat Yourself ―― 重複を排除せよ 重複があると、読み手は…… 同じロジックを 2 回読む（入力量が 2 倍） 「微妙に違う？」と差分を目で比較する どちらが正なのか、履歴を掘って確かめる 修正時に「もう1か所」を見落とす不安を抱 える DRY にすると、読み手は…… 1 か所読めば済む（入力量が最小） 関数名・クラス名から意図を先に受け取れ る 「これが唯一の正」と信じて読み進められ る 変更の影響範囲を 1 か所で判断できる DRY の価値は「行数が減る」ことではなく、読み手が処理する情報量と迷いが減ること 改めて問おう「それ、何のため？」 6
7. 同じレンズで、ほかの原則も見てみる どれも「読み手が受け取る情報」を軽くしている 原則 ふつうの説明 読み手の「入力」に与える効果 KISS シンプルに保つ 読み手に要求する前提知識・追跡手順を減らす 名前重要 良い名前を付ける 中身を読まなくても、名前だけで意図が入力される 高凝集・低結合 関心を集め、依存を減らす 読むべき範囲が局所化され、他所を開かずに済む YAGNI 今必要なものだけ作る 「読まなくていいコード」を最初から存在させない 一貫性・フォーマット スタイルを揃える パターンで予測でき、逐語的に読む必要がなくなる 改めて問おう「それ、何のため？」 7
8. 「何のため？」があれば、衝突しても判断できる 原則はルールではなく、目的のための手段 ケース：似ているだけの 2 つの処理 DRY に従って共通化した しかし仕様が別々に育ち、内部に if 分岐が増 殖 読み手は「どの分岐が自分の話か」を毎回追 う → 行数は減ったのに、入力はむしろ重くな った 改めて問おう「それ、何のため？」 判断の軸 「DRY か、重複か」ではなく 「読み手の入力は軽くなるか？」で決める 偶然似ているだけなら、分けておくほうが読みやす い。 本質的に同じなら、まとめて 1 か所にする。 『プリンシプル オブ プログラミング』の「早すぎ る最適化」「Rule of Three」も同じ根から出てい る。 8
9. まとめ 1 コードは書かれるより読まれる。しかも読むのは“他人“由来のもの。 2 原則・テクニックの目的は、情報の「取得」をスムーズにすること。 3 目的を持てば、原則が衝突したときにも自分で判断できる。 明日からできること コードを書くとき、レビューするとき、原則を持ち出すとき—— 一度だけ問う。「それ、読み手の入力は軽くなる？ 何のため？」
10. 参考文献 上田勲『プリンシプル オブ プログラミング』（秀和システム, 2016） 101 の原則を「前提・原則・思想・視点・習慣・手法・法則」に整理した本書が、本LTの土台 Robert C. Martin『Clean Code』（2008） 「読む時間：書く時間 ＝ 10：1 をはるかに超える」という見積もりの出典 Andrew Hunt / David Thomas『The Pragmatic Programmer』（1999） DRY 原則の初出。「知識の重複」を排除せよ、と定義している ご清聴ありがとうございました 改めて問おう「それ、何のため？」 10