プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則

著者 : 上田勲

• 秀和システム (2016年3月23日発売)

作品紹介・あらすじ

めざせ、脱・初心者。古今東西の達人たちの知恵を、一冊に凝縮してやさしく解説した、プログラマ必携の書!

感想・レビュー・書評

[にっしー82さんの感想 · 2022年8月15日]

プログラマーの心得を各書、各経験から集めたという感じです。
一応、、プログラム周辺のお仕事をしてる身としては3年目でこの内容を身につける事は到底できませんでした。。しかし、書いてあることは真実だと実感してます。

※それぞれのプリンシプルで真逆のことが記載されてたりしますが、間違いではなくてそれをいい「加減」で使いこなすのが大変だったりしますね。。

[yasushi-moさんの感想 · 2021年1月12日]

ひとつひとつのプリンシプルごとに読み切りできるので、隙間時間などにも読みやすい。
応用の幅を広げて欲しいとのことで、プリンシプルの具体例、コードの記載がないが、具体的なイメージがわかないプリンシプルもあるので、具体例を載せて欲しい。

[hatsuさんの感想 · 2020年6月20日]

## 直行性

直交は、幾何学において、グラフの座標軸のように直角に交わる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割のコードが締めている

[akihiko-sさんの感想 · 2019年7月26日]

ウェブディレクターの仕事をしている。プログラミングの知識はないが、ウェブエンジニアのコードレビューの仕事を理解したくて、読んでみた。

しかし、内容に全くピンとこなかった。本書のような、テクニカルなことよりも、構造的な部分を理解した方が、業務には役立つような気がした。あと、自分で手を動かして、コーディングを実際に行う。

一年後くらいに、プログラミングに少し慣れてきたところで、本書に再チャレンジしてみよう。ちんぷんかんぷんだったことが、少しでも腑に落ちるようになっていたい。

[daisuzzさんの感想 · 2017年12月22日]

タイトルの通り、プログラマが意識しておくべき先人の知恵（プリンシパル）が数ページごとにわかりやすくまとめられている本です。
各プリンシパルが「どんなものか」「なぜ必要か」「どうすればよいか」という枠で説明されているため、とても読みやすかったです。
コードが一切でてこないため、実務を経験すればするほどイメージしやすいと感じました。自分自身１年目のプログラマのため、変数名の修正などリファクタリングに関するイメージしやすい箇所と、結合度、凝縮度などイメージしづらい箇所がありました。
自分の周りにこの本をすすめる事で、よりスムーズにプリンシパルに沿ったプログラミングができるのではと思いました。

[musatarosu0607さんの感想 · 2017年1月3日]

プログラミングの原理・原則に重点をおいて、プログラミング初学者がどのようにコードを書いていけばいいのかが細かく記されている。
ただ、あくまで原理・原則なので、参考となるコードを用いて解説するような箇所はあまりない。
（僕自身初学者なので）個人的に、第４章のモジュールについての記述は参考になった。

[P_tanさんの感想 · 2016年3月25日]

プログラミングに関する原理原則をまとめた本。
いずれも基礎知識として知っておいた方が良い内容なので、目次を読んで知らないものが多いなら読むと良いと思う。
また、各項目には参考書籍が載っているため、より詳しく知りたい時には良書への索引集として役立つ。

ただし、各項目数ページの記述であり、具体的なコードもないので、全くゼロからこの本だけで原理原則を理解できるとは思わない方が良い。

[kwnさんの感想 · 2023年9月3日]

●ざっくり感想

本書は言語や分野を問わず「コードを書く人」に向けて書かれています。内容は抽象的で、コードのサンプルはありません。そのため本のタイトルに『3年目までに身につけたい〜』とありますが、プログラミング始めたての人やこれからエンジニアを目指す段階の人だと読んでもあまりピンとこなさそうだなと思いました。なので個人的には最低でもコードを書く経験を数ヶ月してから読むことをオススメします。

内容は「確かにその通りだな」と共感できるものが多く、その中で新たな学びもあり良かったです。1つのプリンシプル(=原則)についての説明が大体2〜5ページ、長くても10ページぐらいで読みやすいのも、一気に読んだわけではなく隙間時間を使って少しずつ読んだ自分にとっては有り難かったです。

ーーーーー

自分のブログから引用
https://kwn1125.hatenablog.com/entry/2023/01/23/210000

