はじめに

こんにちは。
リーダブルコードの社内向け輪読会の資料です。
以下記事の続きです。

今回は第Ⅲ部12-13章です。
前回から引き続き、コードに大きな変更を加える際のポイントを扱います。

第12章　コードに思いを込める

本章の冒頭で「ラバーダック・デバッグのことかな？」と思いながら読み進めたら、章末のまとめがやっぱりそうでした。

本章は、第10章で紹介された 「『このコードの高レベルの目標は何か？』と自問する」 という手法の詳細に当たると言えそうです。
自問する手順は以下の通りです。

「このコードの高レベルの目標は何か？」とうまく自問するための手順

1. コードの動作を簡単な言葉で同僚にもわかるように説明する。

2. その説明のなかで使っているキーワードやフレーズに注目する。

3. その説明に合わせてコードを書く。

手順1の「同僚」を「手元に置いたおもちゃのアヒルちゃん」に置き換えたものが、冒頭で触れた「ラバーダック・デバッグ」（本書では「ラバーダッキング」）と呼ばれるデバッグ手法です。

自分の書いたコードを1行ずつ、アヒルちゃんでも理解できる言葉でアヒルちゃんに向かって説明することで、「このコードで自分が実現したいのは何か？（高レベルの目標は何か？）」を客観的に整理します。

その後、手順2で高レベルの目標と下位問題を改めて整理し、手順3で下位問題を抽出することで、ソースを改善します。

第13章　短いコードを書く

本章では、なるべくコードを書かないこと、小さいコードで済ますことを念押ししています。

要点

13.1, 13.2 なるべく小さい実装コストでなるべく大きなメリットを出すことの要点

無闇に高機能なコードを書く必要はないし、精度や速度を追求しすぎる必要はありません。
1/4の実装コストで問題の半分を改善できるなら十分。

13.3, 13.4 コードを小さく保つことの要点

プロジェクトが進行してコード量が増えて「重く」なると、コードの全貌を把握するのが困難になり、機能追加のための実装コストや心理的抵抗感が跳ね上がってしまいます。
そのため、コードをできるだけ小さく軽量に維持しなければなりません。

コードを小さく保つための要点

- 共通コードを作って重複を削除すること

- 不必要な機能やコードを削除すること

- プロジェクトをサブプロジェクトに分割すること

- コードの「重量」を意識し、コードを軽く機敏に保つこと

- 標準ライブラリに慣れ親しんで活用すること

- ライブラリを再利用すること

おわりに

総じて、当たり前のことをきちんとやり続ける重要性を説く章という印象でした。それがなにより難しい。

次回もリーダブルにしていきます。

（参考文献）Dustin Boswell,Trevor Foucher.リーダブルコードより良いコードを書くためのシンプルで実践的なテクニック,講談社,2012,237p.