「 プリンシプル オブ プログラミング 」のまとめ

# はじめに
書籍「[プリンシプル オブ プログラミング](https://www.shuwasystem.co.jp/book/9784798046143.html)」では、よいコードを書くためのプリンシプルをまとめています。
#### プリンシプルとは
プリンシプル（Principle）を直訳すると原理、原則、主義といった意味合いなりますが、本書では以下のように書かれています。
> プリンシプルとは、プログラミングの指針となる「前提」「原則」「思想」「習慣」「視点」「手法」「法則」などのことです
> 歴史の審査を受けて生き残った、よいプログラミングのためのエッセンス（「普遍的」「定説的」「本質的」な知識）とも言えます。

プリンシプルには「前提」「原則」「思想」「視点」「習慣」「手法」「法則」の7つがあり、それぞれは章ごとに分類されています。
<details><summary> 目次 </summary><div>

#### 第１章 前提 ～プログラミングの変わらぬ真実～
1.1 プログラミングに銀の弾丸はない
1.2 コードは設計書である
1.3 コードは必ず変更される

#### 第２章 原則 ～プログラミングのガイドライン～
2.1 KISS
2.2 DRY
2.3 YAGNI
2.4 PIE
2.5 SLAP
2.6 OCP
2.7 名前重要

#### 第３章 思想 ～プログラミングのイデオロギー～
3.1 プログラミングセオリー
3.2 【プログラミングセオリーを支える3つの価値1】コミュニケーション
3.3 【プログラミングセオリーを支える3つの価値2】シンプル
3.4 【プログラミングセオリーを支える3つの価値3】柔軟性
3.5 【プログラミングセオリーを実現する6つの原則1】結果の局所化
3.6 【プログラミングセオリーを実現する6つの原則2】繰り返しの最小化
3.7 【プログラミングセオリーを実現する6つの原則3】ロジックとデータの一体化
3.8 【プログラミングセオリーを実現する6つの原則4】対称性
3.9 【プログラミングセオリーを実現する6つの原則5】宣言型の表現
3.10 【プログラミングセオリーを実現する6つの原則6】変更頻度
3.11 アーキテクチャ根底技法
3.12 【アーキテクチャ根底技法1】抽象
3.13 【アーキテクチャ根底技法2】カプセル化
3.14 【アーキテクチャ根底技法3】情報隠蔽
3.15 【アーキテクチャ根底技法4】パッケージ化
3.16 【アーキテクチャ根底技法5】関心の分離
3.17 【アーキテクチャ根底技法6】充足性、完全性、プリミティブ性
3.18 【アーキテクチャ根底技法7】ポリシーと実装の分離
3.19 【アーキテクチャ根底技法8】インタフェースと実装の分離
3.20 【アーキテクチャ根底技法9】参照の一点性
3.21 【アーキテクチャ根底技法10】分割統治
3.22 アーキテクチャ非機能要件
3.23 【アーキテクチャ非機能要件1】変更容易性
3.24 【アーキテクチャ非機能要件2】相互運用性
3.25 【アーキテクチャ非機能要件3】効率性
3.26 【アーキテクチャ非機能要件4】信頼性
3.27 【アーキテクチャ非機能要件5】テスト容易性
3.28 【アーキテクチャ非機能要件6】再利用性
3.29 7つの設計原理
3.30 【7つの設計原理1】単純原理
3.31 【7つの設計原理2】同型原理
3.32 【7つの設計原理3】対称原理
3.33 【7つの設計原理4】階層原理
3.34 【7つの設計原理5】線形原理
3.35 【7つの設計原理6】明証原理
3.36 【7つの設計原理7】安全原理
3.37 UNIX思想
3.38 【UNIX思想1】モジュール化の原則
3.39 【UNIX思想2】明確性の原則
3.40 【UNIX思想3】組み立て部品の原則
3.41 【UNIX思想4】分離の原則
3.42 【UNIX思想5】単純性の原則
3.43 【UNIX思想6】倹約の原則
3.44 【UNIX思想7】透明性の原則
3.45 【UNIX思想8】安定性の原則
3.46 【UNIX思想9】表現性の原則
3.47 【UNIX思想10】驚き最小の原則
3.48 【UNIX思想11】沈黙の原則
3.49 【UNIX思想12】修復の原則
3.50 【UNIX思想13】経済性の原則
3.51 【UNIX思想14】生成の原則
3.52 【UNIX思想15】最適化の原則
3.53 【UNIX思想16】多様性の原則
3.54 【UNIX思想17】拡張性の原則
3.55 UNIX哲学
3.56 【UNIX哲学1】小は美なり
3.57 【UNIX哲学2】1つ1仕事
3.58 【UNIX哲学3】即行プロトタイプ
3.59 【UNIX哲学4】効率性より移植性
3.60 【UNIX哲学5】データはテキスト
3.61 【UNIX哲学6】レバレッジ・ソフトウェア
3.62 【UNIX哲学7】シェルスクリプト活用
3.63 【UNIX哲学8】対話インタフェース回避
3.64 【UNIX哲学9】フィルタ化

#### 第４章 視点 ～プログラマの観る角度～
4.1 凝集度
4.2 結合度
4.3 直交性
4.4 可逆性
4.5 コードの臭い
4.6 技術的負債

#### 第５章 習慣 ～プログラマのルーティーン～
5.1 プログラマの3大美徳
5.2 ボーイスカウトの規則
5.3 パフォーマンスチューニングの箴言
5.4 エゴレスプログラミング
5.5 1歩ずつ少しずつ
5.6 TMTOWTDI

#### 第６章 手法 ～プログラマの道具箱～
6.1 曳光弾
6.2 契約による設計
6.3 防御的プログラミング
6.4 ドッグフーディング
6.5 ラバーダッキング
6.6 コンテキスト

#### 第７章 法則 ～プログラミングのアンチパターン～
7.1 ブルックスの法則
7.2 コンウェイの法則
7.3 割れた窓の法則
7.4 エントロピーの法則
7.5 80-10-10の法則
7.6 ジョシュアツリーの法則
7.7 セカンドシステム症候群
7.8 車輪の再発明
7.9 ヤクの毛刈り
</div></details>

コードをよりよくするための様々なプリンシプルが出てくるのですが、本記事では簡単なまとめを記述します。

# 要約
当書を読んで、コードを書く上で大きく3つの事柄を意識するようになりました。
それは「**他人が読む**」「**シンプルに書く**」「**修正を容易にする**」ということです。

例として「原則」のプリンシプルで以下のものがあります。
<!--
- KISS
    - 英 : Keep It Simple, Stupid
    - 日 : 簡潔かつ単純にしておけ
- DRY
    - 英 : Don't Repeat Yourself
    - 日 : 繰り返すな
- YAGNI
    - 英 : You Aren't Going to Need It
    - 日 : それはきっと必要にならない
- PIE
    - 英 : Program Intently and Expressively
    - 日 : 意図を表現してプログラミングせよ
- SLAP
    - 英 : Single Level of Abstraction Principle
    - 日 : 抽象化レベルの統一
- OCP
    - 英 : Open-Closed Principle
    - 日 : 開放・閉鎖原則
- 名前重要
    - 英 : Naming is important
-->
|プリンシプル名|英|日|
|---|---|---|
|KISS|Keep It Simple, Stupid|簡潔かつ単純にしておけ|
|DRY|Don't Repeat Yourself|繰り返すな|
|YAGNI|You Aren't Going to Need It|それはきっと必要にならない|
|PIE|Program Intently and Expressively|意図を表現してプログラミングせよ|
|SLAP|Single Level of Abstraction Principle|抽象化レベルの統一|
|OCP|Open-Closed Principle|開放・閉鎖原則|
|名前重要|Naming is important||

コードは書く時間より読む時間の割合が大きいという事実に基づき、コードは読みやすさを重視します。
上記のプリンシプルに基づくことでよりシンプルなコードになるのではないでしょうか。

# 最後に
すべてのプリンシプルについて触れたわけではないですが、プリンシプルを知ることでより良い開発経験ができるのではないでしょうか。
コードを書いたことはあるがチームでの開発経験はない方、また綺麗なコードを書きたい方に当書をおすすめします。