hiroktsのブログ

IT開発系の勉強会の感想とか雑記とか

『FRONTEND CONFERENCE 2016』に行ってきました

2016年3月5日にあった表題のイベントに参加しました。
特に良かったと感じているのは、以下の内容です。

大型フロントエンド開発におけるTypeScriptとDDD

奥野賢太郎さん Chatwork株式会社

speakerdeck.com

累計メッセージ数 10億

以前のWeb版Chatwork

TypeScript導入の経緯

『型がないとしんどい. 』

チームが拡大

1人 -> 8人 拡大することによる特有の問題が発生

  • コメント、コーディング規約
  • デザイナーとの連携
  • テスト
  • ビルド、タスクランナー

コメントは意図を残す

「なぜそう書かざるを得なかったのか？」

ドキュメント、コーディング規約

外注さんは背景をご存知でない。だが、JSやHTML5は得意。 暗黙知であったものを共有することが必要。 主要な処理は「エントリポイント」を用意し、新しい人でもコードをたどれるように。
ex. onclickから発火して、どのようにデータを取っていくのか

『入り口、玄関をきれいににしておく』

エントリポイントを用意する考えは参考にしたいです。
dockerfileなどのように。

デザイナーさんとの連携

  • SCSSを採用　変数やmixin

エンジニアがTypescriptでHTMLのテンプレートを管理
テンプレートでUIをロジカルに設計してHTMLを構成する
そこから先がデザイナーの仕事

これをちゃんと分離していることがUIの改善を行う上で重要なんだと思います。

デザイン仕様書の取り扱い

最初はGitHub Wiki -> MarkdownにしてPR必須に

その結果として「リポジトリ内で検索しやすい！」とのこと

単体テスト

  • mocha + power-assert

    モックを扱ったり型違反を意図的に扱ったりする ここだけTypescriptではなくES2015で記述する部分も

  • 不安なロジックはしっかりテスト

    カバレッジ100%は目指さない。 もし実装を変更するたびにテストが赤になっていたらそもそも何か問題がある。
    設計変更で壊れるテストをなくせる

    テスト自体も負債化する

E2Eテスト

PageObjectパターンを導入する

PageObjectは自分もGebで使っていますが、非常にわかりやすくシナリオと実現方法を分離できます。

Karmaテスト

  • 開発初期のテストはmochaとE2Eだけだった
  • イベントハンドリング周りの検証

ちょっと試してみたい。。。

タスクランナー

  • gulpを使用
  • 属人性に気をつける　あっという間に秘伝のタレ化

gulpファイルの差分を見やすくするように管理

検証環境の構築

検証環境へのデプロイもgulpで構築 @kyo_agoさん

  • 実際のAPIレスポンスを用いて開発

build

  • build時間はモチベーションに直結 browserifyをwebpackに替えたら5分の1 tslintはバックグラウンドで回すように scssだけのタスク

TypescriptとDDD

約400のソース

  • Component, Service, Utility, API
  • チームメンバー全員で共有するのが大変

Typescriptの型はチームメンバープロダクト全体の把握を助け、揺るぎない情報となる

大きなシステムほど「膨大な知識」が要求される -> Domain Driven

型の恩恵

  • 一ヶ月後の自分は他人

    コンパイラはJSDocと違って嘘をつかない　　 むしろ@paramに型情報を書かない　　
    短いコメントを付けるくらいなら型名を

  • IDEを使うと、ショートカットやクリックでファイルを辿れる

  • テストの捉え方が本質にせまる -> 振る舞いそのもの
    『実行時Assert』

  • 自信を持ってリファクタリング １、２行の変更であれば型が壊れていなければ安心

DDD

  • 完璧なDDDの実践は難しい 言語的な面もチーム共有の側面も

ユビキタス言語 エンジニア、デザイナー、ビジネスでの共通言語

コンテキスト

coreドメイン

  • User, Message, Taskなどのドメインモデル コレクションごとのClass

Applicationドメイン BindableUser class

『３人』という文字列　{length}人ではなく{UserCounts}

TypeScriptとDDD

Viewフレームワークとの付き合い方

オワコンなんてない フレームワークの「変動に強いアーキテクチャ」の検討

フレームワークロックインへの考え方

いつでも捨てても大丈夫なように抽象化された実装にする

Applicationドメインに表示描画用のロジックを集約

Angular2化を始めている

二槽式アーキテクチャ フロントエンドフロントエンド CSSとかDom

フロントエンド・バックエンド Coreドメイン、Applicationドメイン

ScalaJSに置き換えたい

感想

『型がないとしんどい. 』とはどういうことなんだろう、と思いました。 型がある複雑な言語だと抽象化する必要があるときに複雑なステップになったりする傾向がある、と知り合いに聞いています。
ChatworkのサーバサイドはScalaと聞いているので、その影響が多いんだろうかと思いました。
型で管理するのはいいけど、特定のデザインパターンに縛られることだけは避けたい気がします。
TypeScriptを使ってIDEでの操作しやすくしたり、テストを書きやすくするってのは良さそうだけどAngularはちょっと見たいな気持ち。。。
そうしたViewフレームワークなどのJSのメインストリームの変化に対しては、抽象化している「変動に強いアーキテクチャ」で対応するというのは素晴らしいと思います。 サーバーインフラの文脈でも『Docker、Vagrant、Serverlessアーキテクチャとかに依存しすぎない』、と同じように言われています。 変動に強いエンジニアになりたいです。 不勉強なところはとにかく何とかしたい。。。

奥野さん、FRONTEND CONFERENCE 2016のスタッフの皆さま、ありがとうございました。