【感想・ネタバレ】プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則のレビュー

上田勲

一通りプログラミングができるようになった。しかし、読みにくい、遅い、頻繁にエラーが発生する、書いたコードを修正すると動かなくなる等々、なかなか「よいコード」を書けないとお悩みではありませんか？ 本書は、よいコードを書く上で指針となる前提・原則・思想、つまり「プリンシプル」を解説するプログラミングスキル改善書です。初心者向けの書籍では絶対に説明しない、古今東西のプログラマーの知恵をこの一冊に凝縮しました！

[ブクログ · ★★★★★]

プログラミングをやるためにまず、世の中一般で広く知られている原則（常識？）を知らなければならないと思い読んでみた。三年目を微妙に超えているが、プログラミングに本格的に触れるようになってからはまだ三年以内なので良しとする。
これを読むだけでできるプログラマになれるわけではないが、できるプログラマになるために最低限読まなければならない本。SOLIDのようなコーディングの原則から割れ窓理論などの心構えのような内容まで、幅広く扱っている。それらが、what?->why?->how?(->関連->発展)といった形式で紹介されている。また、howにあたってはコード例を出したりせずにあえて図などのイメージに留めているなど、「原則」を理解しやすくなるように工夫されている。
良いプログラマと言われる人がどんな目線で開発をするかその視座に触れることができたと思う。確かにSOLIDなどは定番でネットでも調べればすぐ出てくるがその場合単独での理解になるので、「この原則とあの原則似てるな/対立してるな」とかがわからない（そのわからないというのが初心者の証であって、つまるところ入社三年目までということなのだろうけども）。
しかしこの本ではどの原則が関係しているまたは対立しているのかなど横断的に扱っているおかげで腑に落ちやすい。原則という抽象的な概念の結びつきが生まれやすい。そのため、記憶に残りやすくなるだろうし、実践の時に「これに気を付けなければ、一方でこの点でトレードオフがある」など思考が展開しやすくなると思う。つまり、原理原則のインデックスを頭の中に作ることができる本。
できる人なら経験的にわかっているし身についていることだろうけども、その道半ばにいる人たちには転ばぬ先のなんとやら、ショートカット？アクセル？を提供してくれる良い本だと思う。
ちなみにそれぞれの原則に出典となる書籍が載っているので、より深く知りたいなと思ったらそれらを辿っていくという使い方もできるので、おすすめ。

[ブクログ · ★★★★☆]

## 直行性

直交は、幾何学において、グラフの座標軸のように直角に交わる2つの線分の性質です。

ある点を、X軸に平行に動かしていった時、Xの値は変化しますが、Yの値は変化しません。

つまり、Xの変更は、Yに何ら影響を与えません。

コードは、この直交性を満たすようにします。

つまり、あるコード同士が「独立性」「分離性」を持つようにします。

`2つ以上のコードの塊があり、片方を変更しても他方に影響を与えない場合、それらは直交しています。直交しているコードは、変更に強いコードです。`

## パフォーマンスチューニング

1. 最適化の必要性を証明する
2. パフォーマンスを計測し、ボトルネックを特定する
1. 処理時間の大半を占めている部分のことを「ホットスポット」と呼ぶ
3. ボトルネックのコードを最適化する
4. パフォーマンスを計測し、最適化の効果を確認する
5. 最適化したコードの動作に問題がないことを検証する

## エゴレスプログラミングの十戒

- 自分自身も間違いを犯すということを理解し、受け入れる
- 書いたコードは自分自身ではない
- どれほど極めたいと思っても、上には上がいる
- 相談なしに、コードを書き直しません
- 自分よりもスキルが劣る人にも、尊敬と敬意と忍耐を持って接します
- 世界で唯一変わらないことは、変わるということ
- 本当の権威は、地位ではなく、知識から生じます
- 信じるもののために戦います。ただし、負けは潔く受け入れます
- 部屋に篭りきりはいけません
- 「人に優しく、コードに厳しく」して、人ではなくコードを批評します

## 論理的思考のコツ

- 瞬時に答えを得ようとする態度は誤りです。瞬時に分からなくても考え続けましょう
- 既に考えたことを、しっかり覚えておきましょう。そうすれば同じことを何度も繰り返し考える「思考のループ」に入り込んでしまうことが避けられます
- 覚えておくのは大変なので、書きながら考えるようにしましょう。書きながら考えることは、副次効果もあります。書いて、目で見えるようにすると頭の中だけで考えていたときには分からなかったものがなぜかわかるようになります。

## 関数側では、引数の調整は行わない

- 呼び出される関数の側で、渡された引数の調整はしてはいけない
- 呼び出される関数側は、契約に基づいて「安心して」引数を使うべき。その結果、コードがシンプルになる

## エラー処理における「正当性」と「堅牢性」

- 正当性とは、不正確な結果を決して返さないことを意味する。不正確な結果を返すくらいなら、何も返さないほうがまだ良いという考え方
- 堅牢性とは、実行を継続できるように手を尽くすこと。不正確な結果がもたらされることがあっても、実行を継続できれば構わない、という考え方

## 割れた窓の法則

- ソフトウェアの「割れた窓」、つまり「悪い設計」「間違った意思決定」「悪いコード」を放置すると、それがどんなに小さいものでも、ソフトウェア全体をごく短期間で腐敗させることになる

## コード腐敗の兆候を掴む

『硬さ』

- 硬さとは、変更の難しさのこと
- たった一つの変更で、それと依存関係のあるモジュールを連鎖的に変更しなければならない場合、「硬い」設計のコードと言える

『脆さ』

- たった一つの変更によって、他の多くの部分が壊れてしまう度合いのこと。
- 脆いコードは、変更した部分とは全く関連のない箇所まで壊れてしまうことがある

## 80-10-10の法則

- 高水準のツールや言語によってソフトウェアを開発すると、ユーザーの求めることの80%は驚くほど短時間で実現することができる
- しかし、残り20%のうち、10%は実現可能だが、相当な努力が必要となる
- さらに最後の10%は完全に実現が不可能

## 80-20の法則

- 障害の8割は、2割のコードに集中している
- 処理にかかる時間の8割は、2割のコードが締めている