Ch.13〜Ch.15＆本全体のまとめ｜『リーダブルコード』読解メモ #7
コーディングにあたっての指針を示しておければということで、『リーダブルコード』を課題本に設定しまとめています。（基本的に本を片手にご確認いただく前提なので、細かいところの記述は省略すると思います。勝手に解釈した上での要約なので、万が一解釈違いは生じていたとしたらご容赦ください。）
#1ではCh.1の『理解しやすいコード』とCh.2の『名前に情報を詰め込む』について、#2ではCh.3の『誤解されない名前』とCh.4の『美しさ』について、#3ではCh.5の『コメントすべきことを知る』とCh.6の『コメントは正確で簡潔に』について、#4ではCh.7の『制御フローを読みやすくする』とCh.8の『巨大な式を分割する』について、#5ではCh.9の『変数と読みやすさ』とCh.10の『無関係の下位問題を抽出する』について、#6ではCh.11の『一度に1つのことを』とCh.12の『コードに思いを込める』についてまとめました。
Ch.1~2（理解しやすいコード＆名前に情報を詰め込む）｜『リーダブルコード』読解メモ #1 - lib-arts’s diary
Ch.3~4（誤解されない名前＆美しさ）｜『リーダブルコード』読解メモ #2 - lib-arts’s diary
Ch.5~6（コメントすべきことを知る＆コメントは正確で簡潔に）｜『リーダブルコード』読解メモ #3 - lib-arts’s diary
Ch.7~8（制御フローを読みやすくする＆巨大な式を分割する）｜『リーダブルコード』読解メモ #4 - lib-arts’s diary
Ch.9~10（変数と読みやすさ＆無関係の下位問題を抽出する）｜『リーダブルコード』読解メモ #5 - lib-arts’s diary
Ch.11~12（一度に1つのことを＆コードに思いを込める）｜『リーダブルコード』読解メモ #6 - lib-arts’s diary
#7では、Ch.13の『短いコードを書く』、Ch.14の『テストと読みやすさ』、Ch.15の『「分/時間カウンタ」を設計実装する』についてまとめていきます。
以下目次になります。
1. Ch.13_短いコードを書く
2. Ch.14_テストと読みやすさ
3. Ch.15_「分/時間カウンタ」を設計実装する
4. まとめ
1. Ch.13_短いコードを書く（簡単な要約）
プログラマが学ぶべき最も大切な技能はコードを書かないときを知ることなのかもしれない。自分で書いたコードであれば全ての行をテストして保守しなければならないので、ライブラリの再利用や機能の削除をすることで、時間を節約したり、コードを簡潔に維持したりできる。
プロジェクトを開始する際にプロジェクトに欠かせない機能を過剰に見積もってしまうことで、多くの機能が完成しないか、全く使われないか、アプリケーションを複雑にするものにしてしまう。プログラマは、実務にかかる労力を過小評価しがちであり、プロトタイプの実装にかかる時間を楽観的に見積もったり、将来的に必要となる保守や文書化などの「負担」時間を忘れたりする。
全てのプログラムが高速で、100％正しくて、あらゆる入力をうまく処理する必要はない。要求を詳しく調べることで問題をもっと簡単にできることもある。店舗検索システム一つとっても任意のユーザの緯度経度ではなく、テキサス州のユーザのためにとすることで問題やそれに関する実装をシンプルにすることができる。
また、プロジェクトが成長してもコードをできるだけ軽量に保つには以下を意識しておくと良い。
・汎用的な「ユーティリティ」コードを作って、重複コードを削除する
・未使用のコードや無用の機能を削除する
・プロジェクトをサブプロジェクトに分割する
・コードの「重量」を意識し、軽量で機敏にしておく
身近なライブラリに親しむことも重要で、既存のライブラリで問題を解決することもできるので、この点も意識しておくと良い。
とにかく、難しいコードを書かないようにするには下記を意識しておくと良い。
・不必要な機能をプロダクトから削除する、過剰な機能は持たせない
・最も簡単に問題を解決できるような要求を考える
・定期的に全てのAPIを読んで、標準ライブラリに慣れ親しんでおく
2. Ch.14_テストと読みやすさ（簡単な要約）
テストというのは人によって意味が違うが、Ch.14における「テスト」とは他のコードの振る舞いを確認するための全てのコードのことである。テストコードを読みやすくするのは、テスト以外のコードを読みやすくするのと同じくらい大切なことである。他のプログラマが安心してテストの追加や変更ができるように、テストコードは読みやすくしておくと良い。
もしテストコードが大きくなりすぎた場合は以下のことが起こる懸念がある。
・本物のコードを修正するのを恐れる
・新しいコードを書いたときにテストを追加しなくなる
テストコードを読みやすくするには、「大切ではない詳細はユーザから隠し、大切な詳細は目立つようにすべき」という一般的な設計原則を抑えるということである。また、エラーメッセージを読みやすくしたり、テストの適切な入力値を選択したり、テストの機能に名前をつけたりすることを意識することでより便利なテストコードを記述することができる。
テストを改善する点を下記にまとめる。
・テストのトップレベルはできるだけ簡潔にし、入出力のテストはコード1行で記述するようにする
・テストが失敗したらバグの発見や修正がしやすいようなエラーメッセージを表示する
・テストに有効な最も単純な入力値を使う
3. Ch.15_「分/時間カウンタ」を設計実装する（簡単な要約）
具体的なケーススタディのため省略します。確認されたい方は本を参照いただけたらと思います。
4. まとめ
#7ではCh.13〜Ch.15について取り扱いました。ここまでで本のメイントピックについて一通り取り扱うことができました。一度読んで終わりというよりは読み返しを何度も行うことで定着させていく方が良い内容だと思われるため、時折振り返る形が良いと思われました。
コードの書き方は習熟度やメインで使用している言語によって変わってくるところではあるため、時折読み返すことで都度新しい発見があるのではと思います。逆にあまり遵守し過ぎるとそれぞれの言語の特性などもあるため、各言語のコーディング規約などを優先するのが良いと思われます。
気軽に構えて時折参考がてら読み返すことで定着を図っていくのが本書の一番良い活用方法なのではと思われました。
