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

Keywords

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

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