【專訪】AMPOS：顛覆傳統人才管理的 Flutter App
Help People Do Better
近幾年對於 Flutter 的討論越來越火熱，許多的知名大企業都開始把部分 APP 改成使用 Flutter 來開發，更多的新創公司也決定使用 Flutter 來做為開發主力產品的框架。你會不會也好奇，是什麼原因讓大家對 Flutter 趨之若鶩，並且在 APP 開發圈掀起這麼大的熱潮呢？如果現在想從零打造自己的 APP ，用 Flutter 適不適合？這次 Flutter Taipei 的『App 蒐集企劃』有機會專訪到台灣的易智能股份有限公司。帶你一窺易智能如何將 Flutter 應用在他們的商業產品中，及使用 Flutter 後為產品及團隊帶來怎麼樣的效益。
每個 Idea 的誕生都是希望能夠解決當今的痛點，而人力資源管理一直是每家公司都會遇到的難題。有時候主管難以追蹤員工績效、員工的表現很難量化、或是新人經常被忽略等等的事情，都讓公司吃足苦頭。
為了解決這個千古難題，易智能決定用顛覆式的思維，利用「模組化」的方式重新設計一套完整的人力資源管理系統，並且結合當今主流的平台：Android、iOS、Web，讓管理人才不再困難，這套系統就叫做 AMPOS 。接下來讓我們來深入了解 AMPOS 的工程團隊以及他們使用 Flutter 後的心得跟建議吧！
AMPOS
AMPOS 是一款以將人力發展模組化的人力資源解決方案，以整合性的人才管理為出發點，建構一套能夠即時反應員工狀態，讓同儕與主管在第一時間給予激勵與協助的整合方案，以提升人才管理的即時性與有效性。
易智能以「Help People Do Better」的理念，提供模組化的人力資源發展解決方案。企業可以根據其人才發展上的重點，從入職、培訓、激勵、績效甚至是企業文化實踐等階段，透過 AMPOS 進行更深度的人才溝通及發展管理，企業也能透過 APP 進行互動及宣傳文化精神，凝聚內部員工共識以因應外在環境的快速變化與突發挑戰。
目前提供的模組已經非常完整，提供的模組如下：
- 學習
- 問卷
- 獎勵
- 公告
- 工作任務
- 一對一指導
- 回饋管理
- 個人反饋
- 目標追蹤
- 發送星星
- 持續擴充模組中…
AMPOS 在首頁中提供了一目了然的管理頁面，並且將所有功能及簡易資訊集中在各個小模塊中，方便快速看到重要資訊，並一步抵達想去的頁面：
獎勵模組
舉例來說，在獎勵模組中，你可以看到其他同事給你的星星（獎勵），並且看到你目前星星數量的排行榜，以及管理自己送出的獎勵。透過獲得一定數量的星星，可以去兌換獎勵員工的商品，來達到激勵員工的目的。並且在追逐更多星星的過程中形成內部的良性競爭，提升公司的正能量，讓大家更有動力去努力工作。
AMPOS 技術一窺究竟
你可能好奇 AMPOS 團隊如何評估而選擇了 Flutter 來作為主要開發技術，他們在使用 Flutter 時，什麼事情最讓他們頭痛… 讓我們往下窺探 AMPOS 的技術團隊吧！
Q1.為什麼決定採用 Flutter 技術來開發呢？大約花多久的時間評估決定使用的技術？
AMPOS App 早期是分別在 iOS 和 Android 平台上開發的。當我們新增功能時， 我們需要熟悉 iOS 和 Android 工程師同時開發， 即耗時又耗力。為了提高產品新功能開發速度，產品團隊決定評估 PWA、React Native 和 Flutter 跨平台技術。經過兩個月評估和測試，我們最總決定使用 Flutter，因為 PWA 在現階段不能完全滿足產品需求，而 Flutter 相比較 React Native 更適合我們的團隊，無論是從技術轉換難度還是後續開發資源支持都符合我們需求。
Q2.可以跟我們分享團隊 1 年半大家一起研究 Flutter 的過程和方式嗎 :) ?
日常 Code Review 我們會彼此分享一些語法、技巧、風格、模式、函式庫…等等。由於我們的開發團隊分散在台北和曼谷， 我們也經常在 Slack 上討論一些問題的解法、最佳實作、導入新工具之類的。另外每週例會除了更新彼此的進度，也會討論一些比較工程、架構、流程或框架本身的問題。
Q3.有多少人一起投入開發？大家是什麼樣的背景？
前後大約 12 人左右，熟悉 Android 的較多。除了個別工程師在加入團隊之前就接觸過 Flutter外，其它所有人都是決定採用 Flutter 之後才現學現賣的。因為做 Add-to-App 的關係，所有人都要試著一起開發 Android、iOS、Flutter，偶爾也有人臨時被抓去做 Web、Backend，總之大家學習跟適應的能力都蠻強的。
Q4. 團隊總共花了多少時間時間開發？
Flutter 部分從早期 POC（概念性驗證） 到現在幾乎完成，整個原生到 Flutter 的轉移大概一年半左右，原生的部分之前已經做了三年。
Q5. 團隊的 Flutter App 使用的後端是第三方服務還是自架後端？有用到哪些第三方服務？
我們主要是以 Spring Boot（in Kotlin） 為框架，搭配 Python & Node.js 的 micro service，架在我們後端大神鬼斧神工般的 AWS Infra 上，整合諸多服務如：
- ECS
- EC2
- S3
- RDS
- DynamoDB
- Lambda
- Athena
- Route 53
- API gateway
- CloudWatch
- CodeBuild
- CloudFormation
各種你想得到想不到的服務應有盡有，另外我們也有在考慮提供 AWS 顧問的服務，有興趣的話也歡迎洽詢。另外 APP 端還有用到 MatterMost（aka open source Slack）做 In-app Messaging。
我們的 VCS & CI/CD 使用的是：
- Bitbucket
- Fastlane
- Jenkins
當然也有用其他大家熟悉的服務，如：
- Firebase Analytics
- Crashlytics
- App Distribution
- FCM (中國用百度雲推送)
Q6. 團隊之前有使用非 Flutter 的技術開發 App 的經驗嗎？使用 Flutter 後，在團隊協作或產出方面，有沒有特別想分享的經驗呢？
如前所述，我們有一組開發三年的原生 App，透過 Add-to-App，花費一年半左右一頁一頁逐步轉換成 Flutter。
在我們過去的兩套原生 code base 中，偶而會看到明明應該是相同的商業邏輯，但因為開發者各自的理解或習慣不同，在 Android、iOS 上出現很不一樣的實作方式，進而造成在和 Backend、QA、PM 討論時的一些困難或誤解例如：「為什麼同一個需求 iOS 改很快，Android 卻可能要動到整個架構？」這類的問題在 Flutter 上自然是不會發生，也就是說單一 code base 不只降低了 mobile 團隊的開發成本，同時也降低了對外的溝通成本。
Q7. 在決定使用 Flutter 技術時有什麼擔憂嗎？
擔憂一定是有的， 畢竟 Flutter 是一個新的技術。雖然看到網路上有些針對 Flutter 的討論和開發案例，但我們自己團隊畢竟沒有 Flutter 開發經驗，我們可以想像開發過程中一定會遇到的各種問題。針對於這些問題我們能否找到資源來協助我們解決問題是我們當時最大的擔憂。
Q8. 如何評估適合的架構模式，並取得共識並決定採用呢？
以架構來說，因為大部份的團隊成員都蠻熟悉 Clean Architecture，而且 Clean 本來就是以平台、框架無關為核心精神之一，因此就直接沿用了。 Presentation layer 則是早期大家各自嘗試，試過許多架構：如：
- scoped_model
- redux
- BLOC
- MVVM
大家 Code Review 互相參考一陣子之後慢慢還是收斂到 MVVM。簡單來說 scope_model 太簡單，redux 太複雜，BLOC 和 MVVM 太像感覺也沒什麼好糾結的，最後似乎還是熟悉的 MVVM 最對味。但也沒有硬性規定，如果你覺得在這個場景更適合用其他模式，甚至值得犧牲一點一致性，只要你能說服足夠多的 Reviewer ，也是會得到許可的。
Q9. 承上題，團隊在 Flutter App 使用的架構模式，以你們的實際經驗來說，有什麼樣的優缺點嗎？
Clean 的一大重點在 DI。但我們剛開始做 Flutter 架構的時候，並沒有像 Dagger 那麼強大的 DI Framework，因此我們先用了簡單的套件叫做：simple_flutter_dependency_injection。如名稱所述，它幫你做的事情真的不多，但我們又想要有像 Dagger 那樣切割乾淨的 DI component、module，導致我們寫一個新的 service、interactor 都需要經過相當繁瑣的 boilerplate。
但大費周章的 DI 對我們在做單元測試 mocking 和後續的重構上的確是有很大的幫助，因為我們的目標是從 Add-to-app 轉移到純 Flutter，寫一個 service 的時候就必須考量這點做一個抽象層，再透過 DI 將不同版本的實作提供給其他模組。
例如：一開始我們的 authentication 寫在原生端，要從 Flutter 頁面登入、登出就必須透過 platform channel 去呼叫原生函式。我們會做一個 「AuthenticationService」 的介面，注入到 Interactor 給 Flutter 頁面使用，接著就會有 「AuthenticationServiceImpl」 的實作（by platform channel），透過 DI 提供出來。未來當我們要把這部份轉成 Flutter，只要改寫 Impl 就好。
Q10.用 Flutter 開發的時候，什麼樣的事情讓你們覺得最有挑戰性/最困難？
因為早期 Add-to-App 還在 alpha channel的階段，比較容易遇到一些框架本身的bug，這時候 Flutter 團隊並不會去做 hotfix，就必須自己找 work around。但做 Add-to-App 的人又沒有純 Flutter App 那麼多，偶爾會遇到 Github issue 和 Stack overflow 都查不到解法的問題，最後可能就必須自己看 source code。
另外同樣是 Add-to-App，因為頁面會有 原生 & Flutter 交錯的情況，需要去管理不同頁面使用的 Flutter Engine，同時為了解決 Engine 初始化效能的問題，也需要先做 Pre-warm。這部份相關的文件很少，API 又常常改變，也讓我們費了不少功夫。
總之我們最後是有一個 Engine Factory，準備一個 Pre-warm Engine Queue，每次有新 Flutter 頁面就取一個 engine，同時 warm up 一個新的。
Q11.你們的 Flutter App 之中 有什麼特別想介紹的技術嗎？（例如用到藍芽、IOT、動畫、直播、AdobeXD、Rive、 Machine Learning、 translation 等等…）
老實說我們 App 本身做的事情相對單純，就是各個頁面呼叫後端 API 做 CRUD，因此也可以說特別適合 Flutter。
有一個我個人正在評估的測試工具蠻值得一提的：Repeato。雖然標語是Android UI 測試，但它指的是在 Android 裝置上，而不只是應用在原生 Android App上。因為它是直接對鏡射到桌面上的手機畫面做電腦視覺處理，以此來錄製測試範例和操作 App，理論上適用以下情境：
- 原生
- Flutter
- hybrid
- embedded webview
- React Native
- PWA
都有可能透過這樣的技術來做 UI 測試，而且完全不須要寫測試 code，任何 QA 甚至 PM 都能輕鬆上手。
我目前是只有拿我們的 hybrid Flutter App 來測試，效果還挺不錯的，作者也很快地在後續版本採納了我的幾個小建議，所以我蠻看好它的後續發展的。
另一方面官方的 Flutter Driver 是沒辦法做 Hybrid App Testing 的，你可以想像若是用 Espresso、Flutter Driver 這類直接操作 UI 元素的測試工具，要整合測試 Flutter & Native 頁面交錯的流程有多困難。
另外 appium-flutter-driver 的發展也很值得追蹤，同樣支援各種形式的Hybrid App，如 WebView-in-Flutter、Flutter-in-Native、Native-in-Flutter，雖然現在還在極為初期的階段，未來若是成熟，就可以佈署 Hybrid App 到各大支援 Appium 的 Device Farm： 如 AWS Device Farm 等。
說到 AWS Device Farm 讓我再講一個 Sylph，這是一個 cli tool 讓你可以把 Flutter Driver 當作是 Appium 送到 ADF 上跑，所以純 Flutter App 應該用這個就可以了。可惜它實際跑的還是 Flutter Driver，所以我們的 Hybrid App 還是沒辦法用。
Q12. 你們的 APP 的使用對象看起來有分佈在不同的國家：中國、曼谷和台灣，可以跟我們分享 App 中 internationalizee（國際化） 或是 Localization（本地化） 的處理部分嗎 :) ?
目前的流程是有一個 Google Spreadsheet 存放所有字串，欄位類似
key：en、zh-TW、zh-CN、thai 這樣。每次有新字串加入會先放上 key 和 en，通知翻譯人員補上其他翻譯。然後有一個 Google App Script 把 sheet 裡面的字串分別轉換成 Android、iOS、Flutter 適用的資源結構和格式（ Flutter 這邊是每個語言與對應的每個模組都有一個 json 檔）儲存到個人的雲端硬碟後，再手動下載並整包丟進各專案裡面來更新字串。
這段其實蠻麻煩的，因為要 spreadsheet、drive、Android/iOS/Flutter 到處跑。理論上可以先打 spreadsheet API 資料全部抓回來，本地處理完直接存到對應的專案就好，可惜我一直沒有時間做。
Flutter 端讀取這些資源的方式就蠻土砲的，簡單來說就是：
- App 初始化時根據 locale 讀 json 檔（key-value pair） 進來，存在一個 「AppLocalization class 」裡
- 用 DI 把這個 class 注入到 ViewModel 裡，在 ViewModel 裡根據 key 取得 localized string，提供給 View 使用。
我們沒有用任何第三方套件，連 Flutter Framework 的 「LocalizationsDelegate」 和「Localizations」 都沒用到，畢竟我們沒有根據不同 「BuildContext」 使用不同 Localization 的需求，自然也就不須要到處使用 「Localizations.of()」，給程式多添加不必要的框架相依性。
Q13. 你們有使用任何 CI/CD 工具嗎？有的話是否可以跟我們分享使用的工具，以及為什麼選擇該工具
之前是 Jenkins, Fabric Beta, Fastlane，但這些在之前使用原生的時代就全部建好了，所以我也沒辦法提供太多資訊。至於現在 Fabric 已經轉移到 Firebase App Distribution，Jenkins 也正在轉移到 AWS CodeBuild，主要是希望 Backend、 Web、Mobile 用同一套 CI/CD 工具。
Q14. 如果可以重新選擇開發技術，你們還是會選擇用 Flutter 來開發嗎？
絕對會。現在偶爾還是要回原生 Android、iOS 專案寫些東西，寫到 Android UI 就覺得：「天啊我們以前真的要搞這麼多 Activity, Fragment, View, XML 哦？」到 iOS 專案修 bug 就想說：「天啊每次一編譯就是 5~10 分鐘，難道 iOS 開發者都是得道高僧嗎？」
Flutter 的 Widget Composition 和 Hot Reload 真的是體驗過就回不去了，即使只開發單平台也很有價值，更不用說現在就能很好的跨雙平台，Web、Desktop 也正如火如荼的開發中。雖然早期因為框架成熟度和 Add-to-App 的關係多付出了一些時間成本，但長遠來看 Flutter 依然是非常好的一項投資。
Q15. 你們會推薦什麼樣的 APP 使用 Flutter？如果團隊決定使用 Flutter 來開發，你們有什麼樣的建議想給大家嗎？
針對這個問題，我們換個方式回答可能比較清楚。 我們總結了一些 Flutter 還不適合的情況：
- 大量用到原生 API、套件或硬體的應用（Map/Camera/Bluetooth/AR/VR…）
- 遊戲 （也不是不能做但顯然有比Flutter更好的選擇）
- 設計師希望所有 UI 元件都分別使用原生設計的 APP （Cupertino 的支援度還有一段路要走）
- 非主流裝置 （Watch/TV…）
除了上述情況，Flutter 發展到這個階段，我們認為 80% 的 APP 都會適合用Flutter開發，只要確認過核心功能在 Flutter 上支援足夠，就算可能有其它細項無法直接透過 Flutter 實現，還是可以回去寫原生來串接，多寫 5% platform code 總比 100% 都分別寫來得好。
另一個考量的點可以放在你有什麼樣的團隊，或你個人有什麼樣的技能。例如你們本來就有 Web 產品/團隊，想跨足 Mobile，那麼根據產品需求，走 PWA 可能也是一個不錯的選擇。如果是像我們一樣從原生 Android/iOS 轉跨平台，選擇 Flutter 就會比 PWA 理想的多。
如果最終選擇了 Flutter，我們會建議在興奮地開始玩新玩具的同時，也多點耐心把防護措施做好。例如：模組化、IOC、Unit Test、SOLID、DDD、TDD，甚至是最基本的 clean code，這些不管走到哪個平台/框架，該做的事情還是要做。
畢竟軟體開發最大的挑戰之一就是因應變化，這點在 Flutter 這個既年輕又極為活躍的生態系中更加顯著，API 會變，典範/模式會變，套件/服務會變，當然產品本身的需求更會變。良好的軟體工程、架構和程式碼品質能幫助你快速且安全地因應這些變化，這樣你才能放心大膽地去嘗試 Flutter 各種新玩法，同時不會爆一堆 Bug 把你們家 PM 氣死。
當然以上是針對有實際產品要發佈的開發團隊，如果是個人開發者就別想那麼多了，先上車再說吧！
團隊 & 產品資訊
想認識更多有關 AMPOS 和易智能股份有限公司，以下傳送門請大家享用！
文章都看了，手拍了嗎？
還沒拍呀？！拍手鼓勵支持，小編們才用動力繼續寫下去哦！此計畫也才得以繼續哦！以上文章感謝易智能股份有限公司熱情參與 Flutter Taipei「App 蒐集企劃」，也謝謝你讀完這篇文章！希望這篇文章和此企劃讓你更了解 Flutter 在商業化產品上的應用與導入。歡迎隨時加入 Flutter Taipei 臉書社團 與大家一起互動，告訴我們更多你的想法！如果你也有興趣參與「App 蒐集企劃」聊聊你們團隊/獨立開發者如何開發 Flutter App，想跟大家分享用到了怎麼樣的相關技術，歡迎直接填寫表單，我們將會與你聯絡！
歡迎閱讀「台灣 Flutter App 蒐集企劃」以了解完整計畫資訊哦！
By Michael Lee
