とりあえず動くコードは書けるようになった。でも複数人でのチーム開発を前提とした保守性や拡張性、可読性などがあるコードの書き方が分かるかと聞かれると、悩んでしまう。そんなプログラマにおすすめの一冊です。
こういった"良いコードを書くための書籍でよくおすすめされる本にリーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニックもありますが、このプリンシプル オブ プログラミングという書籍はより抽象的な内容を網羅的に紹介している一冊になります。
リーダブルコードなどを読んでから、このプリンシプル オブ プログラミングに目を通してみると理解が進みやすいかもしれません。
##総論
自分自身、半年ほどプログラムを書いてきたのですが、依然として良いコードとは何かというものをまったく理解していませんでした。開発現場で先輩にコードレビューをしてもらった時に指摘されたことに対してなにを指摘されているのか分からないことを解消したい、また指摘される前にある程度どんなコードが良いのか自分で考えられる指針を持ちたいと思ったのでこの本を読みました。
良いコードを書くためにはどうすればいいのか、プログラマーとしてどう行動するのが良いのか、といったことが101の基本原則として、まとまっています。それらが章立てでまとめてある、かつ各プリンシプルには、どういうこと（what）、どうして（why）、どうやって（how）が載っているので、現場で言われる「ここの場面はこう書く」「ここは規約で決まっているからこう書く」というハウツーの裏にある、「そもそもどうあるべきか、それはなぜか」という点の知識を得ることが出来ます。この本から得られた知識は、今後開発現場で判断を迫られた時の良い指針となってくれるはずだと思います。
ただ、具体的なコード例は一切出てこず、抽象的な概念の説明なので、全く開発経験が無い方が読んでも理解出来ることは少ないと思われます。おそらく本の内容への理解はこれまで書いたコードの量に比例するので、 まったくのプログラミング初心者はこの本を読む対象者ではないでしょう。
##目次
第1章 前提 ～ プログラミングの変わらぬ真実 ～
第2章 原則 ～ プログラミングのガイドライン ～
第3章 思想 ～ プログラミングのイデオロギー ～
第4章 視点 ～ プログラマの観る角度 ～
第5章 習慣 ～ プログラマのルーティーン ～
第6章 手法 ～ プログラマの道具箱 ～
第7章 法則 ～ プログラミングのアンチパターン ～
##第1章 前提 ～ プログラミングの変わらぬ真実 ～
■プログラミングに特効薬はない
ソフトウェア開発において、突然問題が発生し、日常のプログラミングが混乱に陥ってしまうことがあります。
残念ながら、プログラミングにおいて起きる諸問題には、これさえあれば解決できるという特効薬は存在しません。
移行
■ソフトウェアは本質的に困難である
・複雑性 ソフトウェアは大きくて複雑
・同調性 ソフトウェアは実世界のものと接続され、使用されるために実世界と同調する
・可変性 ユーザのニーズにより仕様は絶えず変化する
・不可視性 ソフトウェアは概念の集積であり、不可視である。
■歴史に学ぶ
ソフトウェア開発の歴史とはその複雑さとの戦いです。
これまで培われてきたアイデアや手法を武器に、ソフトウェアの困難性と戦う必要があります。
■コードは設計書である
ソフトウェアにおける設計＝基本設計・要件定義～デバッグ
プログラミングは設計。
エンジニアが作ったコードは、ハードウェアの設計図に該当します。
改善を加えるのは、設計ではなくコードで、コードを直す必要があります。
そのためには、優秀な設計者(プログラマ)が必要。
プログラミングとは、仕様のコード化ではなく、仕様を改善する作業を含む、創造的な行為である。
##第2章 原則 ～ プログラミングのガイドライン
■プログラミングの「原則」
下記を見て、その意味を言えるものはいくつありますか？
「KISS」「DRY」「YAGNI」「PIE」「SLAP」「OCP」「名前重要」
■KISS コードをシンプルに保つ
・コードに余計なことをしない、コードを書く時に「単純性」「簡潔性」に最優先に価値を置くことで、コードの秩序を維持する。
・それが本当に必要なものなのか常に吟味する
・今必要なものだけをコードとして書く
・勝手に要件を加えない
■DRY コードを繰り返さない
・コードを抽象化することで可読性をあげる、コードの修正を簡単にする。
オブジェクト指向プログラミング、デザインパターンなどを使う
■YGNI それはきっと必要にならない
・ソフトウェアの変化予測 = 不可能
→ 今必要なものだけをコードにする。
・コードの予測は外れる
→現段階で不必要な機能は余計な複雑性を生む。
（汎用的なコード → 利用されないことが多い 無制限な汎用性の追求 → 不毛 使われない機能）
■PIE 意図の伝わるコードを書く
・コード → 人が読むもの（コンパイラが読むものではない。）
・ソフトウェアの動作を正確に把握するには、コードを読むしかない。
・コードを書く時間より、読む時間のほうが圧倒的に多い。
・コードは実行の効率性より、読むときの効率性のほうが大事。
■SLAP 抽象化レベルの統一
・コードを書く時は、高いレベルの抽象化概念と低いレベルの抽象化概念を分離するべきである。
・コードに要約性と閲覧性をもたらす。
■OCP オープン・クローズドの原則
・コードの振る舞いを拡張できる
・コードの振る舞いを拡張しても、その他のコードに影響を及ぼさない
・オブジェクト指向のポリモーフィズムなど
##第3章 思想 ～ プログラミングのイデオロギー ～
この章ではプログラミングの思想に関するプリンシプルが紹介されている。
■プログラミングセオリー
・コミュニケーション
コード ＝ コミュニケーションの場
コードとは、ドキュメントである。
コードにおいて、読んだ人が内容を理解し修正することができる ＝ コミュニケーション良好
常にコードを読む側の視点に立つことが重要。
いったんここまで
3章以降また追記予定です！