【読書感想文】リーダブルコード　メモその3

【読書感想文】リーダブルコードメモその1 - 16bit!
【読書感想文】リーダブルコードメモその2 - 16bit!
の続きです。
今回で最後になります。

無関係な下位問題（10.1）

関数を切り出すことには再利用性という理由もありますが、
それと同等くらいに可読性が上がるということも重要です。

「このメソッドでしかやらない処理だから、ここに書きました」
は理解できなくはないけど、
独立した処理なら切り出した方が読みやすくなります。

本書では、最初はまず「プロジェクトから独立した、汎用性の高いコードをたくさん作る」
ことを推奨していますが、
「プロジェクトに特化した機能であっても十分に効果がある」
とも述べています。

全くその通りで、たとえ汎用性が高くなくても、
独立した処理ならどんどんメソッドは切り分けた方が良いと思います。

コードを書かないのがベスト（13）

コードは短いほど読みやすいのはその通りですが、
本書では、「要するに、書かなくて済むのがベスト」と言っています。

最も読みやすいコードは、何も書かれていないコードだ。

そして、コードをできるだけ書かないための方法として、
「すべてのプログラムが、高速で、100％正しくて、あらゆる入力をうまく処理する必要はない」
と述べています。

つまり、本当は必要ない様々な特殊ケースに対応することでソースコードが膨れ上がり、
それによって簡単に書けるコードが読みにくくなってしまうのは馬鹿らしいということです。

ソースは書いて終わりではなく、その後機能追加などの度に読まなくてはなりません。
今回の実装にかかる時間だけでなく、将来的に必要となる保守の負担も考え、
「今要らないものは書かない」というのも大事なことです。

ライブラリを使え（13.4）

上記と少し関係するのですが、
公式が提供しているライブラリを使わずに、同じような処理を独自に書く人がいます。

僕が印象に残っているものでは、
javaのArrayListでcontains()を使わずに、自分で独自メソッドを書いている人がいました。
しかもutilディレクトリではなくそのクラス内に。

その人からすれば、
「ライブラリに何があるのかわざわざ覚えるのは大変なので、
　簡単なメソッドなら自分で書いた方が楽」
だそうですが、自分の書く工数のことしか考えておらず、
後からそのソースを読む他人のことを考えていません。

"contains()"と書いてあればすぐ分かるのに、
独自メソッドなせいでわざわざ読みに行かなくてはいけない。
それに「contains()じゃなくわざわざ独自で書いているんだから、何か意図があるのかな？」
とかも考えなきゃいけない。

標準ライブラリを全て覚える必要はないと思いますが、
せめて「標準中の標準」みたいなものは使ってほしいですね。

テストの本質は1行にまとめられる（14.3）

本書ではテストコードの書き方についても述べられています。
そして、

テストの本質というのは、「こういう状況と入力から、こういう振る舞いと出力を期待する」のレベルまで要約できる。そして、これは1行でまとめられることが多い。

と言っています。

これもその通りで、テストケースというのは本来inputとoutputの組み合わせで書けるものです。
要するに、テストコードは

testHogeHoge(input1, output1);
testHogeHoge(input2, output2);
testHogeHoge(input3, output3);
testHogeHoge(input4, output4);
･･･

という形式で書けるはずで、さらにこれならコピペで簡単にテストを追加できるので、
たくさんテストを書きたくなるという効果もあります。

テストをしやすいようにコードを書く（14.8）

テストコードを書くことの効果は、単純なバグ発見だけでなく、
テストコードを書きやすいようにソースコードを書くようになる、
つまり、inputとoutputが明確な、読みやすいソースを書くようになるという効果もあるそうです。

テストケースはexcelとかに書いて、実際に画面から叩くテストしか行わないことも多いかと思いますが、
テストコードを義務付けることによって、バグ発見以外の品質向上効果もあるので、
「テストコードによるテストやってみたけど、
　バグ発見数あんまり多くなかったから効果なさそうだし、やめるわー」
とか言わずに、継続することが大事かもしれません。