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

概要　

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

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

目次

ブルックスの法則

• 要員追加は「火に油」
• 「人」と「月」は交換不可能
• リスケジュール

　要員を追加すると、新規で入ってきた人に説明するためのコストがかかる。そのコストを元々行なっていた人に使うべきである。そのためにはリスケジュールは必要である。

コンウェイの法則

• アーキテクチャは組織に従う
• アーキテクチャはコミュニケーションに従う
• アーキテクチャ設計後に組織編成せよ

割れた窓の法則

• 悪いコードは「蟻の一穴」
• 悪いコードは邪心を引き出す
• コードは清潔に保つ

　悪いものが一つでもあると、そこの環境はどんどん悪くなっていく。カビが映えるとどんどん広がっていくようになる。そのような事を防ぐために、コードは新鮮に保つ必要がある。

 
エントロピーの法則

• コードは自然に腐っていく
• コードは無秩序へ向かう
• コード腐敗の兆候をつかむ

　コードは生肉のように時間が経つにつれ腐っていく。腐ったものがコード内に溜まっていき、保守しづらくなっていく。少しの変更でも、多くの労力が必要となり、再設計を余儀なくされる。

80-10-10の法則

• プログラミングに万能薬はない
• プログラミングの問題領域は広すぎる
• ツールの使用は適材適所

　ユーザの求めることの80％は、実現できる可能性が高く、10％は実現可能だが相当な努力が必要になる。最後の10％は実現不可能であるという比率。

ジョシュアツリーの法則

• 名前がないものは見えない
• 名前を知ることで存在を知る
• ユビキタス言語を使用する

セカンドシステム症候群

• 二番目のリリースは機能過多
• 慣れると多機能主義へ
• ユーザを考える

　二番目品質にリリースするバージョンは、機能を入れすぎてしまい品質が悪く、機能の使い勝手が悪くなってしまう傾向がある。1つめのバージョンでは、未知の事が多く、リスクが大きい為、慎重に物事を判断することになる。しかし、2番目のバージョンだと知っていることが多く、保留していたものを含めて多くのものを盛り込んでしまう。

車輪の再発明

• すでにあるのに作る
• 車輪を知らない、作りたい
• 車輪以外に注力する

　すでにあるものを使わずに、新しく作り出すのは時間の無駄である。すでにあるものの存在を知らないのは勉強不足である。同じチームのエンジニアにヒアリングして、あるものの存在が分かることもある。

ヤクの毛刈り

• 本当の問題にたどり着かない
• トラブルは芋づる式
• 早々に切り上げる

　問題を深堀しすぎて路頭の迷ったときは、まず何が目的だったのか思い出る。道がずれている、時間やコストをと見合わないと感じた場合は作業を止め、別の道を探す。また、同じことでメンバーがはまらないようにドキュメントに残しておくことも重要。