リーダブルコード の感想文
リーダブルコードを読破したので、感想をまとめる
結論
第1部「表面的な改善」がピーク。
第2部以降は、他の書籍を読んだ方がよいと思う。ただし、プログラム初心者などの層に向けたちょうどよい書籍がこれ以外にないというのも事実。
そういう意味で初心者にとっては消去法的にこの本が「お勧め」ということになるのかもしれない。
そう考える理由
コードサンプルがわかりづらい
- 場所によって何言語で書かれているかわからないものがある
- 説明したい事象に最適化されたコードになっていない
- 他の部分が気になって頭に入りづらい
複数のコード例で、改善できる箇所が残ったまま完了になってしまうので、モヤモヤする。
15章に関しては、明らかに「初心者」を対象としているはずなのに、「時刻」を使う例を持ってきており、実装して検証するが非常に面倒である。
個人的には、大き目の例が大抵C++で書かれていることも萎える。
具体例のみで理論がない場合がある
10章が顕著。「無関係の下位問題を抽出する」のはいいが、どう抽出するのが正しいのか、インタフェースを調整するにしても、正しいインタフェースにするためには何が必要なのか、が書かれていない。具体例に対して、「これだと汚いから修正します」と書かれているだけ。何を根拠に汚いと思ったのか、どうなったからこれ以上はやらなくてよいのか、という理屈の部分がよくわからない。
もちろん、プログラミングは科学ではなくアート(技術)なので完全な理論は存在しないのだが、一般的な設計原則くらいは示した方がよいのではないか、と思ってしまう。
どうなの？と思う箇所がある
9章の2「変数のスコープを縮める」にて、「メソッドをできるだけstaticにする」と言っている。基本的には、オブジェクト指向のテクニックやイディオムを使って設計を改善したいはずであるのに、この方針はどうなのだろうか。もちろん、staticなメソッドは決定論的な動作をするので、テストもしやすくバグも発生しにくい(クラス変数という状態を扱わないので)というメリットがある。が一方でインタフェースの適用対象にならない。そういったデメリットもあることを分かった上で利用する必要がある。その匙加減が「できるだけ」に込められているのかもしれないが、そうだとすれば想定読者のレベルはかなり高いということになる。さて、そういった対象読者に対して、「ド・モルガンの法則」や「ネストはなるべく避ける」などの指摘は必要だろうか。こういったチグハグさを各所に感じてしまう。
タメになる思える点
批判ばかりでは申し訳ないので、タメになる思える点も挙げておく。
第1部
- 全体的に納得感があるし、そこまで考えた方がよいのだなという気づきがある
- 命名に対する英単語の選択については、英語ネイティブでないので生成AIなどを頼った方がよいかもしれない
- 同様の理由で、プロジェクトで共通認識を持てるようにまとめを作った方がよいかもしれない
- 工数をあまりかけず、難しいことも極力せずにコードの可読性を改善できる行為としてまとまっているのがよい
- コードの成型に関しては、linterを使って自動化した方がよいかも
第2部
- 中級者以上には特に目新しいことはないが、初心者には覚えておいてほしいことが書かれている
- この章に書かれていることも、コードの修正の「ついで」などでキャンプ場ルールとしてちょこちょこやっていくには適している
第3部
- 10章「無関係の下位問題を抽出する」
- 突き詰めると、実装に依存せず抽象に依存する、というところに行きつく話なのかな
- 11章「一度に一つのことを」
- 単一責任原則
- 12章「コードに思いを込める」
- 自然言語でやりたいことをまず書いてみる
- ライブラリを有効活用する
- 13章「短いコードを書く」
- 必要最低限の仕様に仕様を落とす(不必要に盛らない)
- 正しい仕様も実用の範囲で差支えがなければ実装を簡素にする方法を考える
- 完璧に仕様通りに実装しないことも選択肢に入れる
- 定期的にライブラリに目を通してライブラリに詳しくなる
- 車輪の再発明をしない
第4部
- 14章「テストと読みやすさ」
- テストが読みづらいと修正したくなくなる
- コードの修正に伴うテストの修正が面倒だと修正したくなくなる
- こういう観点から、ケースの選定やテストに使う値の選定に気を使う必要がある
全体を通りしての感想
- 個人的には14章が一番気づきがあったかもしれない(テストが汚かったり、過剰にテストしてしまったり)
- 13章は、仕様を決める人がコーディングに関わらないシステム開発では難しいことが多いかもしれない
- プログラムに関する本をたくさん読んで来ている人間には、総じて満足度は低い本だと思う
Discussion