Keywords
- architect - Component Oriented - Atomic Design - React.js - GraphQL - Bootstrap - Styled Component
社内管理システムのための技術選定February 21th, 2019Kenju WagatsumaCookpad Inc.
View Slide
TOC・社内管理システム開発の「目的と制約」「戦略と戦術」「裏目的」・なぜコンポーネント指向か・なぜ Atomic Design か・なぜ React.js か(なぜ Vue.js / jQuery ではないか)・なぜ GraphQL か(なぜ REST ではないか)・なぜ Bootstrap & Styled Components か(なぜ Antd / Material Design ではないか)・品質を維持するために・開発に最小限必要なスキル
社内管理システム開発の目的と制約
社内管理システム開発の「目的と制約」目的・業務をスムーズに推進できる土台を作り、 事業の成果に貢献すること制約・フロントエンドエンジニア専任がいない・社内管理システム以外のプロジェクトも多く存在する
社内管理システム開発の「戦略と戦術」戦略・いかにコスパよく新規開発画面を開発するか、 技術力および仕組み化で解決する戦術・ある程度レールを引くことで、 一貫性のあるコード をチームで開発する・仕組みやデザインガイドラインを設けることで、 「考えること」を減らす・コンポーネント指向で開発することで、仕様の変更に柔軟に対応できる可能性を極大化する・「スタイル」「機能」「データ」 を一箇所に閉じ込めることで、変更スコープを極小化する
社内管理システム開発の「裏目的」裏目的・メンバーのキャリアアップにつながる技術選定をしたい ・モチベーション・マネジメント&成長の機会の提供・社内管理システム以外のプロジェクトとも親和性を高くしたい ・再現性&再利用性の高い開発
正しい技術選定をするために(超重要)!!!超重要!!!・あくまで「事業の成果に貢献すること」 が目的・適材適所で REST / haml / jQuery / Bootstrap など慣れたツールを使うことも正しい判断の一つ技術選定の難しさ・品質コントロールのために、あえて枯れた技術を使うことが選定者に求められること・チャレンジする領域の取捨選択も判断の内
なぜコンポーネント指向か
SFD-Component(Style-Function-Data Component)DataFunctionStyleComponentBootstrap /Styled ComponentBusiness LogicGraphQL /Apollo ClientReact.js
なぜコンポーネント指向か仕様の変更に柔軟に対応できる可能性を極大化するため・”持ち運びできる” ようなコンポーネントを実現する・再利用性を高める(同チームの他社内管理システムも含む) ・「コンポーネントを育てる」ようなイメージ
なぜ Atomic Design か
なぜ Atomic Design か考えることを減らすため・「どの粒度で」コンポーネントを分割すれば良いかの指針となる・自然とコンポーネント指向で考えるようになる
Atomic Design GuidelineComponent Definition ExampleAtoms minimum components button / input / toast / label / panelMoleculeshave side effects(useState / useEffect / useContext)input / pagination / selector / popupOrganismshandle multiple events /use GraphQLchart / form / list / tableTemplates wireframe level header / footerPages per #index or #show actions -
なぜ React.js か(なぜ Vue.js / jQuery ではないか)
なぜ React.js かコンポーネント指向が実質的な制約となるため・Vue.js でない強い理由はない( React.js か Vue.js か Ember.js か... フレームワークは関係ない)・jQuery でもコンポーネント指向は可能だが、設計力とメンバー全員の技術力が必要 ・参考)M3 Tech Blog “React.js, Vue.jsが使えない状況でメンテナンス性の高いJavaScriptを書く3つのポイント”・ライブラリや知見も十分に揃ってきており、仕様を満たすために必要十分 ・「jQuery にしかできない」がほぼない
なぜ GraphQL か(なぜ REST ではないか)
なぜ GraphQL か仕様の変更に柔軟に対応できる可能性を極大化させるから・Controller からは疎結合な Single Endpoint・Apollo Client を用いて「データ」を「機能」と同じコンポーネントに配置するSchema がチーム開発における品質担保のための強力なツールとなるから・レガシーバージョンからの移行作業を抽象化するためでもある ・参考:Speakerdeck “Frontend Re-architecture of a decade-old Rails App』”
なぜ Bootstrap &Styled Components か(なぜ Antd や Material Design ではないか)
なぜ Bootstrap & Styled Components か学習コストの調整・社内でも広く使われ、開発者も慣れた API がおおいSFD-Component を実現するために・Styled Components の考え方を用いてスコープを閉じていきましょう・直接 class を使うのではなく、 や など抽象化していきましょう・Bootstrap 自体のアップデートや別のフレームワークへの切替時の 抽象レイヤーとしても機能
(再)SFD-ComponentDataFunctionStyleComponentBootstrap /Styled ComponentBusiness LogicGraphQL /Apollo ClientReact.js
品質を維持するために
品質を維持するためにUnit Testing / E2E Testing・開発環境および本番環境での確認は開発者で担保することGraphQL・GraphQL は可能な限り薄く。テストがほしいと感じたら fat になっている証拠・Model および Service class 側できちんとテストを書くReact.js・見た目のテストは Snapshot Testing(Jest)を使ってコスパよく書く
開発に最小限必要なスキル
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 の処理方法
GraphQL 開発に最小限必要なスキル・GraphQL スキーマの基本的な読み方・書き方・graphql-ruby の API と使い方・Apollo Client を用いた Client 側の実装
Thank you!