Zenn
📝

Tidy First? を読んでみた

に公開
tidyfirst
idea

Tidy とは「整頓する」という意味。
コードを書く際に、いきなりシステムの振る舞いを変えるような大きな変更をするのではなく、まずは周辺を整えるような小さなリファクタリングから始めようというのが本書の大筋になります。

以前、著者ケント・ベックさんの XP 本を読んだことがあり、今回新刊が出たということで前情報なしに購入しましたが、冒頭から引き込まれたので、要旨をまとめてみました。

本書について

第I部 整頓

  • ガード節
    • if 文によるネストした条件分岐を早期リターンに置き換え、ネストを減らすことで可読性を向上させる
    • 使いすぎると逆に可読性が下がるので注意
  • デッドコード
    • 実行されないコードは削除する
  • 読む順番
    • ファイルの中のコードを読み手が遭遇したいと思う順番に並び替える
  • 凝集の順番
    • コードの順番を入れ替えて、関連する処理が隣接するようにする
  • 説明変数
    • 大きくてややこしい式の一部を、意図がわかる変数に抽出する
  • 説明定数
    • コード中に繰り返し現れる固定値を定数に抽出する
  • ヘルパーを抽出する
    • 他のコードとの相互作用が限られているコードを抽出、別メソッドとして切り出す
  • 冗長なコメントを削除する
    • コードに書いてあることをそのまま書いてあるようなコメントは削除する

第II部 管理術

プルリクエストを分ける

プルリクエストは以下の単位に分割することで、レビューのしやすさと速度を向上させることができます。

  • 整頓用のプルリクエスト
  • 振る舞いを変更したプルリクエスト

整頓は連鎖する

  • 散らかったデッドコードを取り除いたら、読む順番や凝集の順番への並べ替えの方法が見えてくるかもしれない
  • 凝集の順番にグループ化されたコードは、ヘルパーとして抽出可能かもしれない
  • ヘルパーとして抽出すると、ガード節や説明定数を取り入れたり、冗長なコメントを削除できるかもしれない
  • 冗長なコメントのノイズを取り除くことで、より良い読む順番が見えてくるかもしれない

整頓のコストを見極める

  • 1プルリクエストあたりの整頓の量が少ない場合
    • コードが煩雑になり、レビューのコストが高くなる
  • 1プルリクエストあたりの整頓の量が多い場合
    • 他のメンバーとのコンフリクトのリスクや、振る舞いを予期せず変更してしまうリスクが高くなる

どうすればレビューのコストを減らしつつ、整頓のコストを下げることができるか？
解決策として、チームに信頼と盤石な文化があるのであれば、整頓のプルリクエストはレビュー必須にしないことが提案されていました。
チームがそのレベルに達するまでは何ヶ月もかかるかもしれませんが、練習と実験を繰り返すことが大切だそうです。

整頓のタイミング

  • 整頓しない
    • 二度と変更しないコードの場合
  • 改めて整頓する
    • 整頓することですぐに見返りがあるわけではなく、大きなかたまりのコードの場合
    • 例) 古い API から新しい API へ大量の移行
      • すぐに影響のある部分だけを変更して、残りは改めて整頓する
      • 小出しに整頓できる
  • あとに整頓する
    • 同じ領域を直近再び変更する可能性がある場合
    • いま整頓する方が見返りが少ない場合
  • 先に整頓する
    • すぐに見返りがある場合
    • 何をどのように整頓すればいいかわかっている場合

第III部 理論

ソフトウェア設計とは

ソフトウェア設計とは何か？
それは「要素を役立つように関係づけること」と定義されています。

要素

  • 細胞 → 臓器 → 生物
  • 原子 → 分子 → 物質
  • トークン → 式 → 関数 → オブジェクト/モジュール → システム

関係づける

  • 呼び出す
  • 公開する
  • 待ち受ける
  • 参照する (変数の値を取得する)

役立つように

  • 要素の作成と削除
  • 関係性の作成と削除
  • 関係性が生み出す利益の増加

最初の言葉で置き換えてみると

  • 「式」を「要素を作成する」ように「参照する」
  • 「関数」を「関係性を削除する」ように「呼び出す」
  • 「システム」を「関係性が生み出す利益が増加する」ように「公開する」

上記のようなことをするのがソフトウェア設計と言えそうです。

なぜ整頓するのか

ソフトウェアは利益を生み出すために作られるため、利益に直接関係する振る舞いを変更することが求められます。
振る舞いを変更し続けるために煩雑なコードは障害となるため、整頓が必要です。

  • 整頓せずに振る舞いを変更
  • 先に整頓して、あとに振る舞いを変更

上記の2択への向き合い方として以下の4つを軸に考えるべきとされています。

  • コスト
    • 整頓によってコストが小さくなるか？
    • cost(整頓) + cost(整頓のあとに振る舞いを変更) < cost(整頓せずに振る舞いを変更) の場合は、先に整頓する
  • 収益
    • 整頓によって収益が大きくなるか？
  • 結合
    • 整頓によってより少ない要素の変更になるか？
  • 凝集
    • 整頓によって変更が必要な要素が、より小さく、もっと集中した範囲になるか？

まとめ

普段生活していると、物がどこにあるかわからなくなったり、汚れが溜まったりしていきます。
その状態を放置していると、探すのにより時間がかかるようになったり、汚れがこびりついて掃除するのに苦労するようになります。
しかし現代の生活では、なかなかそれらを解消するための時間が取れないことが多いです。

整頓は文字通り清掃と似ているなと感じました。
こまめに掃除をしていれば、掃除や物を探すのにかかる時間が短くなり、清潔な環境を保つことができます。
整頓も同じで、こまめに整頓をしていれば、コードを読んだりレビューする時間が短くなり、コードの品質を保つことができます。

またコードとは、小説やドキュメントと同じように人間が読む文章であり、その文章が読みやすいかどうかは、コードの品質に大きく影響すると感じました。

本書は、開発業務に携わっている方にとってはすでに知っている内容がありそうだなと思いつつ、いつやるか？なぜやるか？という点について深く考えたことはなかったため、学びになる内容でした。
今回新刊が出たということで読んでみましたが、どうやら本書の続編も予定しているらしく、引き続きお世話になることになりそうです。
興味のある方はぜひ読んでみてください。

Discussion