今更だけども。仕事で使ったわけでなく、「仕事で使うに耐えるか」をちゃんと判別したくて 1 ヶ月ちょい前から余暇を使ってちまちまと触っていた。
ちなみに自分の本職はサーバーサイドで、JS は片手間に書いている。
勉強のために作ってみたものはこれ。 → GitHub - Cside/unread-manager: はてブの未読整理をする Web アプリ
良いと感じた点
- Redux に限らず Flux 系フレームワーク全般に言えることなのだろうけど、Flux Way に乗って書くだけでコードが疎結合に組み立てられるため、テスタビリティは鬼のように高くなる。
- 一度慣れてしまえば、イベント依存地獄にかなりなりにくい、メンテナンシビリティの高いコードが書けると感じた
イマイチと感じた点
- 学習コストがそれなりに高く、プログラミングのパラダイムもこれまで経験してきたものと全く異なったので慣れるのにも時間がかかった。
- ちょっとブランク空けるとすぐ忘れたり
- 学習コスト高いと書くと学習コスト警察から「お前エンジニアなんだから勉強しろよ！」と言われそうだけど、実務で導入した場合は学習コストは開発のスケジュールにダイレクトに影響してくるので、ちゃんと考慮に入れるべきだと思う
- ファイルが多すぎて、ファイル間を行ったり来たりするのが面倒
- まぁ React や Redux が、書きやすさより読みやすさに主眼をおいている限り、このくらいは仕方ないのかなと思う
- 今回は１人で開発してたので困らなかったが、デザイナーさんに JSX 触ってもらうのしんどいだろうと思う
- 非同期処理ができない点について
- redux-thunk はシンプルだけど Action が肥大化しがちになるし、redux-saga は個人的には牛刀だと感じたので、redux-thunk の問題を解決した大きすぎない middleware が欲しい（探せばあるのかもだけど）
- 今回は非同期処理は XHR だけだったので redux-promise でも良かったのかもしれない
- ちゃんとパフォーマンスも考えるなら shouldComponentUpdate をメンテするコストが発生する
総じて
React + Redux は
- フルタイム JS Developer がチームに一定数以上いて、
- JSX を学んでくれるデザイナーさんがいる
の 2 点が揃えば、コードのメンテナンシビリティの高まる良いツールだと感じた。
まず 1 点目。
フルタイム JS Developer が一定数以上いるなら React + Redux はアリだと思う。
逆に言えば、チームに片手間 JSer しかいないなら向いてない派。React + Redux を使った開発は jQuery で歴史が止まってる人間にはプログラミングパラダイムが違いすぎて慣れるまでが時間かかるからだ。やっと慣れたとしても、ブランクを空けると感覚をすぐ忘れるだろうし、フロントエンドが本職でないのならブランクが空くのは避けられないだろう。やっと慣れた人が退職したり異動したら、メンテを引き継ぐ人（当然この人も片手間 JSer ）が同じ苦労をするだろう。これらの苦労が開発スケジュールに与える影響はなかなか無視ないレベルのものになるんじゃなかろうか。
2 点目について。
聞くところによるとデザイナーさんは JSX にだいたい 2-3 日で慣れてくれるものらしい。
各 PJ のチームのデザイナーさんが固定になる組織であれば問題ないと思う。
そうではなく、開発案件ごとにアサインされるデザイナーが異なる組織、つまり 1 つのプロダクトを何人ものデザイナーさんが代わる代わるマークアップする組織であれば、新しいデザイナーさんがアサインされるたびに JSX に慣れてもらう必要があるので、それはちょっと厳しいんじゃないかと思った。
デザイナーに学習コストをなるべく強いらず、かつ片手間 JS Developer 達にフィットするツールを個人的に探しているので、次は Vue.js ( Vuex ) でも触ってみようかなと思う。
