Masayuki Fukada GitHub page

関連する理論や原則
- 割れ窓理論
  - アメリカの犯罪学者ジョージ・ケリングが考案
  - 軽微な犯罪も徹底的に取り締まることで、凶悪犯罪を含めた犯罪を抑止できるとする環境犯罪学上の理論
  - 1枚の割れた窓ガラスをそのままにしていると、さらに割られる窓ガラスが増え、いずれ街全体が荒廃してしまうという理論
  - プロジェクト開始時にワーニングが1件残っていたとする。あなたの作業後に2件増えたとすると、ワーニングは最初の3倍になる。これはマズイ。
    - しかし、プロジェクトが最初から大量(数百〜数千件)のワーニングが残っていたとしたら、あなたの追加したワーニングは1%にも満たない些細なものに感じられる。
    - つまり放置されたままのワーニングが増えると、作業の結果ワーニングが増えたとしても気にならなくなってしまう。
  - ⇒ 「今回の作業に関係無い範囲は修正しなくても良い」とプロジェクトリーダーが言う様なプロジェクトは要注意
    - ...とは言えテストコードが無い場合はバグを新たに生む可能性もあり、多少Gは仕方ない部分でもある
    - ⇒ 普段からテストコードをちゃんと書く
    - ⇒ テストコードを書いて既存の動作を確かめてから直す
- ボーイスカウトの原則
  - 「来た時よりも美しく」のルール
  - 自分が作業する前よりも作業した後の方がソースコードが綺麗になっている状態を目指す
    - 上記の割れ窓理論とも関連。自分の作業と直接関係が無くてもワーニングが出ていたら直す
    - 修正内容が心配ならコミットを分けておく
対策
- プロジェクトの最初の１週間程度は既存のコードの構造、ルールを理解・修正・最新化するための期間として工数を見積もる
  - 勿論プロジェクトの規模によって期間は調整が必要
- 可能ならワーニングをエラーとして扱う(ビルドを失敗判定にするなど、ワーニングを放置して作業を進められないように)ように設定
  - インデントの違い(タブ <--> スペース)なども消すようにしたりと、コードスタイル系も正す施策があると尚良い
- エラー/ワーニングともに 0件であることをルールとする(又は、どうしても無くせないものはドキュメントに記載する)
  - 「来た時より悪くしない」のが最低限の譲歩

ワーニングをエラーとして扱う