Tidy First? 読書メモ
だっしーはじめにに、「私の目標は、読者が午前中に本書を読み始めたら、午後には設計が上達していることだ」とある。確かに薄い本なので、読みながら読書メモを取っても2−3時間で読み終わりそうである。
だっしーいつ設計するのか？
機能追加に必要な範囲だけか、それとも先々のことまで考えるか。
本書における回答は「その中間」、もはや回答してないに近しい。
でも「Design It!」の回答もそのようなものだったことを思い出した。
だっしー5章「読む順番」
読み手がほしい順に配置せよということ。
当たり前じゃんという話だが私にとっては「そうそれ！」だった。
先日後輩にこのことを伝えたかったのだが、具体的なコードAとBとを比べて長ったらしく説明しないといけなかった。僕の語彙が無かった。
だっしー15章「冗長なコメントを削除する」
「コードに書いてあることをそのまま書いてあるコメントがあったら、消そう」。
その通り過ぎてなんともだが、特に生成AI絡みだとたくさん見るよねそういうコメント。
やや複雑気味なメソッドチェーンにはコメント欲しいんだがその辺の塩梅はいまだに境界がない。
だっしー多少普段考えてることの復習にはなったが、第一部の内容までは薄い「リーダブルコード」でしかない。
第二部に期待。
だっしー16章「分けて整頓する」
耳が痛いことが早速書いてあった。
レビューのレイテンシとPRのサイズは相互作用を持つ。
素早くレビューされると小さなPRがばんばん出てくるが、遅くなるとPRのサイズは膨らんでいく。
整頓と変更のPRを分けるというのは確かにと思える。
だっしー19章「リズム」
1回の整頓にかけるべき時間は長くとも1時間程度とすべし。
パレートの法則、頻繁に変更されるコードは全体の2割。であれば整頓も同じく2割に集中する。結果として、酷いコードは徐々に整頓されていってやがて整頓の時間は落ち着く。
だっしー21章
この本を読んで知るべき最も大きい所がここだった。
整頓するかしないか。要するにコストがペイするかどうかの軸を持てということ。
整頓したい項目に気付いてやらない時は「お楽しみリスト行き」にする。
だっしー26章「オプション」
ソフトウェアの変更容易性を上げろ、というのが単に「開発者体験」なんていう労働者の福利厚生ではなく、ソフトウェアから受け取れる経済効果、つまりソフトウェアの価値をあげる事に繋がることを論じている。
だんだんとソフトウェア設計論から外れてくる気がするし、どこかボブおじ味がする。
ただ、言いたい事は分かるし価値もある。
だっしー28章
可逆か、不可逆か。
普段あまり意識していないが、確かに可逆なものは特に注意を払わずに変更してよいケースが多そう。
整頓が細かいPRに分かれているメリットも関連しそう。
だっしー読み終えた。いい本だったし、次に繋がるアクションを考えるきっかけになった。
技術的なテクニックは控えめだし、そっちが欲しければ「リーダブルコード」で良い。
ある程度の業務経験があるプログラマの「いつどのくらい整頓するんだ？」という問いを、時間を掛けて丁寧に論理的に回答しているというものだった。