给 Android 开发者的 RxJava 详解
(gank.io)
IngramChen
積分 7
值得一讀的好文
不過 RxJava ...
RxJava 是什麼？從一個 architect 的角度來看，這工具不是一個最好的選擇。我舉個例子：
就是 scala 和 java 的差別。scala 的功能相當多，也很先進。相對的 java 就是個老骨頭，沒什麼可以說嘴的。不過架構師在選定技術時，卻不能理所當然的選擇功能強大的 scala，而是要再三考慮後才能做出決定。(要考慮技術學習的門檻，出錯的頻率，人員如果經常流動時… 等等的問題 )
RxJava 的門檻對一般開發者有點太高了。太過於抽象，不夠直覺，需要一段時間的磨練。我不是說開發者學不會，而是專案經常會有人流動，老傢伙對 RxJava 很熟很厲害，但如果換了一批新手來就撞牆了，這樣子專案會走不下去的。
一個最理想的工具大概是擁有 RxJava 的簡潔，和一半的威力，然後直覺好學。不過我現在沒找到就是了，真是可惜，Android 界可能還需要一點時間來醞釀吧。
回到 scala 的例子，現在開發社群已經了解 scala 的強大功能帶來的反效果，新一代語言都是朝折衷的方向前進，像是 Dart, Kotlin, Swift 等等，新語言或多或少都有 scala 的影子，但是強調好用好學，不過度的增加功能，增加開發者負擔 (less is more)。在我看來現階段 RxJava 就是在走 scala 錯誤的道路，所以我也只能欣賞它一半了…
cfchou
積分 3
不喜歡RxJava就算了 幹嘛黑Scala嘛 哭哭
我覺得Scala複雜與否是個相對的觀念, 跟個人經驗, 解決問題種類, 甚至於市場都有關.
Scala本身複不複雜? 在 community 裡面討論的複雜, 應該是設計者們討論一些更進階的語言features. 我相信跟一般developers所說的複雜不太一樣. 舉兩個跟 Java 開發者的個人經驗比較有關係的例子:
functional programming w/ type system: Scala 使 FP 更複雜了嗎? 跟 Haskell 同樣東西作比較, immutable data, algebraic data type, map/filter/fold/monoid/functor/monad, etc. 這些 FP 的 patterns 型別的宣告以及內部實作大同小異. 所以 developers 不習慣的我覺得是 FP & static type system. 就算改用其他 FP languages 障礙還是存在, 小弟認為真正的問題點是如何/為何 Think in FP.
generics w/ type variance: Java 的 List<E> 不是很好嗎 Scala List[+A] 搞這麼複雜幹嘛? 但話說 Java 也有 variance 啊~ 就 wildcard super/extends 用在 collecions 上. 但是我估計一半以上的 Java developers 不寫 bounded wildcard generics. 大部分人覺得 collections 可以用就好了, invariant 也沒差, type erasure/reification/unchecked warning 管他的. Angelika 的 Java Generics FAQs 可能九成的人沒聽過. 而且我們寫了一堆 code, 是芥末日也(還)沒到. Java 有這樣的好工具而把他藏著. 好處是 developers 不需要會用它也可以寫 code. 壞處是也只有少數人用這個feature, 而一個developer 想用也不太敢, 因為做出的東西難保其他人懂. 這樣真的是好現象嗎? Scala 則說有 variance 就要用啊 讓 type system 輔助 api 的設計以及使用. 是的, 很多人不習慣. 但是好東西不學嗎
IngramChen
積分 2
嘛… 我的留言的重點在 architect 導入 高門檻的技術時，會遇到類似的問題。如果一個專案會跑五年以上，要用什麼技術才不會讓技術債太高一直是個困擾的問題啊。看到 RxJava 的高門檻讓我有似曾相識的感覺，就是 scala 的前車之鑑。
唉，scala 被黑不光是用嘴巴說的，是開發者圈用 實作 的方式給了答案。新的語言就是不會走 scala 的方向了，這比什麼嘴炮打臉都還要狠… (如果 scala 模式是成功的，新秀的語言自然會跟隨囉… )
Think in FP 是進階開發者必修之路，但大部份的開發者並不是 (糊口飯的居多)。所以新世代的語言 (尤其是描準大眾市場) 都只挑 FP 裡直覺好吃的功能留了下來，其他都放棄了。
如果是從學習的角度來看，我留言的那些話就是白說的，要學什麼哪有什麼限制？唯一的限制只有時間而已。
rayshih
積分 3
我們使用 scala 開發 android app 已經過了半年，就單純 code 要我回去寫 java 我只會皺眉頭。
說真的其實可以只把 scala 當作語法調整過的 java，一樣可以不走 FP ，全部都使用 OO paradigm。也聽過一些純 FP 擁護者認為 scala 根本不能算 FP 語言，因為 scala 並沒有防止你寫 OO 之類之類。
就以這個觀點來說，scala 跟其他非 java 語言比起來根本沒有有所謂的較高的門檻。
回到 Rx
跟 promise 的 then 一樣，其實要用 Rx 只需要會 flatMap 跟 map 這兩個 function 就可以做到你所有想要做的事情，剩下的都是 helper method 而已。甚至，有些人根本只把 rx 當 event bus 用而已。
我覺得大家認為 Rx 的高門檻其實是建立在：大部份的工程師是從 imperative paradigm 開始學習 programming，所以要過渡到 declarative programming 會有很大的陣痛期，不過就這點來說 ReactJS 的社群接受度倒是很高，所以除去舊有思維的因素，我並不認爲 Rx 是一個高門檻技術。
我反而認為如果一個專案要跑五年以上，導入 Rx 絕對不會錯，FRP 的觀念下，state 被縮現在做小範圍，寫得好的話，所有 function 都可以沒有 side effect，這樣的架構是最好測試最好維護的。
倒是想請問你說「scala 被黑是因為開發者圈用實作的方式給了答案」，是怎麼樣的狀況？
IngramChen
積分 3
好像討論的前題有點不大一樣？你說的我了解，也同意，不過我想你的說法可能比較適用只有兩個人一直開發同個專案二、三年這樣？不然就是要有個很有 sense 的團隊，很穩定地一起工作了一段時間。
我的前題比較類似這樣：
一個十萬行以上的專案，由 2 ~ 4+ 人開發，每年大概會替換 1~2 人，然後開發了 2 年以上。
說真的其實可以只把 scala 當作語法調整過的 java，一樣可以不走 FP ，全部都使用 OO paradigm。也聽過一些純 FP 擁護者認為 scala 根本不能算 FP 語言，因為 scala 並沒有防止你寫 OO 之類之類。
scala 的問題不在 FP 或是 OO，而是兩個都能寫，所以程式碼經過兩、三年；兩、三人經手開發後，就會開始混亂了，什麼寫法都會有。接手的人變成全部的寫法都要會，這不是說你想遵守某些原則就能解決的，因為人員會流動，計畫也會變更，很容易就變成拖彊野馬無法控制。這就是給太多功能的缺點之一。寫法太多又混了兩種 paradigm，門檻還不高嗎？
跟 promise 的 then 一樣，其實要用 Rx 只需要會 flatMap 跟 map 這兩個 function 就可以做到你所有想要做的事情，剩下的都是 helper method 而已。甚至，有些人根本只把 rx 當 event bus 用而已。
RxJava 的 helper method1 太多了，複雜到還要作圖來解說，這圖… 真的沒有比較好懂啊。而且你說的跟我想要的其實是一樣的東西啊。我就是比較希望有一個簡化版的 RxJava，flatMap/map 再加 5,6 個 helper，thread model 再簡化一點，這樣就夠了。寫法統一，維護的人門檻也不會太高。
scala 被黑是因為開發者圈用實作的方式給了答案
scala 在 200x 年的時候記得還蠻紅的 (在 startup 圈)，但經過兩年後就有導入的人自己出來吐嘈，不過那些還可以說是個人的意見。但看看近幾年的新世代語言的風向，沒有人走 scala 的路子 (a scalable language, 一直不斷加強悍的功能)。我說的開發者圈 (設計語言的人) 用實作的方式給了答案，指的是這些設計者實作了新的語言，但他們的成品和 scala 的理念卻是相反的，換句話說就是認為 scala 的強項在他們眼中反而是缺點…
總之，我的想法就是語言和 library 本身提供的功能和概念，要限制在某種難度與自由度下。不然到後期就會失控。我不太相信靠開發者本身自律可以避免這種問題。(這某種程度上還真像法律與道德，道德的自律就是到某種程度以上就無能為力了)