#はじめに#
プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則を読んだので第１章と第２章の内容をまとめました。
#第１章 前提 〜プログラミングの変わらない真実〜
##1.プログラミングに銀の弾丸はない
ソフトウェア(プログラミングの成果物)は本質的に困難であり、以下の４つの性質を持ちます。
1. 複雑性：構成要素間の複雑な依存関係がある。
2. 同調整：複雑な実世界に接続するため同調しなければならない。
3. 可変性：ユーザの要求に対応し変更しなければならない。
4. 不可視性：ソフトウェアは概念の集合なので目に見えない。
よってプログラミングは本質的に困難なものなので、簡単に上達するものではありません。
##2.コードは設計書である##
ハードウェアとソフトウェアの開発の手順はこのようになっています。
ハードウェアにおける設計図はソフトウェアのコードに対応します。
つまりコードは設計書であるので、プログラミングを始めるときは設計に長い時間を掛けず、できるだけ早くコードを書き始めましょう。
##3.コードは必ず変更される##
プログラムを書いたあとに、そのコードは必ず修正されます。
例えば、
・ユーザの要望
・障害の発生
・新規開発のプログラミング(前日のコードの修正)
などです。
特に前日のコードの修正は毎日訪れるので、変更に強い(読みやすい)コードを書くようにしましょう。
#第２章 原則〜プログラミングのガイドライン〜
##1.KISS(Keep It Short and Simple)##
コードはシンプルに保ちましょう。
シンプルなコードとは、
・構成する要素がシンプル
・各要素が担う責務が最小限
・各要素同士の関連がシンプル
なコードのことです。
コードにおいて**「より少ないことは、より豊かなこと」**であるので、今書いているコードは本当に必要かを考えてシンプルなコードを書きましょう。
##2.DRY(Don’t Repeat Yourself)##
コードを抽象化し、コードのコピペをしないようにしましょう。
具体的な抽象化方法としては、オブジェクト指向やデザインパターンです。
また、抽象化した関数などについてですが、**「一つの場所に一つの事実」**という考えをもつことが大事です。
##3.YAGNI(You Aren’t Going to Need It)##
コードは必要最低限作るようにしましょう。
つまり、汎用性よりも単純性を意識しましょう。
##4.PIE(Program Intently and Expressively)##
コードを書くときは、「書きやすさ」よりも**「読みやすさ」**を重視しましょう。
読みやすいコードを書くと、コメントで説明しなくても分かりやすいコードになります。コメントを書く場合、コードは「What」と「How」を伝えるものなので、コメントは「Why」を伝えましょう。
##5.SLAP(Single Level of Abstraction Principle)##
コード(関数等)のレベルを合わせることで**「要約性」と「閲覧性」**をもたらします。
具体的には関数を構造化し、自身より１段低いレベルの関数を呼び出すようにします。**最も低水準な関数は、名前で意図を伝えるためなら１行でもOKです。**行数の少ない低水準な関数をたくさん作ったほうがいいと思います。
##6.OCP(Open-Closed Principle)##
コードの変更を波及させないように、複数のコードの間にはインタフェースを作るようにしましょう。
##7.名前重要(Naming is important)##
コードで命名は最重要課題です。
プログラミングで一番大変なのは命名といっても過言ではないかもしれません。
名前の付け方としては、
・より多くの情報を詰め込む。
・他の意味と誤解されないようにする。
・名前は「効果」と「目的」を説明する。
・命名したものを使用するテストを先に書く。
・発音可能なものにする。
・検索可能なものにする。
などがあるようです。
具体的な命名方法は、頻出の英単語をまとめているサイトやcodicを参考にするといいと思います。
#まとめ#
適当にプログラムを書いていると、「半年前に書いたプログラムが読めない！」などの事態が起こるかもしれないので良いプログラムを書きましょう。