「プリンシプル オブ プログラミング」- 思想 - 読書メモ

概要　

　今回、コードを綺麗に書けるよう、その概念を学ぶためにプリンシプル オブ プログラミングという書籍を読んだ。101個の原則が読みやすくまとめられており、財産になる本だった。この記事では、私自身が大事だと思ったことをメモしていきたいと思う。

プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則

目次

コミュニケーション

• コードはコミュニケーションの場
• 円滑な開発は円滑なコミュニケーションから
• コードを読む側の視点に転回

　他の人が読むという事も考えながらコードを書く。開発では、書くことよりも、読むことの方が時間がかかる。読みやすいコードを書くことによって、読む時間が短くなり、コスト削減につながる。 

シンプル

• コードの複雑性は排除
• コードの複雑性は禍根
• コードの大事な部分を仕分ける　

柔軟性

• コードの変更が容易
• コードは必ず変更される
• コードの拡張性を上げる

繰り返しの最小化

• 重複を排除
• 修正の影響を局所化
• コードを分割して管理

 　コードが重複しているということは、コードを一つにまとめて簡潔に書く

対称性

• コードに一貫性をもたせる
• 他の部分にも類推できる
• 同じことは同じ表現で行う

　 コードに一貫性をもたせる事で、他人がみても理解しやすくなる。という考え方もある

情報隠蔽

• 必要ないものは見せない
• 関連を整理してシンプルに
• 内側を隠蔽する

ログなど、必要の無いものは見せないようにする。たとえばgithubに上げる時など、.gitignoreというファイルに見せたくないファイルを指定することができる。

ポリシーと実装の分離

• 「ポリシー」と「実装」は混ぜない
• 「実装」は安定だが「ポリシー」は不安定
• 「ポリシー」と「実装」は別モジュール 

参照の一点性

• 定義は一度きり
• 副作用のないプログラミング
• 「単一代入」とする

効率性

• リソースをうまく使う能力
• リソースは限られている
• リソースを積極的に活用する

テスト容易性

• 効果的にテストする能力
• テストの品質が本体の品質
• テストも考慮した品質設計 

 　テストが無いコードは負債であり、負債を返さないままだと後に負債を返すだけで手一杯になり、新たな開発ができなくなる。 

再利用性

• 再利用「する」「される」能力
• できる限り「作らない」で開発効率化
• 「プラグイン」

　できる限りコードを書かずに、使えるものを使う。それが効率化につながる 

安全原理

• 安全性にこだわる
• 大事故の発展を防ぐ
• 安全サイドにコードを書く 

明確性の原則

• コードを明確にする
• コードを読むのはマシンではなく人
• 明確でなければ改善する

経済性の原理

• プログラマの時間を大切に
• プログラマの時間は貴重
• プログラマに投資をする

　コストがかかるからといって効率化のためのソフトや環境を与えないのは、かえって効率化を阻み、業務の時間的コストが増加する。なのでプログラマには投資をすべきである。

最適化の原則

• 早いコードより正しいコード 
•  早い段階での「速いコード」は設計を破綻させる
• 正しくしてから速くする

　正しく無ければ、早くても意味がない。まずは、正しくコードを書く技術をつける事が大事である。

即行プロトタイプ

• できるだけ早くプロトタイプ着手
• 試行錯誤なしで良いものは作れない
• プロトタイプで確度を高める

　とりあえず最低限形にすることで、全体像や改善点が見えてくる。クライアントも全体像を想像しやすくなる。

効率性より移植性

• 効率性より移植性を優先
• ソフトウェアの価値を持続
• ハードウェアに依存しないコードを書く