自分が今までに本で読んだり人に聞いたりして知った「ソフトウェア開発における格言」の内、特にビビッと来たものを紹介しています。

1. ソフトウェア開発の格言

2. 目次
❏ DRY原則
❏ プレイン・テキストの威力
❏ ボーイスカウトルール
❏ 割れ窓理論
❏ 偶発的プログラミング

3. DRY原則
Don’t Repeat Yourself（繰り返しを避けるこ
と）
すべての知識はシステム内において、単一、かつ明確な、
そして信頼できる表現になっていなければならない。
「達人プログラマー」より

4. DRY原則
要は情報の一元管理
だけど、必ずしも守れるものではない
❏ 設計書とコード
❏ コードとコメント
❏ パフォーマンスを上げるためのキャッシュ
とは言え、極力この原則を守った方が良い
やむを得ない部分では、メンテナンスに注意す
る

5. プレイン・テキストの威力
達人プログラマーが取り扱う素材は木でも鉄でもありませ
んー知識です。我々は要求を集めて知識とし、設計、実装、
テスト、ドキュメントの中でその知識を表現するのです。
プレイン・テキストを使えば手作業、自動的な作業を問わ
ず、事実上すべてのツールを使って思い通りに知識を操作
することができるようになるのです。
「達人プログラマー」より

6. プレイン・テキストの威力
プレイン・テキストのイイトコ
❏ diffが取りやすい（バージョン管理しやすい）
❏ コードの自動生成ができる
❏ コードから自動生成ができる

7. できたらいいなと思うプロセス
❏ 設計レビュー用仕様書はwordでもexcelでも
良い
❏ 設計が固まった後の仕様書（メンテナンス
用）は、プレイン・テキストで作成する
❏ 仕様書とコードの両方に現れる情報は、一方から他
方を自動生成できるようにする
❏ 外部インターフェース、内部インターフェース、
etc...

8. できたらいいなと思うプロセス
❏ プログラムにおける唯一の真実はコード
❏ 仕様書になんと書いてあっても、実際の動
作はコードが全て
❏ コードがコミットされると、コードからド
キュメントが自動生成されたら、少なくと
もコードとそのドキュメントに乖離はなく
なる
プレインテキストの威力＋DRY原則

9. ボーイスカウトルール
アメリカのボーイスカウトの以下のルールを、コーディン
グにも適用すること：
キャンプ場を、来た時よりも綺麗にして帰ること
チェックアウトした時よりも、少しでも綺麗に
してチェックインする
「Clean Code」より

10. ボーイスカウトルール
チェックアウトした時よりも、少しでも綺麗に
してチェックインする
❏ 「解読に苦労した部分にコメントを追加する」
これだけでも、次に読む人の工数を結構削減できる
かも。
❏ 変数の意味
❏ 関数コメント
❏ etc...

11. 割れ窓理論
「建物の窓が壊れているのを放置すると、誰も注意を払っ
ていないという象徴になり、やがて他の窓もまもなく全て
壊される」という考え方
コード中のささいなtypoやちょっとしたスパゲッティが放
置されると、「このコードの品質はこの程度でいいんだ」
という感じで新たなtypoやスパゲッティを呼んでしまう
Broken Windows: The police and neighborhood safety
「達人プログラマー」

12. ボーイスカウトルールと割れ窓理論
ボーイスカウトルールを適用して、割れ窓を発
見したら自分の変更に加えて是非窓の修理を！

13. 偶発的プログラミング
コードを書いてみて、テストしてみて、動いた
からOK、は危険！（偶発的プログラミング）
❏ たまたまテストした時の条件がうまく合致していた
だけかもしれない。
❏ もし何らかのルーチンを呼び出す場合には、ドキュ
メント化されている振る舞いのみを前提とする
❏ ドキュメント化されていないルーチンを呼ぶ必要が
あるときは、自分の仮定をドキュメント化しておく
「達人プログラマー」