「Tidy First?」を読んでの感想
「Tidy First？」 はKent Beck が新しく出した本で、リファクタリングの手法についてのある種の提案が書かれている本です。
当書 「Tidy First？」は、以下のような章立てになっています。
- Part Ⅰ - Tidyings: 具体的な Tidyings の方法・手法
- Part Ⅱ - Managing:
- Part Ⅲ - Theory:
1章の内容の解説は、過去に記事を書いていますので、よかったらお読みください。
この記事では、本を一通り読んでの感想について書きたいと思います。
Tidyings? とは
「tidy」 は 「几帳面」「綺麗好き」 みたいな意味合いがある言葉です。
「tidying」 も普通に名詞化しているようで、「きれいな状態にすること」「お片付けをすること」 という意味になりそうです。
The act or process in which things are tidied.
「Tidy First?」 はソフトウェア開発に関する本なので、この本の中での意味は以下です。
- Tidyings は Refactoring と同じようなもの。 Refactoring の Subset
- Tidyings は、とても小さな Refactoring
- 反対が少なく、賛同を得やすい修正
Tidyings are a subset of refactorings.
TIdyings are the cute, fuzzy little refactroings that nobady could passibly hate on.
誰からも賛同を得るような、小規模なコードの改善・リファクタリングのことを 「Tidyings」 と読んでいます。
Kent Beck に限らず、技術書や、技術関連の YouTube とかでも最近はリファクタリングや改善作業のことを 「Tidying Up」 と形容することが最近増えたような気がします。これは、「こんまり」の影響なのか、別の影響なのかは裏は取っていません。
結局何を言おうとしているのか
作者の主張を把握する時に、巻頭言と、巻末のまとめ（Conclusion）を読むのがわかりやすいと思うので、まずはそちらを見てみます。
巻頭言 (Chapter1)
Kent Beck には、従来のリファクタリングについての課題感があるようです。
端的に言うと以下のようなもの。
- リファクタリングには時間がかかりすぎる
- 時間がかかりすぎると、機能開発を止めてしまい、開発に深刻な悪影響をあたえる
- 「振る舞いを変えない」という前提も守られないことが多いので、容易にシステムを破壊してしまう
Refactoring took fatal damage when folks started using it to refer to long pauses in feature development.
They even eliminated the "the don't change behavior" clause , so "refactoring" could easily break the system.
端的に言うと、リファクタリングにかかる 「コスト」 を問題視しています。
巻末 (Chapter33)
一足飛びに巻末に飛び、Conclusion で何を書いているかを見てみます。
まとめとして、当書では以下の４点について、様々な視点で述べてきた、と書いています。
| # | item | description |
|---|---|---|
| 1 | Cost: コスト | Will tidying make costs smaller, later, or less likely? |
| 2 | Revenue: コストを支払って得られる収益 | Will tidying make revenue larger, sooner, or more likely? |
| 3 | Coupling: プログラムの結合度 | Will tidying make it so I need to change fewer elements? |
| 4 | Cohesion: プログラムの凝集性 | Will tidying make it so the elements I need to change are in a smaller, more concentrated scope? |
1と2、3と4が対になるもの、というのはすぐに見てとれます。
Coupling (coupled) という言葉が直感的に理解し辛いところがあるのですが、以前書いた記事にもその指す内容は記載しています。
同じような処理を行うコードが複数箇所（E1、E2）に存在していると、修正をする時に、E1も直さないといけないし、E2も直さないといけない。
この場合における E1と E2 の関係が coupled である、ということのようです。
いずれにせよ、当書で掲げているテーマは以下、とまとめられます。
- Tidyings を行うことで、システム関連の様々なコストは減らせるか、良い効果をもたらせるか？
- Coupling をなくし、凝集性(Cohesion)を高め、変更箇所を少なくすることができるか？
そして、Coupling , Cohesion は、システムに関するコストに大きな影響を与えるもの、として書かれています。
なお、ここで言う 「コスト」 は、Chapter 30 の冒頭でも書かれているように、 システムの運用・メンテナンスにかかるコスト にフォーカスが置かれていると思います。
I remember as a young programmer hearing dire reports that as much as 70% of software development costs went into maintenance. 70%!
該当する章をいくつか見ていきます。
Chapter 30. Constantine's Equivalence
「コンスタンティヌスの同等性」というのは何を指しているかよくわかってないですが、この章では以下のようなことが書かれています。
- システムのコストは、変更のコストとほぼ同義
cost(software) ~= cost(change)
- システムのコストは、結局 「大きな変更にかかるコスト」 に引きづられる
cost(software) ~= cost(big change)
- 「大きな変更」が起こる状態とは、つまり 「Coupling」 が起こっている状態 (あちこちに同じようなコードが散在している状態) である
cost(big change) ~= coupling
- まとめると以下
cost(software) ~= cost(change) ~= cost(big change) ~= coupling- →
cost(software) ~= coupling
つまり、システムコストを減らしたい場合は Coupling を減らすことが必要、ということになります。
To reduce the cost of software, we must reduce coupling.
Chapter 6. Cohesion Order
Coupling な状態はシステムコストが大きい、という点については Part Ⅰ の6章でも語られています。
cost(decoupling) + cost(change) < cost(coupling) + cost(change)
端的に、coupling が多いコード（複数の箇所に同じような処理が書かれているコード）の方が、そうでないコードより修正コストが高い、ということになります。
Chapter 31. Coupling Versus Decoupling
とはいえ、では Decoupling をひたすら行えばよいのか、というとそう単純ではない、ということも書かれています。
「Tidy First?」 を紹介するときによく用いられている絵を引用するとこちら。
同じような線を描く図を当書の中ではなんども見かけるので、Kent Beck がこういうグラフが好きだ、というだけなのかもしれませんが、いずれにせよ、「Cost」 を軸に、バランスの取れた着地点を見つけることが大事、というのがメッセージとして伝わってきます。
この辺の方法論や手法について、アカデミックに、もしくはプラクティカルにまとめられていると有益なのだと思いますが、当書は Kent Beck のエッセイ的な書籍なので、そこまで深堀りはされて記載はされてないようです。
ただ、エッセンスについてはわかりやすく伝わってくると思います。
Chapter 27. Options Versus Cash Flows
Cost とのバランスについては27章でも述べられています。
常に「Tidy First で良いか？」というと、Yes でもあり、No でもある、と述べています。
Tidy first? Yes. And also no.
軸になるのは、やはりコスト。
cost(tidying) + cost(behavior change after tidying) < cost(behavior change without tidying)
まず「Tidying」 を実施してから修正を行う方が早く進むケースは、もちろん「Tidying」を実施した方が良い。その作業コストを払ってでも、目の前のコードの可読性や認知コストを下げることが効果的な場合が当てはまると思います。
大きなシステムや、巨大なソースコードのリファクタリングにおいては、概ね上記の事が言えると思います。
cost(tidying) + cost(behavior change after tidying) > cost(behavior change without tidying)
逆に、「Tidying」 を行うことによりかえって時間がかかるケースは採用すべきでない、と書かれています。
以下は私の想像ですが、新規に作成するコードが多い場合や、全体的なコードベースがそこまで大きくない場合などが、このケースに合致するのではないかと思います。
Conclusion
読了しての、自分なりのまとめを記載します。
システム改善は、その「コスト」を軸に考えるべき
リファクタリングは対象が大きくなりすぎ、振る舞いを変更するところまで踏み込むとさらにコストが増大し、組織の中で実施をためらったり、実施をしても時間がかかりシステム開発に悪影響を与えることもあります。
まず踏み出すには、コードの整理整頓作業である「Tidying」 を実施することで、全体的なコストを下げることができる可能性があります。
そのため、まずは費用対効果の良い形で一歩踏み出す手法として「Tidying」が当書では提唱されている、と理解しました。
ただし、いずれにおいても、実施するべきか否かは、「コスト」を軸にして考えるべき、ということも、当書では繰り返し書かれています。
システムにおけるコストは、「可読性」の良し悪しが大きく影響を与えている
cost(software) ~= coupling
で表されている通り、「コストとは Coupling だ」と当書では簡潔にまとめられています。より俯瞰して見ると、Kent Beck としては 「可読性」 がシステムコストにおけるとても大きなファクターだと認識しているようです。
Coupling や Cohesion についてもそうですが、「Tidy First?」で紹介されている「Tidying」の手法は、その大半が 「可読性」 を良くするためのものです。以下の記事で具体的な手法を眺めると理解しやすいと思います。
当書の範囲外でも、CodeClimate などの ソースコードの品質を測定する SaaS でも 「Cognitive Complexity (認知的複雑度)」を大事な指標として取り扱っています。
We recommend checking for cognitive complexity rather than cyclomatic complexity, and we pair that with a return statements check, as two of our 10 point maintainability inspection. (All of which is completely configurable).
また、組織論でも、「Team Topoligies」 では 「Cognitive Load (認知負荷)」 がとても大事なテーマとして語られています。
複雑化が進む現代のシステム開発の現場では、見通しの良い状態、可読性の良い状態、すぐに理解できる状態、というものが大事だと語られるようになってきています。当書の Kent Beck の主張も、そういった全体的な潮流を反映しているものなのかな、と思います。
日々の「Tidying」作業が、システムの改善に寄与する
とはいえ、総合的に見て、言いたいことはこの１点なのかなと思います。
巨大な Bump Update や、大規模な構造の変更も必要なタイミングはありますが、日々のシステム開発のなかで、きめ細かく「Tidying」を続けていくことで、トータルでの開発効率の改善につながる。
「できないリファクタリングよりも日々の Tidying が大事だよ」というメッセージが、当書の一番伝えたいメッセージなのだろうとは思います。
Discussion