検証ツールを使用するべき理由
前回内容はこちら
今回は2つのアーキテクチャの検証ツールについて確認していきます。
検証ツールを利用するべき理由として以下の3つが挙げられています。
検証ツールを使用すべき理由
- スピードの向上
- 安全性の向上
- 効率の向上
手動でも検査は可能ですが、時間がかかるし問題や違反の見落としにつながる可能性もありため検証ツールの利用が推奨されています。
2つの検証ツール
検証ツールには以下の2つが挙げられています。
- Discovery
- Architecture DashBoard
それぞれ簡単に見ていきます。
Discovery
アーキテクチャの改善方法を分析、評価、理解しやすくするためのビジュアルツールでForgeから無料ダウンロードが可能なツールです。
このツールを使用するとモジュールが可視化され、命名規則に従ってArchitectureCanvasのレイヤーに自動で分類される。 （いつでも手動で他のレイヤーに移動することも可能）
モジュールがレイヤー別に分類されている状態で、モジュール間の依存関係を分析し、さらに各モジュールで参照されている要素も特定します。あるモジュールが利用している他のモジュールの要素のほか、他のモジュールで利用されているそのモジュールの要素をいつでも確認できます。
問題が検出された場合、Discoveryはその原因になっている利用中の要素を特定して適切に適用されていないアーキテクチャ検証ルールを指摘し、考えられる改善策を提案します。
またDiscoveryにはアプリケーションの依存関係や適用されていない検証ルールを指摘するアプリケーションのビューも存在する
Architecture Dashboard
Architecture DashboardはOutsystemsの技術的負債監視ツールであり利用することでユーザはアプリケーションポートフォリオを視覚化して問題を特定することができ、開発者はベストプラクティスに従って一般的なリスクを回避することができます。このシステムは無料で利用できる上にOutsystemsによって完全にサポートされています。
Architecture Dashboardの分析の種類（頻出）
- コード解析
- パフォーマンス、セキュリティ、アーキテクチャ、保守性に関連するパターンを明らかにすることがねらい
- ランタイムパフォーマンス分析
- LifeTimeの分析データを使用する。
Dashboardの見方
このツールが提示するコードパターンのコードパターンのリストは技術的負債や頻度といった基準でソートすることができ、検出されたコードのセクションには、そのパターンが及ぼす影響と修正方法のヒントが表示されます。
なにでソートできるかは覚えときましょう。
さらにこのツールにはインフラ内のアプリケーションを表示するビューもあり、各アプリケーション内のコードパターンを解析することが可能です。
カラーコードは５色で
赤色は俊敏性のレベルが低く、緑は俊敏性のレベルが高いことを示していて
レベルが高いほど優れていて、検出されたコードパターンが少ないか他のパターンに比べて影響が小さいことを示しています。
モジュールに関しても同様のビューを備えており、各モジュール内のコードパターンを解析することができます。
検証ツールの対象者(頻出)
対象者となるのは下記３パターンである。※テストでます！
- アーキテクト
- インフラ内の全てのアプリの技術的負債を確認し、アーキテクチャの発展状況を把握するうえで役立つ
- チームリーダー
- チームのアプリの技術的負債を確認できるようになる
- 開発者
- アプリの技術的負債を特定して修正し、ベストプラクティスを遵守できる
対象者は誰か選択させる問題が出ることがあるので覚えておきたいです。
まとめと次回予告
今回から独断と偏見による「頻出」の文言を追記しました。最後の追い込みでヤマをはる時以外は素直に全部覚えてほしいですがこういうのがあると自分的にも見返しやすいなと思い書いてみました。
信頼度40％くらいと思って参考にしてみてください！
前回同様最低限これだけは覚えて帰ってくださいというのを置いておきます！
検証ツールの対象者３パターン
- アーキテクト
- チームリーダー
- 開発者
次回はライブラリモジュールパターンについて学習していきます。
コメント