`Tidy First?` を読んで学んだこと
はじめに
Kent Beck 氏によって書かれた Tidy First? の和訳版を読みました。
こちらの記事ではこの本を読んで学んだこと（と思ったこと）をまとめます。
それと同時に本書を読む前に知っておきたかった前提知識についても記載します。
これによって、これから読む方々の何かしらの参考になれば幸いです。
本記事で記載しないこと
-
Tidy First?で記載されているプログラミングテクニック -
Tidy First?で記載されているそれぞれの細かい記載について
読む前に知っておきたかった前提知識
リファクタリングは外部からの振る舞いを変更せずに内部のみを変更する
ganyariya の完全な知識不足でしたが リファクタリング は外部の振る舞いを変更しないまま内部を変更することを指します。
もし外部から見た振る舞いが変わっているのであればそれは 機能変更 に該当します。
tidy は refactoring の subset である
本書のテーマである tidy(整頓) はリファクタリングの一部です。
そのため tidy についても外部から見た振る舞いを変更しない、が前提となっています。
Tidy First? が扱っている整頓は内部挙動のみに閉じたものであり、できるだけ振る舞いを変更しないようになっています。
時間価値の意味について
本書では時間価値という概念が出てきます。
ただ、本書だけの説明ではよくわからなかったため、参考記事として挙げられていたサイトを読んでなんとなく理解しました。
時間価値が伝えたいことは 今もらえる 1 万円のほうが 1 年後の 1 万円よりも価値を持つ だと考えています。
現時点においてお金を持っていれば投資やギャンブルなど、好きに使ってお金を増やせます。
しかし、未来については本当にお金を貰えるか怪しいですし、使える期間も限られます。
小学生のときに持つ 1 万円と大人になったあとの 1 万円であれば、小学生の頃に投資すべきだったなとこれまでの人生を振り返ってあらためて思います。
経済用語の オプション について
本書では オプション という用語が出てきますが、どうやらこれは経済用語らしいです。
ganyariya がこれを目にしたとき以下を指したものなのかと勘違いしていました。
- 関数において引数を省略できるオプショナル変数
- プログラム実行において挙動を変更できるオプションフラグ
- 同様にプログラムの挙動を変更できるオプション設定
本書においては 将来的に振る舞いを自由に変更できる変更可能性の高さ が オプション の意味で使われているようです。
ソーシャルゲームのサーバサイドエンジニアとして ganyariya は現在働いているのですが、ゲームプロダクト開発において仕様は常日頃変わり続けます。
そのため、できるだけ将来仕様変更があったときに最小限の変更で済むようユーザデータやマスタデータを設計することが大事になっています。
それを踏まえると オプション を用意することで 将来的に振る舞いを変更しやすい → 価値が高く利益を生み出しやすい というのは納得の行く論理だなと思いました。
学びになったこと
1 つの PR では 1 つの変更のみ行う
当たり前ですが 1 つの PR では 1 つの変更に留めたほうが良いです。
これは広く知られていますが、あらためて振り返ってみると ganyariya もこの前提を崩してしまった場面があるなと思いました。
- リファクタリングをしているときに、不必要な機能があったので削除してしまう
- リファクタリングと機能開発を同じ PR で行ってしまう
- 機能開発をしているときに直したほうがよいコードに出会い、PR を分けるのが面倒で一緒にやってしまう
現代には git という便利なツールがあるため、あらためて tidy と 機能開発 は積極的に別の PR に分けていきたいです。
一方で、とにかく PR を小さくしすぎる、つまり tidy を分割しすぎるのもよくありません。
レビュワーの時間を多く割いてしまう、かつレビュワーから見ると実装者が何をしたいのかよくわからないためです。
リファクタリング・整頓するのであればできるだけそれらをまとまった 1 つの PR として出すべきです。
リファクタリングと機能変更は一緒にすべきではない
1 つ前で記載した内容と同じです。
整頓を先にすべきかは cost を考慮すべきである
整頓を先にすべきか、それとも機能開発ならびに機能変更を行うかについては cost を考慮すべきだと自分は捉えました。
どのような cost があるかについて、本書では以下の概念で説明されていました。
- 時間価値
- 明日の 1 ドルより今日の 1 ドル
- オプション vs キャッシュフロー
これらが言いたいこと要約すると、以下のようになると考えています。
cost(now: 整頓) + cost(future: 機能開発) < cost(future: 整頓) + cost(now: 機能開発)
- → 整頓を先にすべき。
cost(now: 整頓) + cost(future: 機能開発) > cost(future: 整頓) + cost(now: 機能開発)
- → 機能開発を先にして目先の利益を確保すべき。来週時間があったら整頓しよう。
cost(now:整頓) + cost(future:機能開発) >>> cost(now:機能開発)
- → 機能開発を先にして目先の利益を確保すべき。整頓はせず将来の仕様変更がないことを祈る。
先に整頓をすることで機能開発をしやすくするべきか。
それとも機能開発を優先的に行って利益を確保するべきか。
これらはその事業が置かれているフェーズやプロジェクトの規模によって変わりそうだなとおもいました。
何でもかんでも整頓するのではなく cost の考慮が大事になります。
それでも 整頓は先にすべき
ganyariya は本書を読んで思ったのは Tidy First! つまり先に整頓しよう、になります。
Kent Beck 氏は Tidy First? と疑問符にすることで整頓を必ずすることがよいことではない、としています。
しかし、多くのケースで整頓を先にしたほうが高い価値を生むと自分は思いました。
少なくとも自分が関わるゲーム業界においては仕様変更は多く発生します。
キャラクターのレベルを拡張したり、既存機能をリニューアルしたり、他にも色々あります。
これらの仕様変更に追従した開発をおこなっていくうえで、過去コードの理解と整頓は非常に大事です。
何かしら間違っていれば障害につながってしまうためです。
そのため ganyariya が置かれている状況においては Tidy First! まずはリファクタリング・整頓をおこなうべきだなと結論づけました。
最後に
本書は 個人における整頓の仕方 について記載しておりこれは 3 部作の第 1 段です。
続く第 2 段の Tidy Together? においては会社を巻き込んで組織的に整頓をしていく、を記載するようで楽しみです。
リファクタリング・整頓は将来の変更容易性と堅牢性を高めるため非常に重要なものですが、プロダクトにおいては即時的に価値を生み出すものではありません。
既存の挙動を壊す可能性もありますし、これらの作業をしている間は新機能開発が行えないためです。
そのため、これらリファクタリングは評価の対象になりづらく、新機能の開発やマイルストーンの達成のほうが評価されやすいなぁと感じています。
Tidy Together? においてこのような評価も踏まえて、プロダクトとしてより健全なコードをどうチームで担保するかが記載されていると考えると、早く読みたくてたまらないです。
Discussion