プリンシプルオブプログラミング の商品レビュー
- ネタバレ
※このレビューにはネタバレを含みます
プログラミングをやるためにまず、世の中一般で広く知られている原則(常識?)を知らなければならないと思い読んでみた。三年目を微妙に超えているが、プログラミングに本格的に触れるようになってからはまだ三年以内なので良しとする。 これを読むだけでできるプログラマになれるわけではないが、できるプログラマになるために最低限読まなければならない本。SOLIDのようなコーディングの原則から割れ窓理論などの心構えのような内容まで、幅広く扱っている。それらが、what?->why?->how?(->関連->発展)といった形式で紹介されている。また、howにあたってはコード例を出したりせずにあえて図などのイメージに留めているなど、「原則」を理解しやすくなるように工夫されている。 良いプログラマと言われる人がどんな目線で開発をするかその視座に触れることができたと思う。確かにSOLIDなどは定番でネットでも調べればすぐ出てくるがその場合単独での理解になるので、「この原則とあの原則似てるな/対立してるな」とかがわからない(そのわからないというのが初心者の証であって、つまるところ入社三年目までということなのだろうけども)。 しかしこの本ではどの原則が関係しているまたは対立しているのかなど横断的に扱っているおかげで腑に落ちやすい。原則という抽象的な概念の結びつきが生まれやすい。そのため、記憶に残りやすくなるだろうし、実践の時に「これに気を付けなければ、一方でこの点でトレードオフがある」など思考が展開しやすくなると思う。つまり、原理原則のインデックスを頭の中に作ることができる本。 できる人なら経験的にわかっているし身についていることだろうけども、その道半ばにいる人たちには転ばぬ先のなんとやら、ショートカット?アクセル?を提供してくれる良い本だと思う。 ちなみにそれぞれの原則に出典となる書籍が載っているので、より深く知りたいなと思ったらそれらを辿っていくという使い方もできるので、おすすめ。
Posted by
エンジニアとして大事な観点を思い出させてくれた部分、新しく知れた部分がたくさんありました。 1つ1つの原則に区切って書かれているため、読みやすい本でした
Posted by
ひとつひとつのプリンシプルごとに読み切りできるので、隙間時間などにも読みやすい。 応用の幅を広げて欲しいとのことで、プリンシプルの具体例、コードの記載がないが、具体的なイメージがわかないプリンシプルもあるので、具体例を載せて欲しい。
Posted by
- ネタバレ
※このレビューにはネタバレを含みます
## 直行性 直交は、幾何学において、グラフの座標軸のように直角に交わる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割のコードが締めている
Posted by
社会人1年目、会社で読んで感想を言えと言われて読みました。 プログラムの書き方について深く考えたことがありませんでしたが、この本を読んで「美しいプログラムが書きたい!」と思えました。 プログラムあまり好きじゃないのに流れでシステム職になっちゃった、というような私と同じような後輩が...
社会人1年目、会社で読んで感想を言えと言われて読みました。 プログラムの書き方について深く考えたことがありませんでしたが、この本を読んで「美しいプログラムが書きたい!」と思えました。 プログラムあまり好きじゃないのに流れでシステム職になっちゃった、というような私と同じような後輩ができたら読ませたいです。 今でも私はプログラムが好きではありませんが、この本を読まずに今まで惰性で働いてたら、今よりもっと辛かったと思います。
Posted by
一つ一つのプリンシプル(原理・原則)がとてもシンプルに書いてあります。 駆け出しの頃買って読んでもピンとこない時代があり、少しずつわかるようになり、この本に書いてあることの重要さもわかり...。プログラマとしての成長のそばにはこの本があり、読むたび学びがあります。これからも読みま...
一つ一つのプリンシプル(原理・原則)がとてもシンプルに書いてあります。 駆け出しの頃買って読んでもピンとこない時代があり、少しずつわかるようになり、この本に書いてあることの重要さもわかり...。プログラマとしての成長のそばにはこの本があり、読むたび学びがあります。これからも読みます。とても良い本です。
Posted by
プログラミングの手法や考え方について示している。リーダブルコードと近い内容だが、リーダブルコードが実践的な内容を書いているのに対してこちらはよりコンセプトに近い。読み物としては面白くて気づきも多いのだが、実践へ応用するとなると個人の能力に依存しそう。思想や思考法についての記述も多...
プログラミングの手法や考え方について示している。リーダブルコードと近い内容だが、リーダブルコードが実践的な内容を書いているのに対してこちらはよりコンセプトに近い。読み物としては面白くて気づきも多いのだが、実践へ応用するとなると個人の能力に依存しそう。思想や思考法についての記述も多く、抽象度は高めだが、著者が勝手に提唱しているわけではなく、複数の引用や参考文献を挙げて説明している。 個人的には自分の中の感覚や概念へのラベリングと合致していたので問題なかったのだが、かなり独特な言い回しや例えを用いていて、それが理解できない人にとっては理解できない哲学書を読んでいるような気分になるかもしれない。 読み物としては面白かったが、個人的に私の元々の考え方がこの本と近かったため、読んで得られるものは少なかったように感じる。 数式やコードが出てこないのでスラスラ読める。
Posted by
- ネタバレ
※このレビューにはネタバレを含みます
[プリンシパルオブプログラミング - 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)
Posted by
ウェブディレクターの仕事をしている。プログラミングの知識はないが、ウェブエンジニアのコードレビューの仕事を理解したくて、読んでみた。 しかし、内容に全くピンとこなかった。本書のような、テクニカルなことよりも、構造的な部分を理解した方が、業務には役立つような気がした。あと、自分で...
ウェブディレクターの仕事をしている。プログラミングの知識はないが、ウェブエンジニアのコードレビューの仕事を理解したくて、読んでみた。 しかし、内容に全くピンとこなかった。本書のような、テクニカルなことよりも、構造的な部分を理解した方が、業務には役立つような気がした。あと、自分で手を動かして、コーディングを実際に行う。 一年後くらいに、プログラミングに少し慣れてきたところで、本書に再チャレンジしてみよう。ちんぷんかんぷんだったことが、少しでも腑に落ちるようになっていたい。
Posted by
ソフトウェアの現場や書籍などて、繰り返し言われている先人たちの知恵をまとめた本。この本でも述べられているように、若干の重複もあるし、表面上矛盾した主張が出てきていたりもする。そんなある意味公平なスタイルだからこそ、幅広く読まれるべき本だと思う。101個紹介されている原理原則には、...
ソフトウェアの現場や書籍などて、繰り返し言われている先人たちの知恵をまとめた本。この本でも述べられているように、若干の重複もあるし、表面上矛盾した主張が出てきていたりもする。そんなある意味公平なスタイルだからこそ、幅広く読まれるべき本だと思う。101個紹介されている原理原則には、それぞれに対する出典書籍と関連書籍が記載されていて、深堀したくなったときも辿りやすい。 「3年目までに身につけたい」と副題にあるので新人以外は手に取りにくいかもしれないが、むしろ色々な現場を経験した人の方がそれぞれの原理原則の含蓄のようなものを感じられそう。
Posted by