午前中に読み始めたら午後には設計が上達してしまった！ - 『Tidy First?』を読んだ

本

私の目標は、読者が午前中に本書を読み始めたら、午後には設計が上達していることだ。

本当にそのとおりだった。読んでる途中で既に自分の設計に対する考えが良い方向に変わってると感じた。とても良かった。おすすめです。

『Tidy First?』

をいただいて読んだ。昨日（2024年12月25日）発売。英語版が2023年11月28日発売だから、たった1年で日本語版が出たということだな。うれしい！はやい！ありがたい！

ソフトウェア設計に焦点を当てたシリーズの最初の1冊ということで、サブタイトルに「個人で実践する経験主義的ソフトウェア設計」とあるように、1人でできる種類のソフトウェア設計について書かれている。続刊ではチームについての話になる予定のようで、それも今から楽しみ。

2周読んだ

なんとなく2周読もうと思ってそうした。

1周目は細かい部分は気にせずにざーっと1,2時間くらいで読んだ。全体的にどういう話があるかを把握してから、2周目に突入。2周目は1行1行しっかり理解しながら数日かけて読んだ。

1周目：前半が面白かった

1周目は、第1部が分かりやすくて面白いなと思いながら読んでた。

第1部では、ガード節や説明変数など、ほんとに個人で取り組める整頓が紹介されている。だいたいどこかで目にしたことがあるかなとは思う。

そういう、一人で10分から1時間ぐらいあれば修正できてしまうような整頓によってコードを読みやすしていくのはとてもいい。

後半は内容が少し難しいなと思いながら読んだ。

2周目：後半が面白かった

1周目では整頓の具体的な一手を楽しんでたけど、2周目は一歩下がって眺めてみた。

「整頓はいいよね。やりたい。でも、実際の仕事で難しいのはいつ・どんな風に整頓へ取り組むかなんだよなぁ」と思ってたら、第2部がそれについての話だった（←気づくの遅い）ので「わー！そういう流れだったのかー！面白いー！」ってなって読んだ。第3部もさらに面白かった。

第2部：振る舞いの変更、構造の変更

第2部では、個人レベルでどのように日々の開発の中に整頓を取り入れるか、について紹介されている。

通常の開発では、システムに振る舞いの変更を加える。それに対して整頓は「コードの構造の変更」をする。この構造の変更を、いつやるべきか・どんな風にやるべきか・いつやめるべきかなどが書かれていてとても興味深かった。

例えば僕は、振る舞いを変更するような機能追加のコードを書いているときに「あぁ、この部分をちょっと整頓しておいたほうが機能を追加しやすいな」と気づくことがある。それを機能追加のプルリクエストに一緒に入れたくなる。振る舞いの変更＋構造の変更。

だけど「構造の変更はプルリクエストを分けようね」っておすすめされていて「はい、そうですね。ごめんなさい」ってなった。

でも、それだけで終わっていなくて「とはいえ、そうするとプルリクエストがたくさん出てしまってレビューが多くなるよね？」というところから、それに対する対処法まで紹介されていて「なるほどねー」ってなった。このあたりは読むときのお楽しみということで！

からの第3部

理論について。2周目の第2部の時点でとても面白いなーと思ってたんだけど、第3部はそれを超えて、個人的にめちゃくちゃ好き。

自分のことを思い返してみると、プロダクトを立ち上げたときは、まずは使ってもらう必要がある。だから、足りない機能をどんどん追加していくなどの「振る舞いの変更」が中心になる。最初はそれでいいし、そうするべきだと思っている。

でも、どこかで整頓しないといけないよなと思っている。コードが手に負えなくなる前に。それが目の前のお金を生み出すわけじゃないけど、プロダクトにとってとても大切だと思っている。でも、なんでだっけ？

第3部には、それに対する理論が書かれている。というかお金の話。

ソフトウェア設計とは何か、構造と振る舞いがそれぞれどのようにプロダクトに価値をもたらすのか、ソフトウェアの何にお金がかかるのか、結合と分離をどう扱うか、どれもとても興味深い。そして（僕にとって）大切なことだが、わりとややこしい話が、どれも4,5ページで簡潔に説明してあって読みやすい。

それらすべてがつながって、最後に「整頓を最初にやる？（Tidy First?）」という質問に答えている。え、流れが綺麗すぎるんですけど！って思いながら読んだ。

おすすめ

「整頓をどう進めるか？」は（本書では使われていない言葉だけど）「技術的負債」という言葉でよく言及されているものだと思う。

だから、技術的負債にどう対処していくかを悩んだことがある人なら、本書はとても面白いと思う。つまり、ソフトウェアエンジニアやエンジニアリングマネージャなら誰でも面白いと感じると思う。

ちなみに

「負債」という言葉を使っていないのは、意図されたものだろうと @kawasima さんが教えてくれた。感謝。「負債」だとマイナスの印象がどうしても出てしまうから「摩擦」というニュートラルな単語を使うように変えたってことっぽい。ほほー。

第4章は内容がよく分からなくて調べた

第4章「新しいインターフェース、古い実装」ではインターフェースの話をしていると思ったら、テストファーストの話がでてきて「？？？」ってなったので調べたら、↓このスレッドを見つけた。

Request for Examples: Pass-Through Interface - by Kent Beck

  • 振る舞いをちょっと変更したいときに、簡単に変更できるようにするために、透過的インターフェースを作る。
  • ここで言う「透過的インターフェース」は「ロジックをどう呼び出すか」という意味か。それを整頓するといいよってことか。
  • 後ろからコーディングする・テストファースト・ヘルパーの設計をやるのも、それと同じ目的で、呼び出し方を整理することになるよね、ってことか。

ってなってスッキリした。

印象に残っているのは

整頓はいいぞ！でも、整頓してると別の部分をさらに整頓したくなって、それが連鎖してどんどん整頓してしまいたくなるけど、それはよくない。振る舞いの変更のためにちょこっと整頓するくらいに留めるんだ！整頓をやりすぎないように。

っていうようなことが全体的に書いてあって、わかるわー。ってなってた。整頓楽しい。

冬休みのお供にどうぞ

ということで、読んで良かったなぁと思った本でした。130ページくらいで読みやすいし、1章1章がコンパクトでサクサク読めるし、冬休みのお供にとてもおすすめです！