RDD (Release Driven Development) リリース駆動開発
とりあえずリリースして様子を見る、という開発手法。
ちょっと変更してすぐリリース
- 変更がちょっとなのでバグを埋め込みづらい
- 変更がちょっとなのでバグがあっても対処しやすい
- 変更に対する反応を確認しやすい
- 変更が大きいと、何が原因でこんな反応が返ってきたんだ・・・？となる
→今更気付いたけどこれって継続的デプロイ！
自動化しない
ユニットテストとかは別として、変更が頻繁で作成コストも高いviewのテストを自動化できるようにしっかりやってると大変なので・・・
自サイトで利用の多いブラウザに絞ってみんなで手動確認。使い心地などのレビューも兼ねます。
自動化しないとかアホかｗｗｗ
でも、実装してみてorリリースしてみて、やっぱこっちの方がいいやというのが頻繁にある場合、そのたびごとにテスト作成するとかやってられません。そしてその流れが継続的である場合は、テストを作るタイミングがつかめなかったり。
もちろん粒度の細かめなプログラマのためのとかはどんどん自動化してやっていくべきだと思います。
バージョン管理
なんかあったらすぐ戻す。やっぱり前の方が良かったな、というのもさっくり戻す。
バグの埋め込みや複雑化を避ける
これすぐやって！ みたいな事は言わない
「急いで！」といわれると、エンジニアは進行中の作業を一旦止めて割り込み作業に対応します。それが終わると「えーと、なにやってたっけ」→ 無駄・バグ。
やらなくていい仕事をやらない
システムの中身に興味のない営業の人などがよく言うんですが「資料がにぎやかになるので○○追加して」とか「誰も見ないけど慣例だから○○も出力して」とか。これらをばっさり切り捨てる。
比較する
テストがなくても出力の比較くらいは簡単にできます。変更前の出力と変更後の出力を比較して、変なところでデグレがないかは簡単に確認できます。ここは自動化。
前提条件
現在正しく動いているシステム
テストはなくともとりあえず今の状態は正しい。というのは必要で、それをあんまり手を掛けずに維持するというのが主目的。
寛容さ
やっぱり出るときは出るので、ちょっとくらいの障害は握りつぶすくらいの・・・
修正の取捨選択と作業量調整ができる事
やらなくていい修正やるべきでない修正はやらない、というところを徹底して、作業の流量をうまいこと調整するのが必須。修正作業に当たるエンジニアなのか、プロジェクトの管理者なのかはわかりませんが。
