「プリンシプル オブ プログラミング」- エンジニアの視点 - 読書メモ

概要　

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

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

目次

凝集度

• モジュールは「純粋」に
• 混じりけのあるモジュールは脆い
• 高強度モジュールを目指す

　凝集度の一番高い機能的強度を持つモジュール作成を目指す。機能的強度を持ったモジュールの変更は、そのモジュールだけで処理できる。また、他のモジュールへの影響度も小さい。凝集度が低いと理解、保守、再利用の面でコードを利用しにくく、脆弱で、変更による影響を植えやすくなってしまう。

結合度

• モジュール間は「疎遠」に
• 相互依存モジュールは脆い
• 低結合モジュールを目指す

　結合が密なモジュールは互いに依存していまい、互いに影響してしまうので、様々な問題が発生する。例えば、結合しているモジュールに変更が必要になると、動作に影響が出たり、モジュールを利用する場合、結合しているモジュールも必要となるので、再利用しにくくなる。

直交性

• コードは独立させよ
• 直行コードは堅牢
• コードのレイヤー化

　直行しているコードは、片方を変更しても、他方に影響がないコード。直交性のあるコードを書けると、生産性の向上とリスクの削減につながる。

可逆性

• 「UNDO」な選択をせよ
• 最終決定などない
• 特定技術に依存しない

コードの臭い

• コードの吉兆を見逃すな
• 味覚はリファクタリングの必要条件
• 臭いの傾向を知る

　理解しにくい、修正しにくい、拡張しにくいコードを嗅ぎ分けリファクタリングしなければならない。臭いの傾向を知り、把握しておく必要がある。 

技術的負債

• 問題コードは「借金である」
• 問題コードとうまく付き合う方法
• 問題コードを管理する

　汚いコードは借金である。もし急務で書いた場合は、後に修正するよう管理が必要である。ドキュメントに残しておくのも一つの手段である。