Upgrade to Pro — share decks privately, control downloads, hide ads and more …

社内管理システムのための技術選定

 社内管理システムのための技術選定

Keywords

- architect
- Component Oriented
- Atomic Design
- React.js
- GraphQL
- Bootstrap
- Styled Component

Ken Wagatsuma

February 21, 2019
Tweet

More Decks by Ken Wagatsuma

Other Decks in Programming

Transcript

  1. 社内管理システムの
    ための技術選定
    February 21th, 2019
    Kenju Wagatsuma
    Cookpad Inc.

    View Slide

  2. TOC
    ・社内管理システム開発の「目的と制約」「戦略と戦術」「裏目的」
    ・なぜコンポーネント指向か
    ・なぜ Atomic Design か
    ・なぜ React.js か(なぜ Vue.js / jQuery ではないか)
    ・なぜ GraphQL か(なぜ REST ではないか)
    ・なぜ Bootstrap & Styled Components か(なぜ Antd / Material Design ではないか)
    ・品質を維持するために
    ・開発に最小限必要なスキル

    View Slide

  3. 社内管理システム開発の
    目的と制約

    View Slide

  4. 社内管理システム開発の「目的と制約」
    目的
    ・業務をスムーズに推進できる土台を作り、 事業の成果に貢献すること
    制約
    ・フロントエンドエンジニア専任がいない
    ・社内管理システム以外のプロジェクトも多く存在する

    View Slide

  5. 社内管理システム開発の「戦略と戦術」
    戦略
    ・いかにコスパよく新規開発画面を開発するか、 技術力および仕組み化で解決する
    戦術
    ・ある程度レールを引くことで、 一貫性のあるコード をチームで開発する
    ・仕組みやデザインガイドラインを設けることで、 「考えること」を減らす
    ・コンポーネント指向で開発することで、仕様の変更に柔軟に対応できる可能性を極大化する
    ・「スタイル」「機能」「データ」 を一箇所に閉じ込めることで、変更スコープを極小化する

    View Slide

  6. 社内管理システム開発の「裏目的」
    裏目的
    ・メンバーのキャリアアップにつながる技術選定をしたい
     ・モチベーション・マネジメント&成長の機会の提供
    ・社内管理システム以外のプロジェクトとも親和性を高くしたい
     ・再現性&再利用性の高い開発

    View Slide

  7. 正しい技術選定をするために(超重要)
    !!!超重要!!!
    ・あくまで「事業の成果に貢献すること」 が目的
    ・適材適所で REST / haml / jQuery / Bootstrap など慣れたツールを使うことも正しい判断の一つ
    技術選定の難しさ
    ・品質コントロールのために、あえて枯れた技術を使うことが選定者に求められること
    ・チャレンジする領域の取捨選択も判断の内

    View Slide

  8. なぜコンポーネント指向か

    View Slide

  9. SFD-Component
    (Style-Function-Data Component)
    Data
    Function
    Style
    Component
    Bootstrap /
    Styled Component
    Business Logic
    GraphQL /
    Apollo Client
    React.js

    View Slide

  10. なぜコンポーネント指向か
    仕様の変更に柔軟に対応できる可能性を極大化するため
    ・”持ち運びできる” ようなコンポーネントを実現する
    ・再利用性を高める(同チームの他社内管理システムも含む)
     ・「コンポーネントを育てる」ようなイメージ

    View Slide

  11. なぜ Atomic Design か

    View Slide

  12. なぜ Atomic Design か

    View Slide

  13. なぜ Atomic Design か
    考えることを減らすため
    ・「どの粒度で」コンポーネントを分割すれば良いかの指針となる
    ・自然とコンポーネント指向で考えるようになる

    View Slide

  14. Atomic Design Guideline
    Component Definition Example
    Atoms minimum components button / input / toast / label / panel
    Molecules
    have side effects
    (useState / useEffect / useContext)
    input / pagination / selector / popup
    Organisms
    handle multiple events /
    use GraphQL
    chart / form / list / table
    Templates wireframe level header / footer
    Pages per #index or #show actions -

    View Slide

  15. なぜ React.js か
    (なぜ Vue.js / jQuery ではないか)

    View Slide

  16. なぜ React.js か
    コンポーネント指向が実質的な制約となるため
    ・Vue.js でない強い理由はない( React.js か Vue.js か Ember.js か... フレームワークは関係ない)
    ・jQuery でもコンポーネント指向は可能だが、設計力とメンバー全員の技術力が必要
     ・参考)M3 Tech Blog “React.js, Vue.jsが使えない状況でメンテナンス性の高いJavaScriptを書く3つのポイント”
    ・ライブラリや知見も十分に揃ってきており、仕様を満たすために必要十分
     ・「jQuery にしかできない」がほぼない

    View Slide

  17. なぜ GraphQL か
    (なぜ REST ではないか)

    View Slide

  18. なぜ GraphQL か
    仕様の変更に柔軟に対応できる可能性を極大化させるから
    ・Controller からは疎結合な Single Endpoint
    ・Apollo Client を用いて「データ」を「機能」と同じコンポーネントに配置する
    Schema がチーム開発における品質担保のための強力なツールとなるから
    ・レガシーバージョンからの移行作業を抽象化するためでもある
     ・参考:Speakerdeck “Frontend Re-architecture of a decade-old Rails App』”

    View Slide

  19. なぜ Bootstrap &
    Styled Components か
    (なぜ Antd や Material Design ではないか)

    View Slide

  20. なぜ Bootstrap & Styled Components か
    学習コストの調整
    ・社内でも広く使われ、開発者も慣れた API がおおい
    SFD-Component を実現するために
    ・Styled Components の考え方を用いてスコープを閉じていきましょう
    ・直接 class を使うのではなく、 や など抽象化していきましょう
    ・Bootstrap 自体のアップデートや別のフレームワークへの切替時の 抽象レイヤーとしても機能

    View Slide

  21. (再)SFD-Component
    Data
    Function
    Style
    Component
    Bootstrap /
    Styled Component
    Business Logic
    GraphQL /
    Apollo Client
    React.js

    View Slide

  22. 品質を維持するために

    View Slide

  23. 品質を維持するために
    Unit Testing / E2E Testing
    ・開発環境および本番環境での確認は開発者で担保すること
    GraphQL
    ・GraphQL は可能な限り薄く。テストがほしいと感じたら fat になっている証拠
    ・Model および Service class 側できちんとテストを書く
    React.js
    ・見た目のテストは Snapshot Testing(Jest)を使ってコスパよく書く

    View Slide

  24. 開発に最小限必要なスキル

    View Slide

  25. React.js 開発に最小限必要なスキル
    ・ECMAScript 6 の基本的な文法(Class / Arrow Function / let&const / Template Strings / Promise /
    destructuring / Rest parameters / Spread syntax / Module system)
    ・JSX の基礎文法
    ・props / state の使い方、もしくは Hooks API
    ・Lifecycle (componentDidUpdate / componentDidMount, etc.)
    ・HTML Events の処理方法

    View Slide

  26. GraphQL 開発に最小限必要なスキル
    ・GraphQL スキーマの基本的な読み方・書き方
    ・graphql-ruby の API と使い方
    ・Apollo Client を用いた Client 側の実装

    View Slide

  27. Thank you!

    View Slide