Tidy First? | Journagu

『Tidy First?』を読んだ覚え書き。

Motivation

コードを書く機会が増えている
メンテナンスしにくいコードも増えている
職場で活用､展開できるエッセンスがあれば取り入れたい

Notes

整頓のテクニック

本書の第Ⅰ部で展開されている内容｡以下は印象に残ったもの｡

シンメトリーを揃え､同じことをするために2つ以上のパターンが存在しないようにする｡
既存のコードを追いきれてない場合や､時間がないときに手癖でやりがち｡

# 早期リターン､代入､returnを明確に分けている
foo()
  return foo if foo not nil
  foo := ...
  return foo

---
# 3項演算子で条件判定､代入､returnを一纏めにしている｡
# 上記と同じことをするがパターンが異なる
foo()
  return foo not nil ? foo : foo := ...

リテラルではなくシンボリック定数を使う｡
たぶんわかるでしょ､ではなく確実にわかるように書く｡

# 初見のときに404の意味を知っている必要がある
if response.code = 404
  hoge

---
# 初見でもわかりやすい
PAGE_NOT_FOUND := 404
if response.code = PAGE_NOT_FOUND
  hoge

なぜ整頓するのか､いつ整頓するのか

なぜ整頓するのか?

将来システムの振る舞いを変更することを簡単にするため

いつ整頓を始めるか?

変更の実装前に整頓する
- すぐに恩恵が得られ､整頓の勘所がわかっているケース
- 変更と1:1くらいのコストで済むケース
変更の実装後に整頓する
- 後回しにするとコストが膨らんでしまうケース
また別の機会に整頓する
- 整頓の規模感が大きく､すぐに恩恵を得られないケース
- 整頓することで少なくとも恩恵があるケース
整頓しない
- コードを二度と変更しないケース

整頓の理論

オプションという言葉が指すのはさらなる変更に対する柔軟性･拡張性｡オプションを備えることは移り変わる状況に対してすぐに対応できることを意味しており､これは変更そのものよりも価値がある｡

ソフトウェア設計は振る舞いの変更への準備｡

可逆的な変更はレビューに時間をかけてもリターンが少ない｡
不可逆的な変更はレビューに時間をかけてもリターンが得られる｡

コンポーネントや関数の結合が増えるほどソフトウェアのメンテナンスコストは増加する｡一方で､ある結合を減らすために分離をしても､別の箇所の結合が増えていく傾向にある｡
結合のコストと分離のコストはトレードオフの関係にある｡結合のコストを払うべきか､分離のコストを払うべきかは判断が要る｡

Thoughts

整頓したら見通しが良くなりそうなとき､変更と整頓を合わせてやっていることがままあったので､本書の主張はとてもわかる｡

整頓のみのPRはレビューなしでマージする仕組みは取り入れられると生産性が上がりそう｡とはいえ取り入れるには､メンバー全員が変更･整頓どちらなのかを見分ける嗅覚を養うことが必須で､これは道のりが長さそう｡レビューなしでマージをしても本番環境が壊れない仕組みを先に作るのが良さそうだろうか｡

第Ⅲ部で述べられていた､オプションに価値があるということ､設計はさらなる変更への準備である(意訳)ことはあまり意識できていない観点だった｡今日から意識することで視点が増えそうだ｡