London Tech TalkのBookclubに初参加して、「Tidy First?」の読書会を終えたのでその感想

こんにちは！カナダ・バンクーバー在住でフリーランスでソフトウェアエンジニアをしているコジです！
今回は、ぼくが参加していた読書会がとても楽しく学びがあったので、読書会や読んだ本の感想を書いてみました。

参加した読書会は、ぼくがよく聴いているTech系PodcastのLondon Tech Talkで開催していたBookclub(読書会)でした。

London Tech Talk

元々、このPodcastのリスナーで過去にDDIA本(データ指向アプリケーションデザイン)の読書会とその内容の放送回を聴いて興味を持ったのが参加のきっかけでした。

読んだ本：「Tidy First?」

Tidy First?

この本の著者は、XP(エクストリームプログラミング)やテスト駆動開発で有名なケント・ベックで、主にこの本ではリファクタリングについて書かれた本となっている。
内容は英語だが書籍としては、全部で122ページというわりと読みやすいサイズなので読書会としてはちょうどいい分量の本だと思います。

「Tidy First?」の書評

タイトルにもある通り、この本のテーマの Tidying というのは、「お片付け」という意味で、この書籍ではリファクタリングのことを指しています。

内容はざっくり３部の構成で、
1. Tidying: 明日から使えそうなTips集(リーダブルコード的な内容)
2. Managing: どのようなメンタルモデルでリファクタリングするべきか
3. Theory: より広範なビジネス観点でリファクタリングを捉える
となっている。

個人的に印象深く刺さったポイントは以下。

Reading Order

これは、第１部 Tidying の5章で書かれていた内容。
コードは書くよりも読むことのほうが多いという前提のもと、コードが理解しやすくなるよう、コードの順序を再編成することを提案しています。例えば、ファイルを読んでいく中で、重要な処理が最後に見つかることがよくあるので、コードを読者が望む順序で並べ替えるのを勧めています。
ただ、言語によっては宣言の順序が実行結果に影響を与える場合もあるため、Tidyingは他の整理作業と同時に行わない方が良いとここでは提案しています。

コードの変更を Behavior/Structureで分ける

こちらは、第２部Managingの16章Separate Cleaningで書かれていた内容。
例えばリファクタリングのPull Requestを出す際に、構造だけの変更と振る舞いの変更をそれぞれ分けてPRを出すといーよということが書かれている。ソフトウェアエンジニアならあるあるネタとして、PRの差分が大きいとレビュアーの負担が大きくてなかなかレビューが進まないという状況は経験があるかもしれません。
このパートでは、そのような状況を回避するためにStructureとBehaviorの変更を分けるというアプローチを提案しています。

Structure Changes は、コードの構造そのものに影響を与える変更。たとえば、コードの整理、ファイルの分割や統合、名前の変更など、コードの見た目や配置を改善する変更が含まれます。これらの変更は、動作に影響を与えず、コードベースをより理解しやすく、保守しやすくすることが目的だと思います。
Behavior Changes は、ソフトウェアの実際の動作に影響を与える変更。新しい機能の追加や既存機能の修正、バグの修正など、ソフトウェアの振る舞いに直接関係する部分です。これらの変更は、動作確認が必要であり、テストの追加や修正が求められる。

Structure と Behavior の変更を別々に扱うことで、コードレビューがスムーズに進みやすくなり、各変更の影響範囲を明確に把握でき、結果として、レビュアーの負担が軽減され、変更のリスクが最小限に抑えられると書かれています。
個人的には概ね同意で、PRに分ける以外に可能ならコミットで分けてもいいかもなと思いました。また Structure の変更でもちょっとしたサイズの修正ならレビュー無しでPRをマージしてもいいという提案は、Tidying のハードルを下げる良い提案だなと思いました。

リファクタリング(Tidying)を金融工学のオプション理論の観点から捉える

これは、第３部Theoryで書かれていた内容。
このパートは抽象的な内容だが、大学で金融工学を学んでいた自分にとっては、とても面白いと同時に難しいなと思ったパートでした。
オプション理論というのは、ざっくりいうと不確実性が高く将来予測が難しい出来事に対して何かしらのアクションを行使する権利を持つことです。例えば原油取引のような価格変動の幅が大きくベストな売買タイミングが難しい商品の取引をする際に、ある時点で特定の価格で原油を売買する権利（オプション）を持つことで、買い手は不利な取引を回避でき、売り手はプレミアム(前払いの手数料)を受け取ることで不確実性を抑えて取引ができます。

このオプション理論をリファクタリングに当てはめて考えるのは難しいですが、自分なりの理解としては以下のような感じです。

• コードの柔軟性の確保:

  • コードをリファクタリングすることで、将来の変更や拡張に対する「オプション」を確保する

    • 例：モジュールを分割することで、特定の部分だけを変更しやすくなるオプションを得る

• コードの複雑性を下げる:

  • リファクタリングによって、コードの複雑さを減らし、将来的なバグやエラーのリスクを低減させ、コードの変更や追加が安全に行える

• 将来的な拡張のための準備:

  • 柔軟な設計を取り入れることで、将来の機能追加や変更に備えることで、新しい機能を簡単に追加できる「オプション」を持つ

正直、ソフトウェアエンジニア目線では、金融工学のオプション理論をリファクタリングのアナロジーとして説明するのはわかりにくいと思ったのですが、これはケント・ベック自身がdev以外のbiz側のステークホルダーたちとコミュニケーションすることが多いゆえなのかなと勝手に邪推したりしました。

ただ書籍としては、全体的にリファクタリングの重要性を明確に言語化している良い書籍だなと思いました。

London Tech TalkのBookclubの良かった点

このBookclubに参加して良かった点は大きく以下の３点でした。

• 事前に本の内容をインプットして読書会は議論などのアウトプットの場

• 読書会の内容をGoogle Docで議事録管理

• 各参加者のバックグラウンドが多様

読書会はアウトプットの場

まず、London Tech TalkのBookclubはアウトプットファーストなのがとても体験良かったです！
参加者は事前に本の内容を読んで、議事録に事前メモを書いて読書会の場で自分たちの考えを共有してディスカッションという流れが、本の内容をより深く多角的に咀嚼できたので、毎回満足感がありました。

読書会の内容をGoogle Docで議事録管理

今回のBookclubでは、北米西海岸/ヨーロッパと日本/ヨーロッパという2つの異なるタイムゾーンでそれぞれ開催していましたが、自分が参加していなかった日本/ヨーロッパの回の内容も議事録で見れるのが良かったです。同じ内容でもこんなにいろんな意見があるんだなあと感心しました。ホストの方には本当に感謝です🙏

各参加者のバックグラウンドが多様

自分が参加した北米西海岸/ヨーロッパの回では、自分がカナダ・バンクーバーから参加、他の方はアメリカのシアトル、サンフランシスコやパリ、ロンドンなどみんな住んでる国や街が違うという面白い環境でした。また所属している会社や職種も違うので、それぞれ異なる観点で本の内容について議論ができたので学びがありました。

改めて今回、London Tech Talk の Bookclub に参加できてとても楽しかったです。やはり一人で本を読むだけだと得られなかった他の方の異なる意見や、そこから新たな気づきが得られたのと、ちょっとした雑談から意外なことを知れたりととても学びが多い機会でした！
また機会があれば、参加したいなと思いました！🙌