プロジェクト振り返りとDI/AOPの利点
長かったプロジェクトもようやく安定稼動に近づきつつある。
おめでとうございます。
改めて今回のフレームワークについて考え直してみると
作ってるときには気づきにくかった（うまく隠蔽されてた）利点が
ちょいちょいあったのでちょろっと書いておきます。
結構な大規模プロジェクトであったものの、特筆するほど変わった点はないですが。
プロジェクトの特徴
- 大規模
- BtoB
- 若手が多く、スキルにはばらつきあり
- オンラインメイン（じゃないとこもあるけど）
良かったこと
テストは、DIでstubとimplがソース修正なし（設定ファイルのみ）で可能なためStubの切り替えが楽。
JSF使ってるのもありPOJOとしてJUnitでの単体テストがやりやすかった
あとJUnitをラップしたテスト用のフレームワークがあったのもやや意味ありか。
担当範囲ごとの進めやすさは、これもやっぱりstub。
interface使って実体を意識させない疎結合になっているので
「〇〇ができてないから、こっちのテストが・・」とかはなかった。
共通モジュールも結構あり、大規模分業制にならざるを得なかったのでこれは必要。
ログはアプリチームで噛むことは少なかったけど、プロセス実行ログとかまさにAOP。
あとトランザクション制御は完全にミドル以下制御だったので
もしこれがなく各実装者依存だったら結合テスト以降どっかで死んでいたでしょう。
改善できたこと
プロジェクトの性質上、プログラム仕様がガチガチに決まっている（というか現行どおり）ので
再利用できたモジュールとか、クラスの責任範囲なんかはごちゃごちゃ。
トランザクションスクリプトには当たるのだろうけど同じような事を結構ごちゃごちゃしてる気がするなぁ。
ロギングはメッセージミドルとspringの住み分けが微妙なところに。
デバッグ用にログ出そうと思っても、切り替えが結構めんどくさい。。。
stubを使ったテストは、そのstubのただしさをどこかで保証しないと。
stub作るのも呼び出し側だったからオレオレテストになりがち。
振り返り、大事ですね。まだまだ勉強が足りん。
