プログラマが知るべき97のこと 読書メモ
プログラマが知るべき97のこと をスキマ時間に読んでいた。気になったところをメモしておく。 技術的負債は、即座に次のイテレーションで返済する。そうでなければ利息が膨れ上がる。 ゼロから描き直したい衝動・誘惑に打ち勝たなければならない。できるだけ既存コードを生かす。 新たな変更を加える時には1箇所でも良いので改善する。 コードを書くことは設計をすること。機械的な作業ではなく、創造的なもの。 コードレビューの目的は誤りの修正だけでなく、コードの共有所有を確立すること。 コメントには読む人が価値があるものを書く。つまり、コードに書いていないことや、コードにかけないことが書かれるべき。 プロジェクトの初期からデプロイ作業を始める。 1万時間やればエキスパートに必ずなれる。ほぼ自分がなろうとするかという意思の問題。 Windows 2000には"TERRIBLE HORRIBLE NO GOOD VERY BAD" と書かれている。見られて恥ずかしいデータは使わないこと。 厄介なのは今はプログラマでなくても以前プログラミングを「ちょっとしたことがある」くらいの人。 SCM へのチェックイン後は開発者は傍観者になるべき 開発者は開発サーバより後の環境へはアクセスしない、QA・顧客は開発サーバへアクセスしない API自身だけじゃなく、APIを利用するコードのテストもする ハードワークは報われない。自分の働く時間や労力を減らすほどプロジェクトへの貢献が大きくなる。 知識と技術の研鑽を怠ってはならない。 バグレポートには、バグの再現方法、頻度、本来の仕様、実際の動作を書く。 パラダイムの異なる第二の言語を学ぶ。 データ構造、アルゴリズムの時間と空間の複雑性を知る。 見積もりを求められた時には、見積もり、ターゲット、コミットメントを区別する。 正しく使用する方がミスするよりも簡単。インターフェイスが良ければ、正しく使用できる。 メモリ共有の代わりに、メッセージパッシングを使う。 テスト担当者は敵ではなく友人。 環境に関する情報もバージョン管理する。 互いの理解には、定義の共有ではなく経験の共有が必要。 シングルトンパターンはテストや保守性の点で不利。 Ubuntuはズールー語で他者への思いやりという意味。 このコードは生涯、自分がサポートし続けると思って書く。 テストは見る人のために書く。 顧客には頻繁に疑問を投げかける。顧客から言われたことを自分の言葉で言い直すと良い。 議論の時は図や絵を利用することが大切。設計の早い段階でモックアップを作るのも良い。 ステートを取り扱う時はステートマシンを意識する。 コードネームをつける。身近でよく知っている名前が良い。チームの結束のための合言葉。 単純作業であってもルーチンワークを1日の最初に行う余地を残しておくと良い。 師匠となる人を見つけると良い。 快適な環境を追求する。 声の大きいユーザからの要望に忠実に答えると、バグの出やすいソフトウェアになってしまう。Feature Creepに陥る。 命名にこだわる。機能の設計の重要な一つ。