『Tidy First?』を読んだ を書いた (#230)

Author: kyu08

content/posts/tidy-first/index.md

@@ -0,0 +1,136 @@
+---
+title: "『Tidy First?』を読んだ"
+tags: ["読書ログ", "設計"]
+
+cover: "https://blog.kyu08.com/cover.png"
+description: ""
+date: 2025-10-04T17:21:10+09:00
+author: "kyu08"
+authorTwitter: "kyu08_"
+draft: false
+showFullContent: false
+readingTime: true
+hideComments: false
+color: ""
+---
+
+『[Tidy First?](https://www.oreilly.co.jp/books/9784814400911/)』を読んだ。
+
+勉強になったところをまとめる。
+
+## 「整頓」という概念
+> 整頓はリファクタリングのサブセットだ。整頓は可愛くてふわふわした小さなリファクタリングなので、誰も嫌いになれないはずだ。
+
+リファクタリングほど大掛かりなものではなく、数十分でできるような小さな改善を本書では「整頓」と呼んでいる。
+
+具体的にはコードコメントを追加したり適切な位置に空行を配置したり適切な変数名に変更したりすることなどを指している。
+
+この「整頓」という概念を知ることができたのが本書を読んで得られた最大の収穫だった。今までそのような行為に名前をつけたことがなかったが名前をつけることで使い所や意義が明確になり意識的に実践できるようになりそう。
+
+なお本書では「整頓」と「振る舞いの変更」の順番やタイミング、粒度や意義について様々な角度から書かれているので気になる方はぜひ手にとってみてほしい。
+
+## 第11章 ステートメントを小分けにする
+> 大きなコードのチャンクを読んでいると、「ああ、ここは**これ**をしていて、あそこで**あれ**をしているのか」とわかる。そのあいだに空行を入れよう。
+
+長めの関数を読むとき、空行がまったくないことは少ないが空行の位置を改善できそうだと感じることがたまにある。
+
+処理の塊ごとに適切に改行されているだけでそこそこ可読性が上がる実感があるのでやってみようと思う。（空行の追加/削除のみのPRであればレビュワーの負担もかなり少ないはず）
+
+## 第13章 ひとかたまり
+> 細かく分割されているがゆえに、かえって理解を妨げているようなコードに出会うことはないだろうか。
+
+超巨大な関数はテストしづらく可読性も低いので避けたいが、逆にすべての処理を関数として切り出してしまうと毎回定義ジャンプしないと処理の内容がわからないのでかえって読みづらくなってしまう。
+
+テストが書きやすい程度に細かくかつ可読性が落ちない程度には大きく関数を切り出すのがよさそうで、いい塩梅を探るには複数のパターンを実際に書いてみて読みやすいかどうかを判断するのがよさそう。（実際に複数パターンを書いてみると意外とすぐに書けることが多いし、しかも実際に書いてみると事前の想定とは印象が違うことが多いように思う）
+
+> 小さな部品に分けようとするのは、コードを少しずつ理解できるようにしたいからだ。だが、ときには、このプロセスが間違った方向に進むことがある。小さな部品のやりとりの仕方によっては、コードが**理解しにくくなる**のだ。明確さを取り戻すには、まずはコードを1箇所に集めて、それから改めて、簡単に理解できる部品を抽出する。
+
+1000行の関数でこれをやるとさすがに辛そうだが、100行前後くらいであればひとまず1つにまとめてから再構成するのはたしかに良さそう。
+
+## 第14章 説明コメント
+> コードを読んでいて「なるほど、それで**こう**なっているのか」と声が出ることがある。これは貴重な瞬間だ。記録しよう。
+
+コードリーディングの結果、必要なコメントが欠けていることに気づくことがある。
+
+そういった場面でこれまであまりPRを作ったりはしてこなかったが、説明コメントの追加も立派な整頓であり将来の読者（当然将来の自分を含む）の時間を節約することに繋がるのでやっていきたい。
+
+説明コメントの追加PRはレビュワーの負荷が少ない割にレビュイーとレビュワーのコード理解を深められる点で比較的コスパの良い取り組みな気がした。（正確な説明コメントを書くための調査が大変、とかはあるかもだが）
+
+## 第19章 リズム
+1つの整頓にかける時間はここでは1時間くらいまでが許容範囲とされており、それを大幅に超過するようであれば変更の単位が大きすぎる兆候らしい。
+
+> こんな話を聞いたことはないだろうか。ある大学がたくさんの建物を造った。計画者は、それを結ぶ歩道をどこに造るか考えていた。だが、そこで経験にもとづいて注意深く推測するのではなく、建物のあいだのエリアに芝生を植えたのだ。
+> 数か月後、学生の歩いた跡によって芝生に道ができた。計画者は芝生がなくなったところを舗装した。
+> 
+> コードにおいて、振る舞いの変更は一部に集中する傾向にある。パレートの法則にあるように、80%の変更は20%のファイルで起こる。
+
+（計画者天才すぎワロタ...）
+
+変更の前に整頓することを続けていくと頻繁に変更される20%のコードがどんどん綺麗になっていく、ということを言っているのだと解釈した。
+
+そうした取り組みを続けていくとコードの大部分は手直ししてないにもかかわらず整頓していないコードに出会うことは稀になる。逆に言うと仮にコードの50%を頑張って綺麗にしたところで、その50%に変更がまったく入らないのであれば投資対効果が高いとはいえないかもしれない。（当然、コード全体が複雑に絡み合っていて一部だけ再設計することが難しい場合や全体的に変更しないと一貫性がなくなる場合などはその限りではないと思う）
+
+なのでコードを修正する際は単純にある時点のコードベースだけを見てコード品質に改善点が見つかったというだけの理由で修正する、というよりは修正すべき合理的な理由（e.g. 内部品質が課題で問題が起きている、よく変更が入る箇所が変更しづらくなっているなど）がある箇所から対応していくのがよさそう。
+
+## 第21章 先に整頓、あとに整頓、改めて整頓、整頓しない
+整頓を変更の前にやるか、あとにやるか、将来時間がとれたときにやるか、あるいはまったくやらないかについて論じた章。
+
+章のまとめにもあるように結局はビジネスにとって合理的なタイミングでやるのがよい、ということなのだと思った。（言葉にするとそれはそうという感じではあるが）
+
+「改めて整頓する」と「あとに整頓する」の区別はあまり考えたことがなかったが、整頓が完了するまでの必要工数が
+大きいケース以外は「あとに整頓する」に寄せるのが良さそうに感じた。
+
+## 第25章 明日の1ドルより今日の1ドル
+> お金を生む振る舞いの変更を今すぐ実装して、あとから整頓できるなら、すぐにお金が手に入り、あとでお金を使うことになる(前述のとおり、ときには先に整頓してから振る舞いを変更するほうが整頓せずに変更するよりも安価なこともある。そんな場合は常に先に整頓する)。
+
+ビジネス的なメリットがあるならば整頓を後回しにすることが合理的になるのは十分にありえる。(e.g. 12/1までにリリースできれば大企業A社の受注に繋がるが、それを超過してしまうと競合他社と契約されてしまい、A社と契約できるチャンスが消滅してしまう)
+
+逆に、先に整頓したほうが変更が楽になるならそうする。コードベースへの理解、ビジネスへの関心と理解（デッドラインは最終的なものなのか、調整可能なのか）、一定の設計スキルなどがあるとこの判断の練度を上げることに繋がりそう。
+<!-- 逆に、先に整頓したほうが変更が楽になるならそうする。じゃあメリデメを整理していい感じに判断すればいいじゃん、という話になるがこの判断を正確にするためにはコードベースへの理解、ビジネスへの関心と理解（デッドラインは最終的なものなのか、調整可能なのか）、一定の設計スキルなどが必要そう。 -->
+
+## 第26章 オプション
+> 「次にどのような振る舞いを実装できるか」は、実装する前から、それ自体に価値がある。
+
+これはあまり考えたことがなかった。「プログラムの変更容易性は将来の実装工数を削減するために重要である」というアイディアと本質的には近いことを言ってそうだが、「価値」という切り口で捉え直すとたしかに変更容易性は価値と等価ともいえそう。
+
+> （これが最重要なのだが）価値予測の不確実性が**高い**ほど、オプションの価値は**高い**（今すぐ実装するのと比べて）。
+
+価値予測の不確実性と変更容易性の価値についてもあまり考えたことがなかったが納得感があった。たとえばよくあるSaaSモデルのプロダクトであれば探索しながら市場の反応を見たり変化に対応したりすることが必要で、そのためには変更容易性が必要なのでその価値がより高まる、ということだと理解した。
+
+## 第32章 凝集
+凝集性が低いモジュールの改善方法についての章だが、どちらかというと章の後半に書かれていた下記の記述が参考になった。
+
+> 次の人のために少しだけコードを整頓しておこう。全員がこのボーイスカウトルール(「来たときよりも美しく」)に従えば、そのうちにより扱いやすいコードになっていくだろう。
+
+これまではボーイスカウトルールというと「触ったコードの負債をできるだけ**リファクタリングして綺麗にすべし**」のような考え方だと認識していた（これ自体は間違いではないと思う）。
+
+本格的なリファクタリングまではいかなくとも、本書で「整頓」として紹介されている「コードコメントの追加」や「空行の調整」なども十分ボーイスカウト的な行為なのだなと考え直して少しハードルが下がる感覚を得た。
+
+## 第33章 結論
+本書のタイトルにもなっている、どんなときに先に整頓すべきかについてのまとめの章。
+
+以下の4つの観点で整理して決断するとよい、と書かれている。次に判断に迷った際には参考にしてみたい。
+
+- コスト
+- 収益
+- 結合
+- 凝集
+
+<!-- > だが、いちばん重要なのはあなただ。整頓はあなたのプログラミングに平穏と満足、喜びをもたらしてくれるだろうか? 多少はありそうだ。これは重要だ。なぜなら、あなたが最高の自分でいれば、より良いプログラマーでいられるからだ。いつも急いでいて、変更に痛みを伴うコードの変更をしているなら、最高の自分ではいられない。 -->
+<!---->
+<!-- この部分に関してはちょっと諸説ありそうだと思った。 -->
+<!---->
+<!-- プログラマ的にはクリーンなコードを書いたり、コードをクリーンにする作業自体が楽しかったり、そこから学びを得ることができるというのは当然理解できる。 -->
+<!---->
+<!-- ただ業務であまりそこを重視しすぎるとビジネス的な都合を無視する考えに繋がるのでは...と思った。（著者はそこまで言ってないかもだが）一般的にはビジネスがうまくいかないと売上が上がらないことに起因してモチベーションが下がったり報酬が思ったように上がらなかったり、働く環境が悪化したりすることもあるため難しい。 -->
+<!---->
+<!-- いちメンバーの視点だとビジネス都合とソフトウェアの状況を勘案して総合的に判断するのがよさそうな気がした。 -->
+<!---->
+<!-- マネジメント側の立場だとメンバーのパフォーマンスを高めることも重要な責務なのでうまくバランスを取るのが重要そう。 -->
+
+## まとめ
+164ページと全体がコンパクトにまとまっているのと、簡潔に書かれている（かつ、翻訳もとても読みやすい）ので短時間で読みやすかった。
+
+**「整頓」** という概念を知れたのが最大の収穫だった。今後は意識的に実践していきたいと思う。
+
+次回作の構想もあるようなので楽しみ。