プログラマが知るべき 97 のこと
無料で読める本
通称「きのこ本」とよばれるオライリー発行の書籍群があります。 これらの書籍は CC-by-3.0 などでライセンスされており、著者名を明記すればコピー/配布や改変が自由にできます（商用利用も可能）。 そこで、勝手に電子書籍化（非公式版）を作っています。 詳細は https://github.com/yoshi389111/kinokobooks まで
Chapters
【01】分別のある行動
【02】関数型プログラミングを学ぶことの重要性
【03】ユーザが何をするかを観察する（あなたはユーザではない）
【04】コーディング規約を自動化する
【05】美はシンプルさに宿る
【06】リファクタリングの際に注意すべきこと
【07】共有は慎重に
【08】ボーイスカウト・ルール
【09】他人よりまず自分を疑う
【10】ツールの選択は慎重に
【11】ドメインの言葉を使ったコード
【12】コードは設計である
【13】コードレイアウトの重要性
【14】コードレビュー
【15】コードの論理的検証
【16】コメントについてのコメント
【17】コードに書けないことのみをコメントにする
【18】学び続ける姿勢
【19】誰にとっての「利便性」か
【20】すばやくデプロイ、こまめにデプロイ
【21】技術的例外とビジネス例外を明確に区別する
【22】1万時間の訓練
【23】ドメイン特化言語
【24】変更を恐れない
【25】見られて恥ずかしいデータは使わないこと
【26】言語だけでなく文化も学ぶ
【27】死ぬはずのプログラムを無理に生かしておいてはいけない
【28】「魔法」に頼りすぎてはいけない
【29】DRY 原則
【30】そのコードに触れてはならない！
【31】状態だけでなく「ふるまい」もカプセル化する
【32】浮動小数点数は実数ではない
【33】オープンソースプロジェクトで夢を実現する
【34】API 設計の黄金律
【35】超人の神話
【36】ハードワークは報われない
【37】バグレポートの使い方
【38】余分なコードは決して書かない
【39】最初が肝心
【40】プロセス間通信とアプリケーションの応答時間の関係
【41】無駄な警告を排除する
【42】コマンドラインツールを使う
【43】プログラミング言語は複数習得すべき
【44】IDE を知る
【45】限界を知る
【46】すべきことは常に明確に
【47】大量のデータはデータベースで
【48】いろいろな言葉を学ぶ
【49】見積りとは何か
【50】Hello, World から始めよう
【51】プロジェクト自身にしゃべらせる
【52】「その場しのぎ」が長生きしてしまう
【53】正しい使い方を簡単に、誤った使い方を困難に
【54】見えないものを見えるように
【55】並行処理に有効なメッセージパッシング
【56】未来へのメッセージ
【57】ポリモーフィズムの利用機会を見逃さない
【58】テスト担当者はプログラマの友人
【59】バイナリは常に1つ
【60】真実を語るはコードのみ
【61】ビルドをおろそかにしない
【62】プリミティブ型よりドメイン固有の型を
【63】ユーザの操作ミスを防止する
【64】プロのプログラマとは？
【65】バージョン管理システムを有効に使う
【66】いったんコンピュータから離れてみる
【67】コードを読む
【68】「人間」を知る
【69】車輪の再発明の効用
【70】シングルトンパターンの誘惑に負けない
【71】パフォーマンスへの道は地雷コードで敷き詰められている
【72】シンプルさは捨てることによって得られる
【73】単一責任原則
【74】「イエス」から始める
【75】面倒でも自動化できることは自動化する
【76】コード分析ツールを利用する
【77】偶然の仕様ではなく本物の仕様のためのテストを書く
【78】テストは夜間と週末に
【79】テストのないソフトウェア開発はあり得ない
【80】1人より2人
【81】エラーがエラーを相殺してしまう
【82】他者への思いやりを意識したコーディング
【83】UNIX ツールを友にする
【84】正しいアルゴリズムとデータ構造を選ぶ
【85】冗長なログは眠りを妨げる
【86】WET なシステムはボトルネックが見つかりにくい
【87】プログラマとテスターが協力してできること
【88】コードは生涯サポートするつもりで書く
【89】関数の「サイズ」を小さくする
【90】コードを見る人のためにテストを書く
【91】良いプログラマになるには
【92】顧客の言葉はそのまま受け取らない
【93】エラーを無視するな
【94】リンカは魔法のプログラムではない
【95】ペアプログラミングと「フロー」
【96】テストは正確に、具体的に
【97】ステートに注目する
Author
Topics