コンポーネントアプローチによるソフトウェア開発の俊敏性と品質向上の実現～カスタマーショーケース
•Télécharger en tant que PPTX, PDF•
0 j'aime•110 vues
2020年2月4日（火）に UDX GALLERY NEXT で開催された「Embarcadero Tech Vision 20」で発表したときのスライドです。
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à コンポーネントアプローチによるソフトウェア開発の俊敏性と品質向上の実現～カスタマーショーケース
Similaire à コンポーネントアプローチによるソフトウェア開発の俊敏性と品質向上の実現～カスタマーショーケース (20)
Plus de Takuya Tsuchida
Dernier
Dernier (9)
コンポーネントアプローチによるソフトウェア開発の俊敏性と品質向上の実現～カスタマーショーケース
- 1. 本文書の一部または全部の転載を禁止します。本文書の著作権は、著作者に帰属します。 コンポーネントアプローチによる ソフトウェア開発の俊敏性と品質向上の実現 土田 拓也 Mikatus 株式会社 プロダクト開発グループ／デザイングループ グループリーダー
- 2. アジェンダ Mikatus のご紹介 Sencha Ext JS 選定の理由 コンポーネントアプローチによる開発とテスト • DEMO: Sencha Architect と Sencha Test による実装例
- 3. Mikatus のご紹介 • Mikatus のミッション • クラウド税務・会計・給与システム A-SaaS • Adobe AIR から Sencha Ext JS へ
- 7. Adobe AIR から Sencha Ext JS へ 2020年末に Adobe のサポート終了
- 9. Sencha Ext JS 選定の理由 • クラウド税務・会計・給与システム A-SaaS の要件 • エンタープライズ品質の Sencha 製品群
- 10. クラウド税務・会計・給与システム A-SaaS の要件 動作の安定性 データの整合性 計算結果の正確性 デスクトップアプリケーション並みの高速な操作性 最低でも10年以上帳票出力する機能を維持できる保守性
- 11. エンタープライズ品質の Sencha 製品群 十分に検証された高機能コンポーネント群 ベストプラクティスを自然に実現できる統合開発環境 DOM 要素単位ではなくコンポーネント単位での自動テスト環境 エンタープライズ水準のサポート体制 ＋ ＋
- 12. コンポーネントアプローチによる開発とテスト • DEMO: Sencha Architect と Sencha Test による実装例 • コンポーネントアプローチによる開発とテストのベストプラクティス
- 13. DEMO: Sencha Architect と Sencha Test による実装例
- 14. 画面を適切な独自コンポーネントに分割する DOs • 画面を適切な粒度の独自コンポーネントに分割する • 独自コンポーネントに分割するときに画面設計も合わせて見直す DON’Ts • 画面を独自コンポーネントに分割せずに画面を実装する • 画面を細かすぎる独自コンポーネントに分割する • 独自コンポーネントを無理に複数の画面で再利用する • 画面設計のワイヤフレームを不可侵としてコンポーネント分割を進める
- 16. 標準コンポーネントを素直に正しく利用する DOs • 標準コンポーネントを組み合わせて独自コンポーネントを実装する • 標準コンポーネントのコンフィグでコンポーネントの動作を指定する • 標準コンポーネントの公開メソッドでコンポーネントを操作する DON’Ts • 標準コンポーネントを深く継承して複雑なコンポーネントを実装する • 標準コンポーネントの非公開メソッドでコンポーネントを操作する • 標準コンポーネントをオーバーライドしてコンポーネントの動作を変更する • 標準コンポーネントの操作を大量に手続き的に実装する
- 17. 例：実装例の Toolbar を標準コンポーネントに分割する Ext.Button iconCls: x-fa fa-plus text: Add Ext.Button iconCls: x-fa fa-minus text: Delete Ext.Toolbar docked: top Example.view.books.Toolbar
- 18. 独自コンポーネントを公開インターフェイスで疎結合にする DOs • 独自コンポーネントを設定するための公開コンフィグを定義する • 独自コンポーネントを操作するための公開メソッドを定義する • 独自コンポーネントと連携するための公開イベントを定義する • 直接の子であるコンポーネントの公開メソッドを呼ぶ • 下位のコンポーネントに依存する DON’Ts • コンフィグ／メソッド／イベントなどの公開インターフェイスを定義しない • 直接の子でないコンポーネントのメソッドを呼ぶ • 上位のコンポーネントに依存する
- 19. 例：実装例の Toolbar に公開インターフェイスを定義する Configs deleteButtonDisabled : 削除ボタンの有効／無効 Methods enableDeleteButton : 削除ボタンを有効にする disableDeleteButton : 削除ボタンを無効にする Events addButtonClicked : 追加ボタンがクリックされた deleteButtonClicked : 削除ボタンがクリックされた Example.view.books.Toolbar
- 20. 例：実装例の Grid に公開インターフェイスを定義する Example.view.books.Grid Methods createNewBook : 新しい本を作成する deleteSelectedBook : 選択された本を削除する Events bookSelected : 本が選択された bookDeselected : 本の選択が解除された
- 22. 独自コンポーネントのインターフェイスを自動テストする DOs • 独自コンポーネントの公開インターフェイスを自動テストする • REST API の通信は SimManager と Simlets でモックにする • テストカバレッジを参考にしつつテストを充実させる DON’Ts • 独自コンポーネントをテストしない • テストカバレッジ100%を必達にする
- 25. Sencha Architect と Sencha Test による実装手順 サンプルアプリケーションの実装手順は下記記事参照 • Sencha Architect と Sencha Test で開発環境を構築する • Sencha Architect と Sencha Test の開発環境に REST API モックサーバーを追 加する • Sencha Architect でコンポーネントを実装して Sencha Test で自動テストす る
- 26. まとめ コンポーネントアプローチで開発できる Sencha Ext JS にしよう ビジュアル開発できる Sencha Architect で始めよう Sencha Test によるコンポーネントテストで品質を担保しよう ＋ ＋
Notes de l'éditeur
- ここからは、コンポーネントアプローチによる Web アプリケーション開発の事例について Mikatus 株式会社の土田が発表させていただきます。
- 本日のアジェンダはこのようになっておりまして、当社 Mikatus をご紹介させていただいた後に、当社のプロダクト開発でなぜ Sencha Ext JS を選定しているかを説明し、コンポーネントアプローチによる開発とテストをする中で実際に見えてきたベストプラクティスをデモを混じえつつお話させていただきます。
- それでは、まずはじめに当社 Mikatus についてご紹介させていただきたいと思います。
- 当社 Mikatus 株式会社は、「税理士のみなさまにとって、なくてはならない存在として」というミッションを掲げ、税理士のみなさまないしは税理士が所属する会計事務所に向けてサービスを提供する会社となっております。昨年社名をアカウンティング・サース・ジャパンから変更してミカタスになりました。前の社名だと聞き覚えのある方がいらっしゃるかもしれません。さて、当社は税理士の皆様に向けて幅広くサービス提供をしておりますが、
- クラウド税務・会計・給与システム A-SaaS が主力製品となっておりまして、会計事務所の仕事を一気通貫でクラウドでできるサービスとなっています。
- A-SaaS の画面のひとつはこのようなものになっていまして、見ていただくとおわかりかと思いますが、グリッドやテキストフィールド、ボタンなどの要素が詰まった UI になっています、昔ながらのプロフェッショナル向けの業務アプリケーションという印象を受けられるのではないでしょうか。そして、こちらのアプリケーションは Adobe AIR で開発されています。10年程前に創業したときの選択肢としてはそんなに悪くなかったと思うのですが、
- Adobe Flash プラグインの配布終了に伴い、Adobe AIR の Adobe によるサポートも2020年末に終了することになりました。その移行先として当社は Sencha Ext JS を選定しました。その理由はのちほどのスライドで説明させていただきますが、実施に Sencha Ext JS で作り直しているアプリケーションは、
- このようなものです。Adobe AIR で開発したアプリケーションの UI をある程度踏襲しながら開発しているので似てはいますが、完全にブラウザー上で動作しています。Sencha Ext JS での開発が進み Adobe AIR で開発されたアプリケーション以上のものができあがりつつあります。
- 改めて、なぜ当社が Sencha Ext JS を選定するに至ったかを簡単にご説明差し上げたいと思います。
- 会計事務所向けの業務システムということで複雑な業務ロジックが含まれることは想像に難くないと思います。要件としても、動作の安定性やデータの整合性、計算結果の正確性などは当然求められますが、クラウドで提供するにあたりデスクトップアプリケーション並みの高速な操作性はチャレンジングな要件となってきます。また、法律の関係で10年以上は帳票が出力できることを維持しなければなりません。この中で、動作の安定性と高速な操作性、保守性はクライアントアプリケーションにおいて重要な要件になってきます。その要件を満たすようなフレームワークとして、
- エンタープライズ品質の Sencha 製品群を当社は選定しました。十分に検証され、高機能なコンポーネントを持つ Sencha Ext JS のみならず、ベストプラクティスを自然に実現できる統合開発環境である Sencha Architect やコンポーネント単位でテストを書けるテスト環境 Sencha Test など、Sencha 製品群によるエコシステムが高品質な業務システム開発に貢献します。移り変りの早いフロントエンド界隈ですが、エンタープライズ向けということもあり、長期に渡ってサポートされるところも重要なポイントです。
- これまで当社は Sencha を導入してコンポーネントアプローチによる開発を行ってきました。サンプルアプリケーションによるデモをした上で、当社なりのコンポーネントアプローチによる開発とテストのベストプラクティスをご紹介したいと思います。
- デモでお見せする実装例は本の一覧を管理するアプリケーションです。実装例について簡単に動作を説明した後に、自動テストを実行してお見せしたいと思います。今回はコードの詳細は時間の関係で割愛しますが、ベストプラクティスはこの実装例を元に説明したいと思います。（デモへ移動）デモでお見せする実装例はとてもシンプルなものとなっています。本の一覧になっていて、タイトルと著者を編集できます。選択して削除することもできれば、新規作成することもできます。シンプルなアプリケーションではありますが、ツールバーの部分とグリッドの部分はコンポーネントとして分かれていまして、それぞれを独立してテストできるようになっています。そのテストを実行してみたいと思います。（テスト画面へ）一瞬なので見逃さないようにしてください。（テスト実行）はい。このようにコンポーネントごとに独立してテストを実行しています。もう一度実行しますね。今度はテストでコードカバレッジを取得するようにしてみます。（カバレッジ実行）コードカバレッジもこのように取得できるので、ある程度テストケースを実装するときの参考になるかと思います。このような形でアプリケーションを開発するときには各コンポーネントを独立して実装してテストをしながら開発を進めることで品質の高いアプリケーションが実現できます。そのような開発をしていくためのベストプラクティスをスライドの後半でご紹介していきたいと思います。
- 今お見せしたアプリケーションではコンポーネントごとにテストを実施しました。アプリケーション開発をする上で画面を適切な粒度のコンポーネントに分割することは重要です。また、コンポーネントに綺麗に分割できないときは画面設計においＵＸ上の課題があることが多いので、画面設計に立ち返ってみることをオススメします。その一方で、コンポーネントに分割せずに開発したり、ボタンひとつひとつを独自コンポーネントとして定義しないようにしましょう。独自に作成したコンポーネントを再利用し過ぎるのも問題になることが多いので注意してください。ある画面のためだけに独自コンポーネントに機能を追加し始めたら赤信号です。
- 実装例のアプリケーションはブックスツールバーとブックスグリッドにコンポーネント分割をしています。それらのコンポーネントをブックスメインが包含して接続しています。
- 独自のコンポーネントを実装する際には当然 Sencha が用意している標準コンポーネントを利用します。それらを素直に正しく組み合わせて独自コンポーネントを実装してください。よく考えられたコンフィグやメソッドが各標準コンポーネントに準備されています。それらを使用しましょう。ただし、それらを何度も継承して複雑なコンポーネントを実装しないようにしましょう。また、標準コンポーネントの非公開メソッドを使用したり、Sencha 独自の機能であるオーバーライドという方法で標準コンポーネントの内部動作を 変更するのはやめましょう。手続的にではなく、できるかぎり宣言的に実装するのもポイントです。
- これはツールバーの例ですが、当然 Sencha の標準コンポーネントで構成されています。ツールバーは標準のツールバーで実装していますし、追加と削除のボタンは標準のボタンです。そのコンフィグを利用してアイコンやテキストを表現しています。ここまでシンプルなコンポーネントばかりではないですが、自然で素直な方法で実装できていることが理想です。
- さらに独自コンポーネントはできる限り疎結合になるように実装しましょう。公開インターフェイスとしてコンフィグ・メソッド・イベントを定義します。メソッドによる連携は直接の子どものコンポーネントに限定して、下位のコンポーネントだけに依存するようにしましょう。そうしない場合、どの機能を使用していいかわからないので複数人で開発していると思いもよらない密結合が発生し、保守性が著しく下がってしまうことがあります。
- 実装例のツールバーで言えば、削除ボタンの有効無効を切り替えるコンフィグがあります。本を選択していないときは削除ボタンをクリックできなくしたかったからです。その削除ボタンを有効にしたり無効にしたりするメソッドがありますし、追加と削除のボタンがクリックされたときに発火するイベントも定義されています。このコンポーネントについて言えば、この公開インターフェイス以外を触らないでくださいということになります。このあたりを開発チームでルール化しておくと開発が安定するかと思います。
- グリッドの公開インターフェイスもシンプルです。新しい本を作成するメソッドと選択された本を削除するメソッドだけが公開メソッドです。本が選択されたり解除されたりしたときはツールバーの削除ボタンの有効無効と連携したいので、本の選択状態に対応するイベントも定義しています。
- 本を選択して削除する処理の流れをシーケンス図に起こしたものです。ツールバーとグリッドが子でメインが親です。必ず親との連携はイベントで、子との連携はメソッドになっています。コンポーネントはこのような形で疎結合にしておくのがオススメです。
- 独自コンポーネントを疎結合にしておくとそのコンポーネントを自動テストしやすくなります。独自コンポーネントをテストするときは公開インターフェイスを自動テストするようにします。REST API の通信は SimManager と Simlets という Ext JS の機能でモックにすることができます。先程お見せしたようにテストカバレッジも出るので、それを参考にテストを充実されていきましょう。テストをしないというのは問題ですが、テストカバレッジ100%を常に目指してテストをし過ぎるのも問題になったりします。何事もバランスですね。
- 先程のシーケンス図で言うところの各コンポーネントの処理を独立してテストします。
- そのとき各コンポーネントのインターフェイスを入力と出力の観点でテストしていくといいです。
- 今回の実装例の詳細は時間の都合で別の記事として書いていますので、手元の環境で試してみたい方はこちらを参考にしてみてください。
- 最後にまとめますと、コンポーネントアプローチで開発できる Sencha Ext JS はエンタープライズ品質のアプリケーションを開発する上でオススメです。最初はビジュアル開発できる Sencha Architect が取っ付きやすくていいと思います。Sencha Test によるコンポーネントテストも一緒に実施することで複雑なアプリケーションでも高い品質を担保できます。ぜひ試してみてください。
- ご清聴ありがとうございました。