設計方法
最近は会社がコストに厳しくなった影響で、仕事を分割してこなす
方法が求められてる。
というわけで、設計の文書化が必要なんだけど、いままで極少人数でしか
実装とテストを回してこなかったので、その辺りが得意じゃない。
最近考えたことのメモ
要求
どういう条件下で何がやりたいか？
まぁ、基本的にはお客さんが書くものなのであんまし関係ないというか、
自分たちは要求作成の補佐役でしかない。
機能仕様
テストが作れるように書く
何を作るか？
どういう条件で何をすると、何が発生するのかを明確にする。
内部仕様
どう作るのかがわかるように。設計レビュー用。
自分が他人のコードをレビューするときに必要な情報を書く
- シーケンス(機能の使用条件が網羅されているかどうかを確認する)
- データ構造(機能がアクセスするデータを明確にすることで、コードが正しいかどうかを確認する)
機能仕様と内部仕様を見ればコードレビューができるようにすればOKなんじゃないかと思ってる。
自分がよくやるミス
- シーケンス書くのが当然過ぎて、サボって、実は呼び出し条件に漏れがあることが発覚
- ちょっとした改善のつもりで、機能仕様を変えてたとか
1.の改善
grep?
2.の改善
その変更は、機能仕様に影響を及ぼさないか？影響がある場合どういう影響なのかを事前チェックする。
