同じコード（処理）は２回しか書かない
１回目は普通に実装し、２回目で共通・抽象化する DRY!(Don't Repeat Yourself!)
重複を見たら疑うこと。
ライブラリを作るときは特にそうだけれど、
実は、プロダクションコードでも大事な気がする。
実例 外部APIのアクセスキーが分散して記述してある
例えば、開発用にと思って、とりあえずAPIのアクセスキーをベタ書き（ハードコーディング）をしていた。
その後、途中で設定ファイル・基底クラスを作り、他のコードはそちらを参照するようになった。（前に書いたコードは直し忘れた）
リリース・テスト時は、開発時とアクセスキーが変わらないので気づかない。（ちゃんと動く）
その後、アクセスキーが更新されると、、、、
・一部だけが動かない（エラー）
または、
・一部だけがおかしい（データ・挙動など）
前者だったら気づきやすいからまだいいけれど、後者は特に大規模になってくるとわかりにくい。
おそらく、再現条件に共通項目が少ないため、この重複が原因だと発見するのに時間がかかる。
ヘタすればバグに気づかない可能性すらあり。
これはテストでも網羅しづらい実装バグ。（結合テストの領域になるのかな？）
こういうのはリファクタの対象になるコードだけど、きちんと動くこともあり、「まあいっか」ってことで優先度低めになりがち。
日頃から重複するコードを書かない癖が大事なのでは。重複したら「なんかおかしいかも・ベストプラクティスじゃないかも」と疑ってみる。
注：ただし、DRYは原理原則というほどではなく、時と場合にもよるようです
DRY原則の利用: コードの重複と密結合の間
See also Don't repeat yourself - Wikipedia