リーダブルコード (第三部)

#3部
##10無関係の下位問題を抽出する
関数やコードブロックを見て、「このコードの高レベルの目標は何か？」と自問する
コードの各行に対して「高レベルの目標に直接的に効果があるのか？あるいは無関係の下位の問題を解決しているのか？」と自問する
無関係の下位問題を解決しているコードが相当量あればそれらを抽出して別の関数にする。

・入門的な例
→完全に自己完結しているのでどのアプリケーションで使われるかを必要としない。
・純粋なユーリティコード
→「このライブラリーにXYZ関数があればなぁ」と思ったらその関数を自分で書く。そうしたコードは複数プロジェクトで使えるユーティリティコードになっている
・その他の汎用的なコード
→関数は小さく独立したものになっていれば、機能追加・読みやすさの向上・エッジケースの処理などが楽にできる
・汎用コードをたくさん作る
→プロジェクトから完全に切り離されているため、開発やテストに役立つ。
・プロジェクトに特化した機能
→抽出する下位問題はプロジェクトから完全に独立している必要はない、下位問題を取り除くだけでも意味はある
・既存のインターフェースを簡潔にする
→「理想とはほど遠いインターフェイスに妥協すること」はないようにする。
・必要に応じてインターフェイスを整える
・やりすぎは避ける
→小さな関数を作りすぎてしまうとあちらこちらに飛び回る実行パスを追いかけることになるため、避ける。
・プロジェクト固有のコードから汎用コードに分離させることが大事

## 11一度に1つのことを
コードは1つずつタスクを行うようにしなければならない。
これを「一度に1つのタスクをする」と呼び手順は以下のようになっている。
    1.コードが行っているタスクを列挙する。
    （タスク ex.「オブジェクトが妥当かどうかを確認する」や「ツリーのすべてのノードをイテレートする」など）
    2.タスクをできるだけ異なる関数に分散する。少なくとも異なる領域に分離する。

実例）
    ・タスクは小さくできる
    ・オブジェクトから値を抽出する

・まとめ
→読みにくいコードがあればそこで行われているタスクをすべて列挙する。

## 12コードに思いを込める
コードをより明確にする簡単な手順として
    1.コードの動作を簡単な言葉で同僚にもわかるように説明する
    2.その説明で使っているキーワードやフレーズに注目する
    3.その説明に合わせてコードを書く
・ロジックを明確に説明する
→否定形を減らし、権限がある人がより分かりやすいコードに直した
・ライブラリを知る
→簡潔なコードを書くのに欠かせないのはライブラリが何を提供してくれているかを知ること
・この手法を大きな問題に適用する
→解決策を言葉で説明する。手法を再帰的に適用する
・まとめ
→プログラムのことを簡単な言葉で説明することで問題のある下位問題に気が付くことができる。
ex.ラバーダッキング 人形などに問題を声に出して説明する手法（cf 『プログラミング作法』、『達人プログラマー――システム開発の職人から名匠への道』など）

## 13短いコードを書く
最も読みやすいコードは、何も書かれていないコードである

・その機能の実装について悩まないで
→実装にかかる労力を過小評価してしまうことで、「負担」の比率が上がってしまう
・質問と要求の分割

・コードを小さく保つ（コードをできるだけ小さく軽量に維持する）
→
汎用的な「ユーティリティ」コードを作って重複コードを削除する
未使用のコードや無用の機能を削除する
プロジェクトをサブプロジェクトに分割する
コードの「重量」を意識する。軽量で機敏にしておく

・身近なライブラリに親しむ
→標準ライブラリのすべての関数・モジュール・型の名前を読んでみる
どんなことができそうかを目を通しておく

・例：コーティングするよりもUnixツールボックスを使う
サーバーが4xx,5xxを返したときのURLパスを見つけるプログラムをJava等実装をしようとすると20行以上になってしまう。
Unixならば、コマンドを入力するだけで済む
（またソース管理もに含む費用もなくなる）

・まとめ
できるだけコードを書かないことを説明した。
新しいコードを書かないようにするには
１）不必要な機能をプロダクトから削除する。過剰な機能は持たせない
２）最も簡単に問題を解決できるような要求を考える
３）定期的にすべてのAPIを読んで、標準ライブラリに慣れ親しんでおく