[巴澤さんの感想 · 2023年6月2日]

コーディングの時とかの指針になるのでおすすめです

[パルディ博士の助手RDAGさんの感想 · 2023年4月16日]

会社の共有本棚から読みましタ。新しい知識はないですガ、エンジニアなら会話で出てくるような用語が一語1〜2ページくらいの規模でザッとまとまっていまス。説明も平易でスッと入ってきまス。1年目で読んでおきたい本

[いししさんの感想 · 2023年2月5日]

コーディングをする上の心構えについて、教えてくれる本。
コーディングは書いてる時間よりも、読んでもらう時間の方が圧倒的に長く、他者のことを意識して書くことを改めて感じさせられた。


ここで書かれている内容は、コーディングだけではなくその他の分野のエンジニアにも当てはまるように感じた。
・1つの関数にはひとつの機能
・抽象とは捨象と一般化
・ブルックスの法則
・コンテキストを理解し、作業をしてくれる達人は本当に貴重な存在
などは機械系エンジニアとして働いている自分にもためになる内容だった。

とにかくKISS、コードをシンプルに保つことを心がけたいと思う。

[sou (08thse)さんの感想 · 2022年11月6日]

＃以前に読了していましたが、登録していなかったので改めて。

プログラマ…いや、ITエンジニアであれば、一度は通っても良い本なのではと思います。

[ちーたさんの感想 · 2022年4月26日]

仕事をする時の心得集。

[あにとさんの感想 · 2022年3月29日]

概念的なものをざっくり知ることができる。プログラミングをするなら目を通しておくといいかも。

[enさんの感想 · 2022年1月22日]

さっと考え方を知るには良さそう。実務に活用するってよりも、考え方の基礎的なインプットぐらいに考えておおくのがいい。

[かばおさんの感想 · 2021年12月26日]

プログラミングの課題を課題として分割し言語化している。内容はだいたい既知だったが、習得すべき全体マップ的なものが薄く広く概観できる。

[Takumaさんの感想 · 2021年12月2日]

達人プログラマーとかの世代なので今のそれ系ってどんな感じなんだろうと。

読み手の事を考えた原則が多いのが非常に良い！

めっちゃ良いんだけど広く薄味で、ジュニアが読んでもピンと来るのかな？

[gatumaruhahahaさんの感想 · 2021年11月10日]

一つ一つが当たり前だけれどそれ故に大切なことだった。アナロジーとしてプログラマ以外の人が読んでも学びある気がします。

[masaさんの感想 · 2021年10月20日]

プログラミングをやるためにまず、世の中一般で広く知られている原則（常識？）を知らなければならないと思い読んでみた。三年目を微妙に超えているが、プログラミングに本格的に触れるようになってからはまだ三年以内なので良しとする。
これを読むだけでできるプログラマになれるわけではないが、できるプログラマになるために最低限読まなければならない本。SOLIDのようなコーディングの原則から割れ窓理論などの心構えのような内容まで、幅広く扱っている。それらが、what?->why?->how?(->関連->発展)といった形式で紹介されている。また、howにあたってはコード例を出したりせずにあえて図などのイメージに留めているなど、「原則」を理解しやすくなるように工夫されている。
良いプログラマと言われる人がどんな目線で開発をするかその視座に触れることができたと思う。確かにSOLIDなどは定番でネットでも調べればすぐ出てくるがその場合単独での理解になるので、「この原則とあの原則似てるな/対立してるな」とかがわからない（そのわからないというのが初心者の証であって、つまるところ入社三年目までということなのだろうけども）。
しかしこの本ではどの原則が関係しているまたは対立しているのかなど横断的に扱っているおかげで腑に落ちやすい。原則という抽象的な概念の結びつきが生まれやすい。そのため、記憶に残りやすくなるだろうし、実践の時に「これに気を付けなければ、一方でこの点でトレードオフがある」など思考が展開しやすくなると思う。つまり、原理原則のインデックスを頭の中に作ることができる本。
できる人なら経験的にわかっているし身についていることだろうけども、その道半ばにいる人たちには転ばぬ先のなんとやら、ショートカット？アクセル？を提供してくれる良い本だと思う。
ちなみにそれぞれの原則に出典となる書籍が載っているので、より深く知りたいなと思ったらそれらを辿っていくという使い方もできるので、おすすめ。

[佐賀大学附属図書館（本館）さんの感想 · 2021年10月14日]

