REACT導入失敗談

新技術導入

に失敗してレガシーコードだけが残った

REACT導入前ViewModel

がひとつのファイルの中で入り乱れる

↓

↓

巨大なfunction

複数の関数から操作される一つのDOM

もうメンテナンスできない

次期ユーザインタフェース

View操作のプロトコルをReactで固定するViewのルールが整理できた

FLUX

DOMイベントのハンドリングとデータ更新のプロトコルをFluxで固定するModelのルールが整理できた

Viewの秩序 → React

Model(というかViewからのコード分離) → Flux

いけそうな気がした

導入

学習過程 - 1開発ツール＆エコシステムの理解

webpack: JSのリンカgulp: タスクランナーbabel: トランスパイラjest or karma: テストランナー

もうこれだけで正直おなかいっぱいでした

学習過程 - 2基本パターンの理解

Reactのお約束を理解するFluxのコードを読んでAPIを覚える

＋

ボイラープレートは切り取って部品にする

いざ実装......

最初のプロトタイプをいちおう作りきった

機能拡張とメンテナンス穴が増えていく

デザイン上の瑕疵エコシステム周りの整備ミス

パッケージデザインのミスFluxで機能の役割を整理

→ 役割からはずれた機能を発見

→ 配置するパッケージがわからない

→ とりあえずほとんどutils的なところに

アンチパターン...

コンポーネントの依存関係のミス1. データAをHTMLとして描画したい2. そのためにはデータBが...3. Bを構築するには...

いきあたりばったりwork around...

ユニットテスト開発者自身が不安だと思うところをテストする

誰がどうみても複雑な関数

これはまずまず奏功した変更時にデグレが見つかるとか

依存ライブラリと心中 - 1ローカルではビルド成功

Jenkinsで実行

依存関係の解決でハング

依存ライブラリと心中 - 2依存ライブラリのバージョンを固定していない

新たにチェックアウトしてビルドする

→ やっぱり壊れる

バージョン間のAPI非互換がすごい

clean buildするたびにどんどん死んでいく

くそ、う、動いていたバージョンってどれだ……

(まとめ)デザイン上の問題パッケージデザインのミスコンポーネントの依存関係のミスどんどん不明瞭になるデータの関係

→ 自分で決定するべきアーキテクチャデザインは事前におさえる

(まとめ)エコシステム上の問題依存ライブラリと心中

ビルドできなくなる という進化を遂げた

→ エコシステムの不安定さを知っておくべきだった

教訓技術的な適合だけではだめ

メンテナンスエコシステムの使い方

使って解る辛さを把握しておくプロダクト特有の癖と付き合うデザイン

大事なことビジネスサイドのニーズの変化

それに伴って新しい技術を導入するのは良いこと

でも

少しずつ使い始めて少し運用する時間を持つこと

小さいプロトタイプを作る社内利用でドッグフーディングするこうした活動に理解のある上司・先輩・同志の支援を受ける

これから考えたいこと商用サービスに導入するための考慮アンテナをはるということ準備のためににいつ学習の時間を作るか

今はReactの思想の源流っぽいElmを触ってる

以上

Links

React

Flux