Zenn
💡

Tidy First?

2025/01/04に公開
設計
リファクタリング
tidy
idea

はじめに

タイトルの本が発売されてから間もないです。従って、内容に関する情報もまだまだ少ないように思います。気になったところに焦点を当てていきます。
基本は本の構成に従って考えを述べるつもりですが、一部混ざったところ・誤解もあるのでご了承ください。
https://www.oreilly.co.jp/books/9784814400911/

目的

  1. アウトプットすることでより深い理解を得るため
  2. 他に読んでいる人やこれから読む人の考察の一旦になれば

対象読者

Tidy Firstの内容理解にヒントを求めている人。特に後半の理論。

何をどうやって整頓する？

本章で述べられていることは、本題ではないと思います。
多くの書籍でより詳しく議論されているので、そちらをお勧めします。
参考：リーダブルコードほか

ここでは技術であり詳細の議論がなされています。
いくつか例を紹介します。

デッドコード

「消そう。以上」（引用：Tidy First?）
非常にシンプルで、明確なメッセージですが、なかなか削除できていない人も多いのではないでしょうか？その理由には「後で使うかもしれない」などがあるかもしれない。
しかし、バージョン管理によってすぐに戻せる。心配しなくても良い。

説明定数

例えば、下記のコードはresponse.codeが404だった時に何か処理を行う場合のコードです。

if response.code = 404
    hogehoge() // 何かしらの処理

多くの場所で指摘されているが、リテラル（上記でいう404の数値）定数は避けるべきです。
下記のように値の目的はなんなのか明らかにする必要があります。

PAGE_NOT_FOUND = 404
if response.code = PAGE_NOT_FOUND
    hogehoge() // 何かしらの処理

いつ整頓するのか？

多くのリファクタリングや設計に焦点を当てた議論では、時間の概念を多く語っているものは少ないように思います。本書では、時間に焦点を当て「いつ」整理するのか？について考察しています。

  1. 整頓しない
    変更しなかったり、コードの改善によって学ぶことがない

  2. 改めて整頓する
    整頓にメリットがある。大きな塊ですぐに整頓できない。いつかやるリストとして残しておく

  3. あとに整頓する
    変更が先だ。整頓はあとの方がやりやすい、いつかやるだとかえってコストがかかってしまう

  4. 先に整頓する
    何をどのようにすれば整頓できるかわかっていて、すぐに見返りがある

なぜ整頓するのか？

今回話したい本題。
「なぜ」整頓するのか？そして本当に整頓するのか？しないのか？をどのように判断するのか。

ソフトウェアの価値

ソフトフェアが価値を生み出す方法は以下の2つあると述べられています。

  1. 今日ソフトウェアが行うこと
  2. 明日ソフトウェアに行わせることができそうな新しいこと

順を追って確認してみます。

1. 今日ソフトウェアが行うこと

ソフトウェアが今まさに顧客に提供しているサービスそのもの。

例えば、給与計算を行うソフトウェアがある。働いた時間や社員のポジションによって金額を自動的に算出してくれるサービスです。

2. 明日ソフトウェアに行わせることができそうな新しいこと

ソフトウェアが将来実装する可能性のある機能があり、その選択肢が多いこと。

例えば、給与計算を行うソフトウェアにおいて、新しい国の通貨に対応できる状態であることなどが当たります。整頓することで変更容易性が高まり、選択肢が増えることになります。仮に泥団子のような大きなメソッドだったらどうでしょうか？その機能は予算の観点から選択肢から除外される可能性すらあります。

さてこちらが少し難解に感じた箇所でした。
本書では「オプショナリティ」と呼ばれるこの価値は、金融用語として用いられます。

どういうことでしょうか？
時間による不確実性が価値を生むのです。お金を例に考えます。

今日100円/ドルだったものが明日いくらになるか？
特に大きな理由もなければ1円程度の間に収まるでしょう。

では1年後ではどうでしょうか？
2024年を例にすると、最大20円もの幅があり、より不確実性が増したと言えます。

今日のお金との差が大きいほど利益のチャンスが増えるため、オプショナリティは価値を増大します。この考え方がソフトウェアにも適用できるということになります。

つまり、ソフトウェアのオプショナリティはその価値を増大させることが金融的な観点から示唆されます。

改めてなぜ整頓するのか？

ソフトウェアのオプショナリティを増大させるため

整頓するのか？しないのか？

下記の場合迷わず整頓します

 cost(整頓) + cost(整頓のあとに機能開発) < cost(整頓せずに機能開発)

では下記の場合はどうでしょうか？

 cost(整頓) + cost(整頓のあとに機能開発) > cost(整頓せずに機能開発)

経済性を考えると、整頓せずに機能開発が行われるはずです。

しかしながら、これは「1. 今日ソフトウェアが行うこと」のみが評価され、「2. 明日ソフトウェアに行わせることができそうな新しいこと」は評価されていないのです。

従って、後者のケースでは整頓する選択肢もあるし、整頓しない選択肢もあるということになります。

つまり、「今時点でコストが見合わないから整頓しない」という判断ではなく、「この整頓は将来のソフトウェアの機能実装や変更に対してポジティブになる（オプショナリティが増大する）かもしれないから、整頓する」という判断が可能になります。

感想

リファクタリングなどの書籍もいくつか読んできて、手法や技術は学ぶことができました。
加えて本書ではそれをやるかどうか、について述べられており、それを考える良いきっかけになりました。

Discussion