プリンシプルオブプログラミング ～ プログラミング原則を読んで ～

はじめに

プリンシプルオブプログラミング―３年目までに身につけたい一生役立つ１０１の原理原則
https://www.kinokuniya.co.jp/f/dsg-01-9784798046143
上記の本を読み、
2章「プログラミングの原則 ～プログラミングのガイドライン～」部分を
自分なりに解釈して、まとめました。

実はプログラミング歴そこそこあるけど、知らない原則もあった…🤯
という方のお役に立てればいいなぁ～と思って書いてます🐢

１．KISS　～ 簡潔かつ単純にしておけ ～

Keep It Short and Simple.

コード書く時はどんな時でも、コードは常にシンプルしておこう！！　
これに尽きます。

コードを自然に任せて修正しちゃうと、どんどん好き勝手に改変され、複雑になります。
そして誰も理解できないコードへ……なんて、想像しただけで恐ろしいですね。
一方で、シンプルなコードは誰でも読みやすく、改修もテストもしやすいです👌

🐏 ＜ シンプルなコードを日頃から意識する！

余計なことはしないように、日頃から意識します。

• 余計になりやすい箇所
  1. 新しく覚えた技術を使いたい！
  2. 将来の必要に備えて、余分なコードも書いちゃう💦
  3. 勝手に要件を加えてしまう

↑をやると、余計なコミュニケーションコストも増えて、開発速度もダウン⇩します。
どんなコードでも必ず修正が入るので、長い目で見てもメンテナンスしやすくしましょう。

２．DRY ～ 繰り返すな ～

Don't Repeat Your Self.

同じコードを重複して書かないこと。コピペは厳禁！！

他のクラスで似たような処理をやってるからと、コピペして少しだけ改変してっ！というコードは🙅！
重複していると、以下のようなデメリットで「コードの改善が面倒」となります。

1. 単純にコードの量が増えるので、「読む作業」も増える。
2. レコードの修正が複数個所にも及ぶので、面倒くさい。
   • まったく別の処理で、修正の要否の判断もしないといけない…。

🐏 ＜ 重複コード ⇒ 関数・抽象化をしちゃおう！

似たような処理は 「関数化」・「抽象化」 を徹底します。

メリット

1. コードの量が減って、「読む作業」も減る。
2. 同じコードが1つに集約されるので修正作業も楽。品質も担保される。
3. 新しい機能を追加する時、抽象化しているとコードの再利用ができる。

ただし、既にリリースされている処理を抽象化するのは、デグレ発生のリスクがあります！
が、長い目で見ると必ず有利に働きます🦕

（個人的な感想）
仕事では、案件内容とは関係ない処理を修正するので結構避けられがちですが、、
リーダーに打診をしておくのは良いかもです。（どこかのタイミングで修正できるので）

３．YAGNI ～ それはきっと必要にならない ～

You Ain't Gonna Need It.

コードは必要最低限にしましょう。「ヤグニ」で有名です。
「たぶん必要になるかも！」「とりあえず書いておこ！」ではなく、今必要なものだけを書きます。

🤔 ＜ いや、色々な事象に備えて用意しておいても良いんじゃない！？
😭 ＜ 大抵の場合は結局利用されないことが多いです…。

何故このコードを書いているのか、時間が経つと理由も必要になるので、
せっかく作っても邪魔者扱いされてしまうことも…。

🐏 ＜ コードは「今必要なもの」だけにしよう！

色々用意すると全体が複雑になるので、単純性を意識しましょう！
コード以外も、ソフトウェアの機能も当てはまります。

４．PIE ～ 意図を用意してプログラミングする ～

Program Intently and Expressively.

コードは、「人」が読みやすいように書く！　という原則です。
ソフトウェアの動作を正確に知るためには、コードを読むしかないのです。
そのため、どういった意図でコードを書いたか、コードに分かりやすく用意する必要があります。

🐏 ＜ コードは沢山の人に読まれることを意識する！

コードを書く時間は短いですが、読まれる時間は圧倒的に多いです。
常に人に読まれている、他の人が読んでも理解できるコードを心掛けましょう👌

