だいたい一週間ぐらいかけてこの本を読みました。
この記事は、本書の感想記事になります。ちゃんと買ったよ！（？）という画像です。
全体的な内容
『レガシーコードからの脱却』というタイトルから、『レガシーコード改善ガイド』や『レガシーソフトウェア改善ガイド』に近い、リファクタリングのテクニックなどを紹介する本かな？と思っていました。
本書は違います。初めからレガシーコードを作り出さないためにどうするか、を中心に書かれた本です。アジャイル開発手法によって、業界全体として失敗プロジェクトが減少し、開発コストも減少していると言えるが、なぜそうなっているのか。ソフトウェア開発者が何を学び、どのような態度で開発するのが良いのか、などが書かれています。
無論、リファクタリングについても触れられています。今まさに目の前にあるレガシーコードに対して、手を打つ一つの手法がリファクタリングです。
テストの重要性
本書、かなりの部分でテストについて述べられています。テストが大事だと書かれた本は、枚挙に暇がないほど大量にあります。なぜテストが大事か。本書では特に以下のような点で、テストが重要だと言っていたように感じました。
- 開発を小さな単位で区切る
- 受入基準を明確にする
- 作りすぎないようにする
最近、オフショアに開発を依頼することがあります。そういうとき、一応全体を設計しないと自分が意図したとおりのものが返ってきません。
しかし、まだ何もない、作られていない機能に関して、完璧な全体設計を行えるほど私はすごい人間ではありません。それに、その機能が持つ微妙なニュアンスを完全に設計に落とし込むのは非常に難しい場合があり、「この辺りは設計固まってないから、適当に作ってくれ」というわけにはいかずに設計しすぎてしまうこともあります。
こういう現状に、
そもそも、最初に全部を設計する手法自体に誤りがあるのでは？
と思うようになりました。だって、これじゃやってることウォーターフォールじゃん、と。
であれば、最低限のストーリーに区切って、それをテストとして表現して、「このテストが通るように実装してください」という渡し方ができるかも…と思い始めました。
テストが通れば、ユーザーの目には見えない機能であっても、使いさえすれば価値が生まれる状況になります。
技術的卓越性を求める
この態度が本当に大事で。
私も、テストファーストで開発しようと奮闘していますが、データアクセス部分の抽象化がうまくいく気がしなくて、躊躇してしまいます。そして、もっとコーディング能力があれば…と歯噛みします。
リファクタリングするにもテストを書く。これも自分が実践してこそだと思っています。
本書にも、テストを書くこと、設計は最後に行うこと、リファクタリングすることと、様々なことが書かれています。ただ、その具体的な手法（ソースコード例など）については触れられません。
それは自分で学ぶこと、というか、学ぶ方法は巷にあふれているので、それらを学び続けることが、私たち*1の仕事なのではと思います。勉強しない人を否定しているわけではなく。
感想
やっぱり、テストは大事だよな…と改めて認識しました。
幸い、現在の立場は、プロダクトに対してテスト導入を推進できる状態*2にあります。まずは自分からやってみよう、と思っている次第です。
ふるまいをテストにする、と言われても、どうやっていくのがいいんだろう…？という部分は疑問があります。これはもっと学習して実践して、学んでいこうと思っています。
本書では、アジャイル開発手法についてしっかり書いてあります。自分の感想が、あまりにもテストに傾きすぎているな、と、ここまで書いて思ったので、そちらにも触れます。
アジャイルで開発するのはあくまで手段です。それでも、優れた手段であることは、本書でもデータとともに触れられています。その手段をうまくやるために、タスクをタイムボックスで区切る、それを可能にするためにタスクを細分化する、細分化したタスクが終わったことを検証するためにテストを作るなど、本書ではきちんと書いてあります。
また、やり方より目的などを明確にすること。これは本書ではとても強調されて書いてあります。どうやってテストするのか、ではなく、なぜテストをそんなに重視しているのか。それについて私も述べていかねば、と思っています。
全ては、
ソフトウェアの寿命を延ばし、価値を高める
ためにあるのだと。
本書で一番好きだった言葉
ソフトウェア開発は複雑だ。おそらく、人類が関わるものの中でいちばん複雑なものだ。
「４章 ９つのプラクティス」で書かれている、この文章です。
プログラミングが大切なのに、全体の工数のほんの数割しかない。作ってしまえば終わりとは言えない。作ったけど使われないことすらある。ソフトウェアで表現する対象が無限に存在する。要求される知識が広い。様々な要因を考えると、この主張にも頷けます。
ときどき、自分の仕事を振り返って、なんでおれはスケジュールを区切っているのだろう、細かい設計をしているのだろう、なんで英語でコメント考えているのだろう、得意でもないインフラについて考えているのだろう、他のサイトを見てどういう構成がベストか考えているのだろう、とか思います。
要求される知識が広いのです。とにかく広い。まあ、それが楽しくもあるのですが。
おわりに
ただただ、まとまりのない感想を書いた記事になっています*3。
私のように、ある程度経験を積んで、他の書籍を読んでいる人間からすると、本書の感想はこんな感じになります。テストって大事だよね、みたいな。
おそらく、経験した人によって本書から学べることは違うと思います。人によっては、こんなプラクティス、とっくに導入しているよ、と思うかもしれません。
個人的には、若手にとっては様々なプラクティスを学べる本だと思います。経験を積んだ方には、その経験によって全く違う学びがあるのではと思います。
いろんな人の感想を読んでみたい。そんな感じです。
本書中に出てきた『レガシーソフトウェア改善ガイド』に関しては、過去に記事書いています。よかったらどうぞ。
