本書は、「プログラマ」の、「プログラマ」による、「プログラマ」のための本です。
- プログラマとして成功したい！
- プログラミングの腕を上達させたい！
- ソースコードの質を向上させたい！
- メンバーと上手くやりたい！
こういった願いを持つ人のために、世界中でよく知られた著者陣のエッセイがまとめられています。
何か壁にぶち当たっている人、成功したプログラマはどんなことを考えていたのか知りたい人、どういうことを考えてプログラムを書けば質が上がるのか知りたい人。
すべての「プログラマ」におすすめの一冊です。
参考
カテゴリ別目次
- バグとその修正
- ビルドとデプロイメント
- コーディングガイドラインとコードレイアウト
- 設計原則とコーディングテクニック
- ドメインの考慮
- エラー、例外とその処理
- 技術、知識の習得
- 夜と魔法
- パフォーマンス向上、最適化、その具体策
- プロとしての心構え、態度
- プログラミング言語とパラダイム
- リファクタリングと保守
- 再利用と重複
- スケジュールと納期、見積もり
- シンプルさ
- チームワークと強調
- テストとその実践、テスター
- ツール、自動化、開発環境
- コードと顧客
おぼえがき
本書は、良いことばかり書いてあり、おぼえがきを真面目に書こうとすると全部抜き出すことになっちゃうので適当に抜き出しました。
すごくいいことがいっぱい書いてあるので、一度本屋で立ち読みしてみるといいと思います。
コードの再利用
コードの再利用をするときは、コンテキストが同じかどうかを確認すること。システム内に同じことをするコードが二つあったとしてもそれぞれが違う役割をしていたら、それはコンテキストが違うから再利用のメリットは少ない。
「再利用」は一般に良いこととされており、確かに基本的には良いことだからです。コンテキストさえ適切なら、間違いなく有効です。しかし、コンテキストが不適切だと、メリットよりもコストのほうが大きくなるのです。
DRY原則
「DRY（Don’t Repeat Yourself:繰り返しを避ける）原則」とは「すべての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない」という条件をみたすこと。
「知識」が唯一であるということがポイントで、その知識を取り出すコードの重複は DRY 原則違反ではない。その知識を取り出すコードの重複を一箇所にまとめることは、OAOO（Once and Only Once）と呼ぶ。
技術的例外とビジネス例外を明確に区別する
技術的例外、たとえばネットワークに繋がらない、データベースに繋がらない、配列のインデックスを超えてアクセスしたなどの例外と、預金額を超える額のお金を口座から引き出そうとしたというようなビジネス例外は、明確に別れた例外階層を使うべき。
良いインターフェース仕様の条件は「正しい使い方を簡単に、誤った使い方を困難に」
良いインターフェースは、正しく使用することが操作ミスをするよりも簡単である。良い API を設計するときに考えることは「それが一番自然かどうか」
名前重要
「すべての人物・事物には真の名前があり、その名前を知るものはそれを支配することができる」本当にしっくりくる名前を選択することは、とても重要なことで、適切な名前を選択できたら8割は設計が完成したと考えても大げさではない。