読者です 読者をやめる 読者になる 読者になる

16bit!

エンジニアじゃなくなっちゃった人が何かを書くブログ

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

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

無関係な下位問題(10.1)

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

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

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

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

コードを書かないのがベスト(13)

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

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

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

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

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

ライブラリを使え(13.4)

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

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

テストは神ではない(14.9)

ただ、本書の14.9にも書いてあるのですが、あまりにもテストを重視しすぎるのも考え物です。

特にテストコードによるテストはボタン1つで実行できる手軽さもあり、
プロジェクトの「資産」と見なされることもしばしばありますが、
それ故にテストコードを絶対に変更してはいけない神のようなものとして扱い、
結果として、「より良いものを作る」というプロジェクトの本質を見失わせることもあります。

あくまでもテストは品質を担保するためのものであり、
大事なのは良いものを作ることだということを忘れてはいけません。

おわりに

というわけで、長くなりましたがリーダブルコードの個人的メモをようやくまとめ終わりました。

内容としては「当たり前」なものが多かったですが、
それでも読んで良かったと思います。

ちなみに僕が今の会社でエンジニア配属された時に、
コードの可読性について言われた最初の言葉は、
「営業が読みにくいメールや読みにくい資料を作っていてはいけないのと同じで、
 プログラマは読みにくいソースを書いていてはいけない」
ということでした。

ソースはメールや資料と同じで、相手に意図が伝わるように書くこと。

本書で紹介されているいろんなテクニックも重要ですが、
何より大事なのはこういう心構えなんだろうなと思います。


おわり。