「Tidy First?」読書感想文

この記事は CARTA TECH BLOG アドベントカレンダー2024 の 12/5 の記事です。

fluctでエンジニアをしていますryuといいます。

「洋書を読む会」と題して、洋書を課題図書にした読書会を、弊社の技術コーチのt-wadaさんを交えて、毎週開催しています。

その会で、「Tidy First?」を読みました。

www.oreilly.com

今回は、その「Tidy First?」の読書感想文です。

どんな本

著者はテスト駆動開発やエクストリームプログラミングのKent Beck氏です。

まずTidyとは何？というと、日本語では整頓や整理という意味です。整頓というとソフトウェアではリファクタリングのことを思い浮かべると思いますが、本文では、以下のように説明があり、作者は意図的にリファクタリングと差別化してTidyという言葉を選んでいるように感じました。

A tidying is like a little baby miniature refactoring.

普段コードを書いて、やばいコードに直面したときに、これは、最初に整頓したほうが良いのか、あとに整頓したほうが良いのか、みたいなことに悩むことは誰しもあると思います。

この本のタイトルは Tidy First?です。Tidy FirstではなくてTidy First ? です。明確に、先にやるのが良い！みたいに答えを提供するのではなくて、こういうメリット・デメリットがありますよ、こういう場合は先にやる（もしくは、後でやる、そのうちやる、やらない）のが良さそうですね、みたいな内容でした。

特におもしろいなと思ったのはIII部で、ソフトウェア設計とはなにか？というのに踏み込み、経済の話（明日の1ドルよりも今日の1ドル）とオプション（振る舞いの変更の準備）の話を交えて、Tidy Firstが良いかどうかという話をしていました。

経済の話的には、より早く稼ぎ、後でお金を使うのがよいから、Tidy Firstはやめよう。
オプションの話的には、今お金を使って、後でお金を稼ぐのが良いから、Tidy Firstをしよう。

となると、じゃあ、どっちが良いんだっけ？ということが語られてました。

また、経済性やオプションといった、金銭に結びつくメリット・デメリットだけでなく、geekである自分自身の気持ちも大切やでみたいなことが書いてあったのがすごく良かったです。

あとは、I部では、具体的な整頓のやり方が紹介されていました（ガード説や、デッドコードは消そうなど）。すぐ業務に役に立つ知識ですので、こちらも勉強になりました。

印象に残ったところ

Code review processes (which I’ve promised multiple times to trash, but now is not the time) don’t distinguish between reversible and irreversible changes. We end up making the same investment with radically different payoff profiles. What a waste.

文中では、構造の変更と振る舞いの変更との違いは何か、可逆的があるかどうかである。みたいなことがあり、その上で、上記の文章がありました。可逆的な変更と不可逆的な変更は意識してレビューしたことなかったので確かにとなりました。

Finally, tidying later just feels good. Software development is a human process. We are humans with human needs. Sometimes I just don’t have the energy to tackle a new feature, but I want to work. Picking an item off the Fun List and tidying it brings me joy. Don’t underestimate how much better you are as a programmer when you’re happy.

Tidying laterをすることについて、ロジック的にはなした最後にあった文章です。Don’t underestimate how much better you are as a programmer when you’re happyがほんとに良いなって思いました。

Most important, though, is you. Will tidying bring peace, satisfaction, and joy to your programming? Maybe some. This is important because if you are your best self, you are a better programmer. You can’t be your best self if you’re always rushing, if you’re always changing code that’s painful to change.

良い。最高の自分になりたい。