佐賀大学附属図書館OPACはこちら↓
https://opac.lib.saga-u.ac.jp/opc/recordID/catalog.bib/BB20981754?caller=xc-search

[Daichi Mizunoさんの感想 · 2021年9月14日]

エンジニアとして大事な観点を思い出させてくれた部分、新しく知れた部分がたくさんありました。

1つ1つの原則に区切って書かれているため、読みやすい本でした

[岡本 有馬さんの感想 · 2021年5月14日]

エンジニアとして、やっていきたいなら読んだほうがいい。

[みゆ尾さんの感想 · 2020年5月27日]

社会人1年目、会社で読んで感想を言えと言われて読みました。
プログラムの書き方について深く考えたことがありませんでしたが、この本を読んで「美しいプログラムが書きたい！」と思えました。
プログラムあまり好きじゃないのに流れでシステム職になっちゃった、というような私と同じような後輩ができたら読ませたいです。
今でも私はプログラムが好きではありませんが、この本を読まずに今まで惰性で働いてたら、今よりもっと辛かったと思います。

[kanabun_desuさんの感想 · 2020年5月3日]

プログラミングするなら読んでおいて良い本です。

[kjさんの感想 · 2020年4月13日]

一つ一つのプリンシプル(原理・原則)がとてもシンプルに書いてあります。
駆け出しの頃買って読んでもピンとこない時代があり、少しずつわかるようになり、この本に書いてあることの重要さもわかり...。プログラマとしての成長のそばにはこの本があり、読むたび学びがあります。これからも読みます。とても良い本です。

[chlorochruleさんの感想 · 2020年3月13日]

プログラミングの手法や考え方について示している。リーダブルコードと近い内容だが、リーダブルコードが実践的な内容を書いているのに対してこちらはよりコンセプトに近い。読み物としては面白くて気づきも多いのだが、実践へ応用するとなると個人の能力に依存しそう。思想や思考法についての記述も多く、抽象度は高めだが、著者が勝手に提唱しているわけではなく、複数の引用や参考文献を挙げて説明している。
個人的には自分の中の感覚や概念へのラベリングと合致していたので問題なかったのだが、かなり独特な言い回しや例えを用いていて、それが理解できない人にとっては理解できない哲学書を読んでいるような気分になるかもしれない。
読み物としては面白かったが、個人的に私の元々の考え方がこの本と近かったため、読んで得られるものは少なかったように感じる。

数式やコードが出てこないのでスラスラ読める。

[えんどぅーさんの感想 · 2019年8月23日]

[プリンシパルオブプログラミング - 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)

[馬場久志さんの感想 · 2019年8月12日]

技術書読書ブログを運営する著者による、プログラミングの原則をまとめた本。
101もの原理原則が理路整然と並べられ、各々に論理的な解説が付いている。プログラマならだれでも知っている有名な原則もあれば、恥ずかしながら聞いたことのない原則まであった。(個人的にはUNIXの思想や哲学が網羅されているのが嬉しい。) 各セクションの最後に掲載されている出展書籍には技術書だけでなく哲学書なども含まれており、著者の知識の広さがうかがえる。
副題には「3年目までに身につけたい」とあるが、プログラマなら何年目であっても手元に置いて読み返したいバイブルのような本だと思う。

[rindricsさんの感想 · 2019年5月6日]

よくある内容

[fuji70さんの感想 · 2018年10月20日]

プログラミングの基本原則が数ページ毎にまとめられている。ほとんど既知だったことから自分が網羅していることを確認出来た。

[more]

- YAGNI You Aren't Goint to Need It
- それはきっと必要にならない
- 今必要なものだけつくるべき
- OCP Open-Closed Principle
- 拡張に対して開いている
- 修正に対して閉じている
- 名前重要 Naming is important.
- コードで命名は最重要課題
- 非機能要件
- 機能面以外全般
- 変更容易性、信頼性、テスト容易性、再利用性
- 倹約の原則 Rule of Parsimony
- コードを継ぎ足し続けない
- 大きくなったら分割する
- 驚き最小の原則 Rule of Least Surprise
- 予想通りのインタフェース
- 可逆性 Reversibility
- プログラマは唯一の最終決定解を求める傾向
- 外部要因で変更されることは良くある
- チームはハイコンテキスト志向で
- 共通認識が多い状態
- 多くを言わずとも通じる

eof