這幾天一路下來，我們從設計師與設計師的角度，討論了 Rive 的優缺點、基本的使用方式與語法、實務建議、以及一些進階的議題。你可能會發現，文章的主題慢慢的從具體到抽象，到後面越來越偏向一些觀點或是概念上的釐清。

我個人是覺得，選擇比努力重要的非常多，所以在學一個東西時，只要努力掌握了基本的語法，那剩下更重要的是選擇，選擇為什麼要用，或者為什麼不要用這個東西。選擇這個東西要用在哪邊？要用到什麼程度？有沒有哪些雷要先避開？方向對了，剩下的就只是細節的問題而已。所以如何評價一個東西，要把這個東西放在哪個位置或體系上，他的定位是什麼？我個人覺得遠比語法或使用方式來的重要，因此以下是我個人對 Rive 的一些評價。

是一個好東西

Rive 至少解決了「還原度」「參數 & 互動」這兩個前端製作動畫的痛點，市面上幾乎沒有其他 solution，所以光是這兩點就很值得用 Rive。而且其他方面 Rive 的表現也不差，官方也有積極在推動，所以各種功能陸續推出，長期下來會是一個值得投資的技術，這點無庸置疑。

只是一個動畫工具

可能因為我是站在前端工程師的角度，但就我個人的觀點來看，Rive 只是一個 2D 向量動畫工具，如此而已，他不能也不應該能涉及到其他領域。這是 Rive 在前端生態系的的定位，雖然官方似乎有想把觸角延伸到遊戲引擎這一塊，但還不是很成熟。

很容易造成過度設計

把以上這兩點加在一起後，實務上很容易遇到的問題是，大家一開始被 Rive 驚艷到，於是什麼東西都想用 Rive 做，同時會提出一些更天馬行空的需求。這其實是兩個問題，一個是把不該給 Rive 做的東西給 Rive 做的問題，另一個是提了一堆根本不該做的東西的問題。

無論是哪一個問題，因為 Rive 還蠻強大的，所以真的要硬幹的話也不是不行，但慾望不會因為被滿足而消失，只會繼續擴大。所以就算暫時用 Rive 硬幹完了，他只會繼續捲土重來，直到無法實現為止。

如果這些額外的設計或需求對產品有所提升，那可能還有點道理，但更多時候會變成一種過度設計，或者至少沒有合理的評估過成本與收益。邊際效益是會遞減的，在網頁第一眼會看到的地方加入動畫，或許可以帶來流量，但有必要在每一個按鈕跟連結都加入動畫嗎？一段簡單但精緻的過場動畫一開始可能只有兩秒鐘，有必要多投入 20 mb 的素材跟三個月的開發時間把他變成五秒鐘的華麗轉場效果嗎？不是說完全不可以，但有評估過能多帶來多少收益嗎？這筆投資划算嗎？還是只是在滿足虛榮心跟強迫症而已？

就跟這張圖一樣，聽說岸本的助手畫了一個禮拜，雖然真的非常精緻，但一般人看漫畫應該不到五秒鐘就翻過去了。如果連這種等級的圖，都無法吸引讀者的注意力超過五秒鐘，那我們用 Rive 的動畫，有必要做到非常精緻華麗嗎？

反過來說，就算沒有這張圖，難道火影的銷量就會往下掉嗎？人家是 Jump 三本柱所以可以這樣內捲，平常我們開發專案，有資源這樣燒嗎？還是把時間省下來多開發幾個專案比較划算？

當然這絕對不是 Rive 獨有的問題，但是很容易在採用 Rive 之後發生，因為他的確很好用來作動畫。就好像剛開始幾天提到的那樣，Rive 的一個優點就是把設計師拉過來跟工程師站在一起一袋米要扛幾樓，這樣整體來說會更節省開發成本，進而對團隊創造更多收益，而不是拿來繼續內捲的。

好吧我知道我一直有扯得很遠的壞習慣，這篇應該是這 30 天扯最遠的一篇。再扯更遠一點的話，我是覺得設計跟程式碼一樣，本身都是手段而不是目的，賺錢才是目的，所以這兩種東西都是夠用就好。code review 的時候，我也不會要求到盡善盡美，我知道那只是在滿足我自己，對專案的效益不高。

”In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn’t perfect.”