• ポイント
  • 補足が必要な部分は、コメントに残すようにする。
  • コードを書く時に、別の書き方をして、自分の技術をアピールしない。
    • この部分は、KISSと同様。
  • 自分や他人のコードを読んでいて、分かりにくければ書き直す。

５．SLAP ～ 抽象化レベルの統一 ～

Single Level of Abstraction Principle.

コードを書く時、高いレベルと低いレベルの抽象化概念に分離し、
このレベルを揃えるようにしていく～という原則です。
レベルが揃っていると、結果的に書籍のようになります。

サンプルコード（※本のコードから引用しております）

function 高水準(){// レベル1の目次
    中水準1();
    中水準2();
}
function 中水準1(){// レベル2の目次-1
    低水準1();
    低水準2();
}
function 低水準1(){// 本文内容
    // 処理
}
function 低水準2(){// 本文内容
    // 処理
}
function 中水準2(){// レベル2の目次-2
    低水準3();
}
function 低水準3(){// 本文内容
    // 処理
}

• 最高水準～中間水準の処理：書籍の目次
• 最低水準の処理：書籍の本文内容

↑のように、コードが揃った関数に分かれていると、流れが理解しやすくなります。
反対に、コードを読んでいて急に抽象度が変わると、コードの流れが切れて読みづらくなります😰

🐏 ＜ コードを伝わりやすい単位に分解して、構造化する！

コード＝処理を意図の伝わりやすい単位の関数に変換しましょう。
その後に、自分より1段階低いレベルの関数を呼び出す処理を行っていきます。（複合関数）

複合関数の中では、色々な抽象レベルの関数は呼ばないように注意しましょう

６．OCP ～ オープン・クローズドの原則 ～

Open Closed Principle.

コードは以下2つの属性を同時に満たすように、設計します。

1. 🏙️ 拡張に対して開いている。
   • コードの振る舞いを拡張できる！
2. 🚪 修正に対して閉じている。
   • コードの振る舞いを拡張しても、他のコードは影響を受けない。

↑の原則が守られていれば、コードの変更に柔軟に対応しやすいです💪
「硬い」設計ではなく、「柔らかい」設計が大切です🧈

🐏 ＜ インターフェースを積極的に使用する！

ある機能を持ったモジュールを直接呼び出す時の例です。
（本の図から、内容は引用しております。）

クライアントとサーバの間にインターフェースを作ってあげると…？

機能追加を柔軟に行うことがしやすくなります🌹

７．名前重要

Naming is important.

コードに名前を付ける行為、名前そのもの＝プログラミングの最重要課題です💥
ふさわしくない名前を付けると、プログラマが正しく処理や要素を理解していないことになります。
名前自体も、プログラマ同士がコミュニケーションするために、適切な名前が必要です。

名前は、コードの読み手への UI（ユーザインタフェース） に該当します。

• 適切な名前がつけられている🐻
  • 関数名を見ただけで、その処理の概要が頭に入りやすい。
  • コードを書いている時、その関数の適切な利用方法がすぐに理解できる
    • 関数を呼び出すのが簡単！
• 適切な名前がつけられていないと…。
  • 関数名を見ても、処理の内容が分からず、理解するために内部の解析時間が掛かる。
  • コードを書いている時、同じく内部の解析が必要。。
    • 作成しても関数名が悪いと読みづらくなる。

🐏 ＜ コードはまず「名前」を決めよう！

プログラミングは、まずは第一に「名前」から入りましょう🐻
「読み手」「使う側」の視点に立ち、分かりやすい名前を心掛けることが大切です。
（読み手の視点は、PIEとも被るかもですが）

• ポイント
  • 名前は誤解されることのないように気を付ける。
  • 名前は「効果」と「目的」を説明し、簡潔に伝える。
  • 名前をチェックする場合は、処理を書く前にテストを書く。
    • コードの使用者の目線に立つ。
  • 名前は検索・発音可能な単語にする。

おわりに

以上、まとめでした。
実際に自分でも出来ていないと感じる部分、SLAPのレベルの統一とか意識しないとなと感じました。
今後詳細設計・実装していくときは、関数のレベルに注意していきたいと思います！

シンプルにまとめるKISSも、コードに限らずこういった記事にも必須ですね～。
何度も記事を投稿して、技術を磨いていこうと思います💪

少しでも何かの参考になりましたら幸いです。