プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則 | 上田 勲 |本 | 通販 | Amazon
読書感想文です。
いい仕事いい先輩いいコードに、自分にとっていいタイミングで巡り合えれば、成長できます。しかし、これは運に左右されます。確率は高くありません。
そこで書籍を読んで勉強します。ただし、初学者向けの書籍では文法とイディオムは身に付きますがプログラミングスキルの改善には至りません。
そうかと言って、達人プログラマたちの名著を読んでも敷居が高く難しすぎて挫折したり、知識が素通りして結局得るものがなかったりします。
さらにさしあたりやらなければならない仕事があり、その仕事に直結する技術を身に付けなければなりません。しかも、その技術はどんどん更新されていきます
この悩みを解決してもらうために書いたのが本書になります。
ソフトウェア業界で高名なよいコードを書くための「プリンシプル」を紹介します。そして「それはどういうことなのか（＝What）」「それはなぜなのか、なぜ必要なのか（＝Why）」「ではどうすればよいのか（＝How）」を中心に解説します
感想
- 「銀の弾丸はない」
- なのだが、他の本への入り口を数々教えてくれる本。芋づる式に読みたい本が増える。
- 特に前半が印象的
- 「コードには、『How』や『What』はよく表現されていますが、『Why』、つまり設計理由がありません。この設計理由をドキュメントに記述しておくと、保守担当者の修正の判断材料として、多くの機会で役に立ちます」
- 「結局コードというものは、書いている時間より、読んでいる時間の方が、はるかに長くなります」
- 良い、良い、と聞いていながら研修のためにあらためて読んだ。新人だった頃の自分が読んだとして響くかはわからないが、経験を経て読むと、ああいい言葉しか無いな～、と感じられる本。
要点
- 銀の弾丸はない
- ソフトウェアの本質は困難性ですが、その最たる要因は「複雑さ」にあります。ソフトウェア開発の歴史は、実は、複雑さとの戦いの歴史です。これまでに、複雑さに対抗する、様々なアイデアが生まれています。歴史を学び、様々な手法や考え方を学んで、地道に、複雑さを「軽減」するようにしましょう。
- コードは設計書である
- ソースコードは設計書であり、コーディングは設計作業である - Qiita
- 「コーディングは設計か製造か」という考え方の違い - 思考と現場の間で
- コードは設計書ですが、コードが唯一のドキュメントというわけではありません。ほかにも必要なドキュメントはたくさんあります。アジャイル開発手法は、ドキュメントを軽視する開発プロセスであるとよく誤解されますが、無駄なドキュメントを作らないというだけで、「ドキュメントを作らなくてよい」と主張しているわけではありません。
- コードには、「How」や「What」はよく表現されていますが、「Why」、つまり設計理由がありません。この設計理由をドキュメントに記述しておくと、保守担当者の修正の判断材料として、多くの機会で役に立ちます。
- 「変更に強いコードを書く」
- そのためには「コードが読みやすい」ということが、もっとも大切です。
- 結局コードというものは、書いている時間より、読んでいる時間の方が、はるかに長くなります。
- シンプルに保つ
- DRY
- YAGNI
- PIE
- 名前重要
- 名前は、コードを読む人へのユーザーインタフェースです。各要素に対して適切に名前の付けられているコードは、その意図するところが伝わり、「何を」「どのように」やっているか明確に理解できます。読むとただちに意味がわかる、よいユーザーインタフェースです。
- プログラミングセオリー
- コミュニケーション
- シンプル
- 柔軟性
- 結果の局所化
- 繰り返しの最小化
- ロジックとデータの一体化
- アーキテクチャ根底技法
- 変更頻度
- 情報隠蔽
- アーキテクチャ非機能要件
- 変更容易性
- 保守性・拡張性・再構築・移植性
- ソフトウェアの高齢化を防ぐためには、「正確なドキュメント化」「変更時にアーキテクチャを壊さないこと」「真摯なレビュー」「変更箇所を予測した柔軟な設計」などの対抗手段を駆使します。
- 変更容易性
- 7つの設計原理
- UNIX思想
- UNIX哲学
- UNIXという考え方 | Ohmsha に通ずる
- UNIXの哲学は普遍である
- UNIXに採用されているアイデアは、他の多くのソフトウェア開発にも生かされ、応用されています。
- UNIX哲学を利用する
- UNIXの哲学を、設計方針やプログラミングに活かしましょう。
- 設計哲学の背景にある「理由」を把握しておくと、適切な方針を選択できます。
- 視点 ～プログラマの見る角度～
- 技術的負債
- 経験不足のプログラマ
- 締切りのプレッシャー
- 読みにくいコード
- 特殊化されたコード
- 不要に複雑なコード
- 単に悪い設計
- 技術的負債
- 習慣 ～プログラマのルーティーン～
- プログラマの三大美徳
- 怠慢・短気・傲慢
- 確かに、長時間オフィスにいれば、プロジェクトに多大な貢献をしているような錯覚に陥ることがあります。メンバーの人たちも、そう思ってくれることもあります。しかし、事実はまったく逆で、自分の働く時間や労力を減らせば減らすほど、プロジェクトへの貢献は大きくなるのです。
- ボーイスカウトルール
- ボーイスカウトには、シンプルな規則があります。「自分のいた場所は、そこを出て行く時、来た時よりもきれいにしなければならない」という規則です。たとえ、自分が来た時には既にキャンプ場が汚かったとしても、たとえ、汚したのが自分ではなかったとしても、きれいにしてからその場を去るのです。この規則を、プログラミングにも当てはめます。
- エゴレスプログラミング
- プログラマの三大美徳
- 手法
- コンテキスト
- 新しく加入したメンバーは、コンテキストが共有されていません。したがって、そのメンバーに対しては、ローコンテキスト文化を見習い、自明であると思われることも説明したり、5W1Hを明確に説明したり、順を追った論理的な説明を心がけたりする必要があります。
- コンテキスト
等など。
参考記事
『プリンシプルオブプログラミング』を読んだ - 夜は寝る
プリンシプルオブプログラミング
初心者にこそおすすめしたいプリンシプル オブ プログラミング｜あきの/D-En｜note
以上です～