Kent Beck 御大による、ソフトウェア設計に関する書籍シリーズの第一弾である「Tidy First?」を読みました。
この本では開発中に散らかってしまうコードをいかに片付けて、読みやすい状態を保つかについて説明されます。 ソフトウェアの設計は人間関係のエクササイズだとし、シリーズ第一弾である本書ではまずは一人で行える範囲の話題を扱います。
リファクタリングのサブセットとして、誰もが気に入って反対する人もいないくらいの小規模の改善と "Tidying" として定義して、代表的な Tidying のカタログと、その適用方法、そこから踏み込んで理論的な解説が続きます。
Tidying
どうして Tidying が必要になったかと言うと、御大は以下のように最近の「リファクタリング」という言葉の使われ方を嘆いている。
“Refactoring” took fatal damage when folks started using it to refer to long pauses in feature development. They even eliminated the “that don’t change behavior” clause, so “refactoring” could easily break the system.
「リファクタリング」は、機能開発を長期間止めることを指す言葉として使われるようになって致命的なダメージを受けてしまった。彼らは「振る舞いを変更しない」という条項さえ削除してしまってので、「リファクタリング」によって容易にシステムが破壊されるようになたのだ。
どうしてコードが散らかっていると駄目なのだろうか。
本書ではソフトウェアを変更するコストを、コードを理解するコストとニアリーイコールであるとしている。 コードが散らかっているとコードを理解するコストが上がり、結果的に開発速度も落ちてしまう。
つまり Tidying をしてコードが理解しやすくなると、将来的な変更のコストも下がって、選択肢が増えるということである。
Managing
コードの変更を「振る舞いの変更」と「構造の変更」に分けて解説している。「振る舞いの変更」は直接的な価値を生むが、「構造の変更」は間接的な価値しか生まない。
「構造の変更」= たとえば Tidying が価値を生むケースは cost(change) > cost(change + tidying) ということになる。
この式から分かる通り、Tidying によって理解しやすくなったコードを変更することによって、何もせずに変更する場合よりコストが下がる場合だけ適用すべきということになる。
つまり、Tidying は「振る舞いの変更」より長い時間をかけて行うべきではないことが分かる。
ではいつ Tidying をするべきかについても書かれている。コードを変更する前に行うのか、すぐ後に行うのか、ずっと後に行うのか、やらないのか。 これまで説明したとおり、変更のコストが下がるのであれば先にやるべきではある。ただし、どうやるべきかがはっきり見えてなかったりすると後でやった方がいいケースもある。 忙しくて時間がない場合もあるだろう。そういうときは Fun List (= Tidying は楽しいのでTODOリストではない) に書いておいてあとでやるということも可能である。 また、そのコードを二度と触らないのであれば、コードが散らかっていても問題はないと言えるので、やらない方がよい場合もある。
いつやるかというのは以前から僕も気になっていたテーマだったので、答え合わせのような内容でとても良かった。
他にも面白かったのが、レビューのコストについての話で、レビューのコストもチリツモで影響が出てくるので、Tidying による「構造の変更」についてはレビューするべきではないという書かれている。 逆にいうとレビューが必要なくらい複雑な変更は Tidying ではないということでもある。 ただし、これを実際にやるのはかなり勇気がいるので実践はできていない。
Theory
このパートはおもしろくて経済とソフトウェア開発について書かれている。 「ディスカウントキャッシュフロー」と「オプション取引」についてをソフトウェア設計に当てはめて解説されている。
「ディスカウントキャッシュフロー」は未来の価値より今の価値の方が高い。 つまり早く手に入れて、支払を出来るだけ遅らせる方が得という話で、これをソフトウェア開発に置き換えると、出来るだけ早く機能開発をすることで、顧客に届ける価値が高まるということになる。(=開発者は収益を得られる) 開発の初期段階はまだ何の価値も得られていないので、特にこの傾向が強まることで、直接的に価値を生む「振る舞いの変更」を優先してしまいがちである。
「オプション取引」は将来購入する権利を買う取引で、例えば「一週間以内に10,000円で株券を買う権利」を買ったとすると、株の値段が10,000円を超えたらお得だし、下回ると損になる。 ちなみにこれは「買う権利」でしかないので放棄することも出来るのがみそである。 これをソフトウェア開発に適用すると「構造の変更」を行うモチベーションになるという話である。 つまりコストを払って「構造の変更」を行うことで、将来の変更しやすさが高まり、システムとしての選択肢が増やせるので、その時に手に入る価値が妥当だと思うならコストを払うべきと言える。
ところで本書ではソフトウェア開発全体のコストを以下のように定義している。
cost(software) ≒ cost(change) ≒ cost(big change) ≒ coupling
つまり変更のうち大きな変更のコストが支配的で、そのコストは「結合」からきていると言うのだ。
「結合」しているとは「同時に変更する必要がある」ということであり、「結合度」が高いと同時に変更する箇所が増えてしまうので、変更のコストも上がるということである。 それではとにかく「疎結合」にすればいいかというとそうでもなくて、結合度が0のソフトウェアは存在しないし、結合度を下げるにもコストがかかるのである。 ここら辺は「要はバランスおじさん」が登場している。
Conclusion
最後に一番好きな一文を紹介して終わります。
The world is challenging enough that we can’t afford to ignore opportunities to make things easier for ourselves and others.
この世界は過酷なので、物事を簡単にする機会を逃すわけにはいかない
もうすぐ日本語版も出るみたいなのでとっ散らかったコードをなんとかしたいと思っている人はぜひ。
また、第二弾の「Tidy Together?」も執筆中なので楽しみです。
