Code Readingを読んだ 1章

本書を読む目的

他人の書いたコードを早く理解して、修正を加えられるようになりたい
自分の書き方をもっと洗練させたい
設計が苦手なので、既存のコードから読み取れるようになりたい

はじめに

他人の作品を読まなかった偉大な作家、他人の筆使いを研究しなかった偉大な画家、同僚の肩越しに技を盗まなかった腕の良い外科医、副操縦席で実地の経験を積まなかった767機長 —果たしてそんな人たちが本当にいるのでしょうか

序論

ソフトウェアシステムに投入される労力の40~70%はプログラムを最初に作成する段階ではなく、既存のソースを読んで理解し修正することに使われる
優秀なコードを読むことは本格的なシステムの構成やプログラミングについての洞察力を養うことになる
- 小さなプログラムをいくら書いてもこうしたスキルは身につかない
プログラムは人が読むことを前提に書くべきであり、たとえプログラムが読むことを前提に書かれていなくても読む必要がある
コードを読む裏にはいろいろな動機があり、その動機に応じて戦略をかえねばならない

コードを読む理由と方法論

他人が書いた良質なコードを読むのを習慣化することが大切です
- 良質な小説を読めば語彙が増え、想像力が掻き立てられ、視野が広がるのと同じ
- うまく設計されたソフトウェアシステムの内部構造を詳しく調べることで、新しいアーキテクチャパターンやデータ構造、コーディング方法、アルゴリズム、スタイル、表記の慣習、APIなどの知識が得られる
良質なコードを読むことは自分が書くコードのレベルを高める効果がある
- コードを読んでいると「避けるべき典型的なコーディング作法」に必ず出会う
低品質のコードは次の点に着目すればすぐに見分けられる
- コーディングスタイルに一貫性がない
- 意味もなく複雑な構造や理解不能な構造が使われている
- 明らかな論理ミスや手抜きがある
- 移植性のない構造が多用されている
- 保守されていない
コードを読むときは目標を決めて重点的に読むことが大切です
- 最初から大きなシステムにチャレンジするのではなく、まずは小さなプログラムから始める
- 学習したいプログラムを実際にビルドし、実行してみる
- コードに積極的に変更を加えて自分の理解度をテストする
  - この場合も小さな変更から始める
- オープンソースコードはドキュメントがしっかりしていないことが多いので、コードを読んで理解したことをドキュメントに反映させれば良い

手本としてのコード

コードを手本として使う時に鍵となる考え方は「柔軟に対応せよ」ということ
まず適当なドキュメントがあるときは、それを読む
探索すべき対象が何であるかを具体的に意識しなければならない
- システムコール？アルゴリズム？コードシーケンス？アーキテクチャ？etc
- 目的が違えば探索の戦略も変化する
ブレイクポイントをおく、ログを出力する等、あるやり方で望むの結果がすぐに得られなければ、それをうち切って別のやり方を試すべき
目的のコードが見つかったら、関連しないコードは無視すること
- これが重要なポイントで、練習しなければならない
- オリジナルのコンテキストのままだとコードが良く理解できない時は、それを一時ファイルにコピーし、関連しない要素をすべて削除する

保守

バグの修正等が保守にあたる
この場面で鍵となるのは「ツールを使え」ということ
デバッガ、パケットダンプツール等

進化

新しい機能を追加したり、既存の機能を修正する、リファクタリングするなどの場合に鍵となる考え方は「コードの中から重要な部分を適切に選択すること」
- コードの中から興味を引く部分を特定する
- 到底の部分を分離してよく理解する
- 抜粋した部分とコードのの狩りの部分の関係を推察する
システムに新しい機能を実装する時に最初にすべきことは、類似した機能の実装を見つけ、それをこれから実装する機能のテンプレにすること
あとは、それが影響をあたえる領域を特定すること