法則一覧
コラム
古いコードとつきあう
古いコードは、二つの逆向きの衝動を呼ぶ。無駄に見えるものを消したい衝動と、全部書き直したい衝動だ。このコラムは、そのコードがなぜあり、誰が頼っているかを知るところから、変えられる状態を保つ手、そして大きな書き直しをせずに置き換える手までを順に読む。
多くの場合、何もしていないように見える部分から始まる。
チェスタトンの柵
経緯を知らないコードやルールは無駄に見え、理由も知らずに消したくなる。心得：理由を知ってから消す。ただし探すのは期限つきでなぜそこにあるのかを知るには、作った人に聞くことになりやすい。その人たちは、もういないかもしれない。
プログラミングは理論の構築である
プログラムの設計は作った人たちの頭の中にあり、コードや文書が運べるのはその一部だけだ。だから作った人たちがいなくなると、文書がそろっていても、変更を重ねるうちに設計が崩れやすい。心得：理由を言える人がいるうちが、保守できるコードだその人たちでも、何に頼られているかを全部は挙げられない。それを知っているのは使っている側だ。
ハイラムの法則
利用者が十分に多ければ、バグも含めた観測可能な挙動すべてに誰かが依存する。心得：見えているものは、すべて約束したものとみなすコードが理解し直されるまで待ってはもらえない。使われているコードは変更され続けるからだ。
レーマンのソフトウェア進化の法則
実際に使われているプログラムは、変わり続けなければ役に立たなくなる。そして変えるたびに、手をかけて単純にしない限り複雑になっていく。心得：変更だけでなく、単純化にも予算を割くその複雑さの一部は、問題を理解しきる前に承知で出したコードだ。その分は借金として記録できる。
技術的負債
問題を十分に理解する前に出したコードは、誰かが書き直すまで、そのコードをその後変えるたびに余計なコストを生む。心得：近道は借金として記録し、よく触るところから返すその一部は、専用のプロジェクトを待たずに返せる。
ボーイスカウトの規則
コードが劣化するのは、片付けが、めったに実施されないリファクタリングに先送りされがちだからだ。心得：触ったところは、同じ差分の中で少しだけきれいにする小さな手直しでは遅すぎると感じると、もう一方の衝動が勝つ。作り直すなら、壊れていない所まで直したくなる。
セカンドシステム症候群
最初の成功のあと、設計者は先送りしたアイデアを二作目に詰め込みがちだ。心得：作り直しで持ち越すのは、願望リストではなく制約作り直しは、古いシステムが持っているもの、つまり今動いているという事実も手放す。
ガルの法則
動く複雑なシステムは、たいてい動く単純なシステムから育ったものだ。最初から設計したものが動くことはまれだ。心得：一度に全部動かないと動かない設計を疑う置き換えも動くものから育てるなら、その動くものは古いシステム自身でよい。
ストラングラーフィグ
稼働中のシステムは、一度に置き換えるより、周縁から少しずつ置き換えるほうがたいてい安全だ。心得：移行は一歩ずつ出せる形にし、旧系の削除まで計画する部品を一つ移すたびに、古い挙動に頼っていた誰かが壊れうる。移す側に見えるのは、テストが確かめている挙動だけだ。
ビヨンセ・ルール
共有コードベースでは、どのテストも確かめていない挙動こそが予告なく変わる。心得：頼っている挙動には、テストを置く
