Doge log

Abby CTO 雑賀 力王のオフィシャルサイトです

最近DIとAOPに思うこと その1

DI-AOPで処理を織り込んで行く場合にはDI-AOPな設計書フォーマットがないと不便な気がする。
え?なんでそんなこと気にするかって?
いくらなんでもテストファースト、TDDが盛んだからってインスペクション(レビュー)をやらないわけにはいかんでしょ??

  • 設計書通りに機能が実現されているか?

って誰がどうやって保障するのか?
「そんなのテストしてればわかるさー」と思う人もいるかもしれない。
だが世の中設計者と実装者が別というパターンがよくある。
実装者からすると「知らないものは知りえない」ため

  • 設計自体の不備
  • 設計書自体の不備
  • 設計書を読み間違えた

が発生すると品質的にはかなり悪くなってしまう。
(実装者が設計不備を指摘することも考えられるけど)
それらを防ぐためにも設計書とのすり合わせは必須といえよう。
また後工程になればなるほど修正コストは増加する一方なので事前のインスペクションは必須であるといえる。

でじゃあ実際にインスペクションを行おうとするわけだがSpringFrameworkなどDIを使用する場合

  • 機能全体把握しにくい
  • 処理順序などがわかりにくい
  • 設計書と設定ファイルのマッピングにギャップが発生

という問題が出てくる。

機能内の小機能レベル(依存を注入するクラスレベル)のインスペクション自身は特に問題がない。たがビジネスロジックはそういった小機能の組み合わせで実現される。
そのため小機能の処理順序、処理の前後関係を確認する場合には設定ファイルなども含めインスペクションしなければならない。
だが設計者は機能自体を設計しており下位のフレームワークがなんであるか意識して設計していないことが多くそれらを説明したり理解してもらうのにかなり時間がかかってしまうのである。
もちろん設計書もDIなんて意識していないので実ソースと設計書のマッピングができない。
結局ちゃんとマッピングができないとインスペクションしても意味がなくなり品質確保が難しくなってしまうのである。

なのでDI-AOPな設計書フォーマットがないと導入が辛いなあっていうのが正直な感想だなあ。
うくく。