名著のダイジェスト
2017/02/04 17:32
8人中、8人の方がこのレビューが役に立ったと投票しています。
投稿者：ルイージ - この投稿者のレビュー一覧を見る
この本の最大の特徴は、大量の出典や関連書籍が、巻末にまとまってるのではなく、各項目それぞれに書いてあることです。例えば「アジャイルソフトウェア開発の奥義」とか「プログラマが知るべき97のこと」「オブジェクト指向のこころ」「達人プログラマー」などなど、IT分野で名著と言われている書籍が多数上げられています。著者は技術書だけで800冊以上読んだそうなので、その中から選ばれた名著のエッセンスを抽出してまとめていて、大変お得感があります。本来ならこれらの関連書籍を全部読めば勉強になるのですが、初心者がゼロから読み始めたら何年もかかってしまいますから、この本でエッセンスを掴んでおくと指針になるし、次に読む本を選ぶ際にもハズレがなくなると思います。
7人中、7人の方がこのレビューが役に立ったと投票しています。
投稿者：Kircheis - この投稿者のレビュー一覧を見る
プログラミングの原理原則を「プリンシプル」と括って紹介している。
抽象度の高い情報に終始しており、具体的なコード例などはない。
プログラミング技術書としては、あまり見ないタイプの本である。
ただ、プログラマ一として「知っておかなければならない知識」が
かなりの網羅率で提示されており、かつ各々非常に丁寧に解説されていた。
とくに、各プリンシプルについて、必ず「なぜそれが必要か」が明確に説明されている。
これがあるので、抽象寄りの情報ながら、「実際に使える」情報となっている。
（「How to本」ならぬ「Why本」である。）
しかも、抽象度が高い分、適用範囲は果てなく広い。
読むにつれ、視点の高さが、いやがおうにも上げられる。
問題を（不遜な意味でなく、視野的な意味で）上から見下ろせるようになる。
その高さは、位置エネルギーであるかのように、現場で具象に落とした時の効果は計り知れない。
プリンシプルは101個あるので、相当に投資対効果の高い本だ。
本書で「抽象」、リーダブルコードで「具象」を押さえて、
あとはそれらの観点を持って経験を積めば、自然と「よいプログラマー」になっていくだろう。
確かに、プログラマ必携の書だ。
投稿元：
レビューを見る
プログラミングに関する原理原則をまとめた本。
いずれも基礎知識として知っておいた方が良い内容なので、目次を読んで知らないものが多いなら読むと良いと思う。
また、各項目には参考書籍が載っているため、より詳しく知りたい時には良書への索引集として役立つ。
ただし、各項目数ページの記述であり、具体的なコードもないので、全くゼロからこの本だけで原理原則を理解できるとは思わない方が良い。
投稿元：
レビューを見る
プログラミングに関する原理原則についてまとめた本。
まとめたというより詰め込んだといったほうが正しいかもしれない。こういう巷で言われている原理原則について知りたい人にはいいかもしれないけど、個人的にはもう少し絞ってもいいんじゃないかと思った。プロローグにも書いてあるけど、重複している箇所もあるわけだし。
ただ、これだけの量を一人の著者が書き上げたのはすごい。どれぐらい時間かかったんだろう。ところどころ、翻訳書を読んでいるような感覚だったけど。
『ジョシュアツリーの法則』という言葉を初めて知った。名前を知ることで存在を意識するという法則らしい。バズワードとかも、名前をつけること自体が案外大事なのかも。
投稿元：
レビューを見る
プログラミングの原理・原則に重点をおいて、プログラミング初学者がどのようにコードを書いていけばいいのかが細かく記されている。
ただ、あくまで原理・原則なので、参考となるコードを用いて解説するような箇所はあまりない。
（僕自身初学者なので）個人的に、第４章のモジュールについての記述は参考になった。
投稿元：
レビューを見る
適用範囲を広くするために抽象的に書いているために、コードが書いていないというのは分かるけれど、もう少しコードがあった方が理解しやすいのにと思う箇所もあり。
投稿元：
レビューを見る
読み易く、メンテナンスし易いコードを書く。
最初にきっちりやれば後でお釣りがくる。
ってことだね。
きっとメンテナンスで苦労した人じゃないと理解できないね。
「身につけたい」ではなく「身に着けさせたい」で指導者のテキストにすると良いかも。
こんな事をコードレビューで指摘できる先輩になると頼りにされることでしょう！
そもそもコードレビューやってるかい？？
投稿元：
レビューを見る
101の原理原則が重複していたり、知っているものばかりであった。
重複のことは前書きにも書いてあったが、
実際読んでみると繰り返すはくどく感じる。
投稿元：
レビューを見る
読んでいるのと読んでいないのとでは大違い。ただし、実際に経験を積まないと実感できない部分もあると思います。
投稿元：
レビューを見る
最初の章だけでも、若手に読んでもらいたい。
後半は少し経験がないと何言ってるのかわからないと思う。
投稿元：
レビューを見る
ソフトウェアの現場や書籍などて、繰り返し言われている先人たちの知恵をまとめた本。この本でも述べられているように、若干の重複もあるし、表面上矛盾した主張が出てきていたりもする。そんなある意味公平なスタイルだからこそ、幅広く読まれるべき本だと思う。101個紹介されている原理原則には、それぞれに対する出典書籍と関連書籍が記載されていて、深堀したくなったときも辿りやすい。
「3年目までに身につけたい」と副題にあるので新人以外は手に取りにくいかもしれないが、むしろ色々な現場を経験した人の方がそれぞれの原理原則の含蓄のようなものを感じられそう。
投稿元：
レビューを見る
## 直行性
直交は、幾何学において、グラフの座標軸のように直角に交わる2つの線分の性質です。
ある点を、X軸に平行に動かしていった時、Xの値は変化しますが、Yの値は変化しません。
つまり、Xの変更は、Yに何ら影響を与えません。
コードは、この直交性を満たすようにします。
つまり、あるコード同士が「独立性」「分離性」を持つようにします。
`2つ以上のコードの塊があり、片方を変更しても他方に影響を与えない場合、それらは直交しています。直交しているコードは、変更に強いコードです。`
## パフォーマンスチューニング
1. 最適化の必要性を証明する
2. パフォーマンスを計測し、ボトルネックを特定する
1. 処理時間の大半を占めている部分のことを「ホットスポット」と呼ぶ
3. ボトルネックのコードを最適化する
4. パフォーマンスを計測し、最適化の効果を確認する
5. 最適化したコードの動作に問題がないことを検証する
## エゴレスプログラミングの十戒
- 自分自身も間違いを犯すということを理解し、受け入れる
- 書いたコードは自分自身ではない
- どれほど極めたいと思っても、上には上がいる
- 相談なしに、コードを書き直しません
- 自分よりもスキルが劣る人にも、尊敬と敬意と忍耐を持って接します
- 世界で唯一変わらないことは、変わるということ
- 本当の権威は、地位ではなく、知識から生じます
- 信じるもののために戦います。ただし、負けは潔く受け入れます
- 部屋に篭りきりはいけません
- 「人に優しく、コードに厳しく」して、人ではなくコードを批評します
## 論理的思考のコツ
- 瞬時に答えを得ようとする態度は誤りです。瞬時に分からなくても考え続けましょう
- 既に考えたことを、しっかり覚えておきましょう。そうすれば同じことを何度も繰り返し考える「思考のループ」に入り込んでしまうことが避けられます
- 覚えておくのは大変なので、書きながら考えるようにしましょう。書きながら考えることは、副次効果もあります。書いて、目で見えるようにすると頭の中だけで考えていたときには分からなかったものがなぜかわかるようになります。
## 関数側では、引数の調整は行わない
- 呼び出される関数の側で、渡された引数の調整はしてはいけない
- 呼び出される関数側は、契約に基づいて「安心して」引数を使うべき。その結果、コードがシンプルになる
## エラー処理における「正当性」と「堅牢性」
- 正当性とは、不正確な結果を決して返さないことを意味する。不正確な結果を返すくらいなら、何も返さないほうがまだ良いという考え方
- 堅牢性とは、実行を継続できるように手を尽くすこと。不正確な結果がもたらされることがあっても、実行を継続できれば構わない、という考え方
## 割れた窓の法則
- ソフトウェアの「割れた窓」、つまり「悪い設計」「間違った意思決定」「悪いコード」を放置する��、それがどんなに小さいものでも、ソフトウェア全体をごく短期間で腐敗させることになる
## コード腐敗の兆候を掴む
『硬さ』
- 硬さとは、変更の難しさのこと
- たった一つの変更で、それと依存関係のあるモジュールを連鎖的に変更しなければならない場合、「硬い」設計のコードと言える
『脆さ』
- たった一つの変更によって、他の多くの部分が壊れてしまう度合いのこと。
- 脆いコードは、変更した部分とは全く関連のない箇所まで壊れてしまうことがある
## 80-10-10の法則
- 高水準のツールや言語によってソフトウェアを開発すると、ユーザーの求めることの80%は驚くほど短時間で実現することができる
- しかし、残り20%のうち、10%は実現可能だが、相当な努力が必要となる
- さらに最後の10%は完全に実現が不可能
## 80-20の法則
- 障害の8割は、2割のコードに集中している
- 処理にかかる時間の8割は、2割のコードが締めている
投稿元：
レビューを見る
ウェブディレクターの仕事をしている。プログラミングの知識はないが、ウェブエンジニアのコードレビューの仕事を理解したくて、読んでみた。
しかし、内容に全くピンとこなかった。本書のような、テクニカルなことよりも、構造的な部分を理解した方が、業務には役立つような気がした。あと、自分で手を動かして、コーディングを実際に行う。
一年後くらいに、プログラミングに少し慣れてきたところで、本書に再チャレンジしてみよう。ちんぷんかんぷんだったことが、少しでも腑に落ちるようになっていたい。
投稿元：
レビューを見る
[プリンシパルオブプログラミング - Fendo181](https://scrapbox.io/fendo181/%E3%83%97%E3%83%AA%E3%83%B3%E3%82%B7%E3%83%91%E3%83%AB%E3%82%AA%E3%83%96%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0)
投稿元：
レビューを見る
プログラミングの手法や考え方について示している。リーダブルコードと近い内容だが、リーダブルコードが実践的な内容を書いているのに対してこちらはよりコンセプトに近い。読み物としては面白くて気づきも多いのだが、実践へ応用するとなると個人の能力に依存しそう。思想や思考法についての記述も多く、抽象度は高めだが、著者が勝手に提唱しているわけではなく、複数の引用や参考文献を挙げて説明している。
個人的には自分の中の感覚や概念へのラベリングと合致していたので問題なかったのだが、かなり独特な言い回しや例えを用いていて、それが理解できない人にとっては理解できない哲学書を読んでいるような気分になるかもしれない。
読み物としては面白かったが、個人的に私の元々の考え方がこの本と近かったため、読んで得られるものは少なかったように感じる。
数式やコードが出てこないのでスラスラ読める。
