ボクの考えた最強の開発プロセス
そろそろ開発プロセスというかツールを見なおして、「安くて・早くて・うまい」を実現するための近未来的な開発がしたいので、こういう開発がしたいなぁ、というのを妄想をしてみた。
コンセプトは「可能な限り人間が翻訳しない」。言い方を変えればDRY。
A.要件定義
- 要求から要件を抽出。各要件をチケット化(redmine/jiraとか)
- 全体像を確認するために業務フロー図を作成
B.設計
- 各要件チケットの内容を元に、仕様記述言語で仕様を作成(Alloy, SPIN, VDM)
- 仕様に矛盾がないことをモデル検査
- 仕様記述言語で書くのが難しそうな画面設計を作成(sphinxとか)
- A-1, B-1, B-2の成果物からBDDのシナリオを生成
- 必要に応じて第三者による仕様レビュー。問題があればAまたはBからやり直し
C.開発/テスト
- BDDの仕様を満たすようにTDDしながら開発で仕様を満たしていることを確認
- CIで下記を回す.問題が出たものはバグチケット化
- どうしてもCIで自動化できない結合テストをマニュアルで実施
- 必要に応じて第三者によるコードレビュー。修正があれば、直してC-2から再度
CIで回すもの一覧
- UnitTest(JUnitとか)
- BDD Test(cucumber/seleniumとか)
- Code Analyze(Sonarとか)
- Dynamic Security Scan(Zed Attack ProxyとかでBDDのシナリオから生成)
D.QAテスト
- 第三者によるQAテスト。A, Bの成果物は連携
E.負荷テスト/運用テスト
- 必要に応じて負荷テストを実施(jmeterとか)
- 必要に応じて仮想環境や検証環境で運用テストを実施(vagrant/chefとか)
F.リリース
- デプロイツールとかで安全かつ低コストでリリース(capistranoとか)
G.リリース後
- バグ管理はチケットへ
- 追加要求はチケットへ
基本的にはウォーターフォールの文脈だけど、アジャイルとかでも一つのイテレーションを切ってみれば似たようなものだと思うのでだいたい同じかな。もちろん仕様変更があったら、要件定義に戻る感じで。
ちなみに人間によるレビューは完全に排除できないと思ってるので入れてる。ツールで見つけられない領域はあるしね。ロジック的には矛盾してないけど、うちでは○○の理由でしないとかは、さすがに検出できないだろうし。
AからCにかけて、基本的に自動検証可能な作りになるので、気軽に仕様変更が出来るはず。正直、仕様が完全に決まる前にCのプロセスに入ることがしばしばあるのだけど
そうしたときに出てくる後付の仕様で、既存が壊れないならまあ、特に仕様変更は問題ないかな。リリース日が変わらなかったら時間的にはつらいがｗ
何気にBが結構大事。ここで自然言語とか使うから、だいたいD当たりで問題が出る...
他の部分は、ちゃんとしてるところならどこでもしてそうだけど、Bを実践してる所はまだ少ないんじゃないかなぁ、と思ったり。
あとは、これを妄想から現実にするために、各種プロセスに適用できるツールを検証しないとかな。Cはある程度実践できてるけど、Bがほとんどしたことがない領域な上に
B-2はB-1と連携出来るようにDSL的なものがいるだろうし、結構大変かも。
それでは、Happy Hacking!
