【勉強会まとめ】クラスメソッドのモバイル開発を知る!全5回〜第4回 Webフロント開発編〜 に参加してきたのでまとめる
概要
クラスメソッド社のモバイル開発の中の Webフロントエンド開発に関する発表
セッションは以下の3つ
- Atomic Design with React
- React のレガシープロジェクトと戦って得た戦果
- クラスメソッドで働き始めたサーバサイドエンジニアの8ヶ月間
- 終了後に懇親会
Atomic Design with React
登壇者：清田 隆志 さん
- Director / UI Designer / 半熟 Web Frontend Engineer
- 元々 Director と Designer 出身で今はフロントエンドをやっている
- 開発は東京
開発しているサービスについて
スマホアプリ開発のカスタマーストーリーモバイル｜クラスメソッドのサービス
- 現在は SaaS プラットフォームの開発で、CMS の管理画面を担当している
- SPAでクライアントサイドは React を利用している
- バックエンド は AWS AppSync という GraphQL サービスを利用している
- AWS のマネージドサービスの開発
Atomic Design をつかったコンポーネント管理について
- Atomic Design → UIコンポーネントを atom(原子) , molecules(分子), organisms(生体), templates(テンプレート), pages(ページ) に分割し整理・管理する手法
- 管理画面のUIを顧客が自分で細かくカスタマイズできる仕様のためコンポーネントを細分化して利用する必要があった
- デザインツールとして invision を利用している
- 具体的な Atom の分割単位は HTML のタグレベル
- 実際の開発では以下のレベルでコンポーネントを管理している
- atom → ラベル、テキスト、入力欄、ボタンなど
- molecules → 検索フォーム
- organisms → ヘッダー、フッター、モーダル、テーブル、フォームなど
- コンポーネント管理単位のはチーム内で話し合って決める
Atomic Design with React
- 基本的にAtomic Design の流儀に乗るのが良い
- 最初からAtom 層を作るのは難しい → ログインフォームとかある程度の塊から作り、そこから Atom を抽出していく
- React のコンポーネントを atom の単位で作成
- ReactコンポーネントをStoryBook を使ってコードからスタイルガイドを作成することで効率良くかつ保守しやすい開発をしていく
- スタイルガイドドキュメントを地力で作るのはつらい
- AbemaTV の開発で使われている
- 実際にどのように使うかはStorybookのサンプルと Atomic React というオープンソースがあるのでそこで確認できる
所感🤔
- Atomic Design を実際に運用している例を聞くことはあまりなかったので、大変貴重な機会だった
- Atomic Design が React にマッチしてるのがよくわかった🧠
- なんとなく受託開発で納期優先ならStoryBook を使ってコンポーネント管理していくとこまで時間かけれなさそうだけど、納品したあとも保守する前提なのかな？🤔
- コンポーネントの定義をどのように分類するかはチームでよく話し合わないとあとでめちゃくちゃになりそう😇
- エンジニアしかいない（デザイナーがいない）チームだとCSS周りとかつらそうだと思った。
- 懇親会でお伺いしたが登壇者の方が元々デザイナー出身のフロントエンド開発者なので CSS まわりも問題ないそうで。うらやましい。
- 全体的にスライドがキレイだった
- 大阪のおすすめスポットについて質問されていたが、自分的には観光なら京都に行かれては？と思った🚆
React のレガシープロジェクトと戦ってきた戦果
登壇者：伊勢洋平 さん
- フロントエンド開発
- 主にRuby on Rails の開発をやっていた
- React 歴は浅め
開発しているサービスについて
- モバイルアプリサービス
- React + Rails
- Redux
- AWSAppSync(GraphQL)
React の 開発環境
- SPA で React と Rails は別で管理している。 Git リポジトリも別
- SPA なので ルーティングはクライアント側で行っている
- 認証機能を自前で実装せず、Amazon Cognito を利用している
- React で GraphQL のエンドポイントを叩くのに react-apollo を利用している
- より安全な開発のために React コンポーネントは Class を使わずに 純粋関数で記述しStateless Functional Component を実現している
- Stateless Functional Component で開発するために recompose を利用している
- フロントエンドは 開発環境設定に凝ると時間を使いすぎてしまう → 環境構築は react-create-app
- プロジェクトがレガシー化するのがはやい → つらい
- チーム開発でコードレビューでの無駄なやりとりをなくすために eslint + prettier を利用している
- コンポーネントの引数に props を渡すときは展開式 を使うと props に何が入るかわかってよい
const button = props => {...} // NG パターン const button = ({ height, width }) => {} // OK パターン
- Flow を使って型定義を行い、実行時エラーの前にビルド時点でエラーを検知できるようにする。
- JS に型定義を持ち込むには Flow と TypeScript があるが、Flow は TypeScript よりも既存プロジェクトへの追加が容易。
- ただしTypeScriptにくらべ型情報が少ない。開発初期から使うなら TypeScript がよい
所感🤔
- JSに足りない安全安心な開発を React で行うための施策がたくさん盛り込まれていた。素晴らしい。
- recompose はつかったことないので使って見たい
- Vim@terminalでReact 書いていらっしゃったようだが、元々 Rails 出身ならなんとなく納得。Vim の入力補完で React とか対応しているんだろうか？
- GraphQL はサーバーサイドの実装がつらそうなイメージだったが、AWS AppSync はデータ設定を正しく行うだけで クライアントからGraphQL APIが利用できるようになるらしい
- 改めてReact は開発を始めるまでに準備しないといけないことが多すぎる
- 懇親会の時にデファクトスタンダードな設定がないことがつらいとみんな行っていた。
クラスメソッドで働き始めたサーバサイドエンジニアの8ヶ月間
登壇者：木田 亮介 さん
クラスメソッド社のアプリ開発について
- モバイルアプリサービス部の話
- 受託のアプリ開発がメイン
- 特に小売業向けのモバイルアプリ開発（カスタマーに近い立場のアプリが多い）
- サーバーサイドの利用する言語フレームワークはプロジェクトの特性やチームメンバーのスキルによる
- CMSなどわりと軽めのサービスの場合 → Ruby On Rails
- 高負荷なアプリケーションの場合 → Java Scala, Go
- フロントエンドは React Angularが使われる
クラスメソッドに転職する前と後の話
技術スタック
- 転職前 → php, Laravel , angular2, typescript
- 転職後 → SpringBoot(Java) , PlayFrameWork(Scala), Rails , AWS
転職前に経験のない分野だったが、先輩が優しく教えてくれる
時間かかってもいいと言ってもらえたのが心強かったそう。
怒られない、キレられない🤣 というパワーワード
- 年収が上がった（割と具体的にわかるレベルの話をしてくれた😅）
- 前の職場では技術的な話ができる人がいなかったが、クラスメソッドは優秀なエンジニアが多い
- クラスメソッド社の中でもブログを書くエンジニアは強いエンジニアらしい👨🏻💻
- AWS に詳しくないと働けないわけではない
- プロジェクト管理はカンバン
- Github issue と Backlog で管理している
- 札幌と大阪で遠隔で開発しているがコミュニケーションは密に取っている
- Slackに乃木坂の動画が上がる！！！！（素晴らしい🎉👏👏👏）
- Slack の退勤報告の時間は 19:15くらいだった
- エンジニア募集中
所感🤔
- エンジニアとして楽しく開発ができているそうで、素晴らしい🎉
- 乃木坂好きのエンジニアがいるというだけで、うらやましい👏
- クラスメソッド社に転職する前の会社の年収にはちょっと引いた😅本当に年収アップしてよかったと思う。
- 優秀なエンジニアが多い環境で働けるのはいいのと、技術好きな人が多いというはエンジニアとしては働きやそう
