十年資深 Flutter 工程師的啟發 — AI 世代該如何因應和準備？

大家好，我是 Jerry，從事軟體開發已超過 10 年，目前在 Cake 擔任資深 Flutter 工程師。曾開發 2 個受歡迎的開源專案：一個是基於 Index 的 Flutter List Scroll函式庫；另一個是 Swift 自然語言的時間解析函式庫。過去我有將近 5 年的前後端開發經驗，包含開源的 ZK Framework 與 Web 試算表。職涯後半段專注於 Flutter， 從零打造即時多人協同合作的專案管理系統 Quire Mobile App，有著良好效能與細膩的使用體驗。

如果總結自己這些年的經歷與願景，我想應該是讓產品不受技術的限制，幫助使用者完成他們的目標。接下來，我將透過這篇文章分享多年工程經驗的啟發，依序會提出 3 個有效的工程思維並在最後說明它們在 AI 世代為什麼重要。

在了解什麼是 Flutter 工程師、更深入的工程思維之前，不妨先認識 Flutter 是什麼？

Flutter 是用來編寫跨平台應用程式的 SDK（軟體開發工具包），使用 Flutter 能讓單一程式庫在多個平台上運行，舉例來說透過 Flutter 能在不另外建立單獨應用程式的前提下，讓程式碼在網頁版和手機版運作。也因為跨平台開發框架，讓團隊可以短時間建立高品質的數位產品，所以 Flutter 深受專業人士跟業界的喜愛，根據 2023 年 Stack Overflow 調查指出，Flutter 是最受歡迎的跨平台技術。

那麼 Flutter 工程師主要的日常工作內容有哪些呢？

顧名思義，Flutter 工程師是精通 Flutter 框架並以此開發行動裝置、網頁、桌面應用程式的軟體工程師，因此 Flutter 工程師可以是網頁或行動裝置開發人員。除此之外，使用 Flutter 框架設計頁面時也與 UI 設計相關，所以身為專業的 Flutter 工程師，也需要能有效評估及優化電腦或行動版的互動介面，並和團隊一同設計出合適的相關功能和體驗。

Flutter 工程師的角色在軟體開發產業中相當重要，和一般 App 工程師一樣，Flutter 工程師的職責、任務可能會根據不同公司產品、專案要求而有所不同，不過最常見的任務通常會包括：

• 開發和維護應用程式
• 開發和實作 UI 元件
• 整合第三方資料庫和 API
• 確保應用程式的效能、品質和反應能力
• 與跨領域團隊合作，包括設計師、產品經理和其他開發人員
• 參與從設計到開發和維護的過程
• 開發跨平台框架
• 使用 Flutter DevTools、單元測試和整合測試等工具來偵錯和測試 Flutter 程式碼
• 使用 Git、SVN 或 Mercurial 等版本控制工具來管理其程式庫

不只基本的 Flutter 技術能力，在現今 AI 世代，建立有效且精準的工程思維也是 Flutter 工程師和 App 工程師相當重要的能力之一，以下將分享 3 大重要的 Flutter 工程思維。

了解系統底層的運作原理，可以在我們遇見每個表象結果時，試著推理出由上而下、各層之間資訊傳遞的邏輯。

舉例來說，同樣遇見 100 種情況以及最後的結果，不熟底層運作的人，看到情況 A，而得到 A’ 的結果，經驗累積上僅止於此；了解底層運作原理的人，就可以試著推斷 A 應該會有中間層資料結果 A1，最終轉換為 A’。在這麼一次的經驗中，了解中間傳遞什麼的人，不只了解到 A’，也順便得知 A 與 A1 的關係，以及 A1 與 A’ 的關係。久而久之，同樣的 100 種情境問題，後者得到的知識驗證絕對是更多的。

追循底層運作的原理，雖然短時間內會讓人覺得花了很多時間，但久而久之，它的優勢是之後才會體現的。因為愈是資深，愈有機會被指派處理更複雜的問題，這時候各技術層級之間的知識就能幫助我們快速定位各層需求並專心疏理，對於大腦的負擔也會降低許多。

以我自身的經驗而言，在我剛步入 iOS 領域時，對套件管理系統 Cocoapods 的印象本來就不盡正確，接著又把它的錯誤訊息貼上網搜尋，再將任何建議方法複製貼上試看看，直到修好為止。後來某天我下定決心想搞懂它，所以開始了解 Xcode Workspace，並認識到這個系統是透過定義檔，產生平行的專案目錄集合第三方的套件，最後將它與自己開發的專案目錄連結起來。整合我先前的經驗，自從搞懂這些底層的作法後，一旦再次看見錯誤訊號，其實都能猜出可能的環節。

再舉例另一個例子：我在上一份工作時，為了將 Timeline View 上不同的任務標題 Sticky，就用了各種方法在 Flutter Widget 上疊加程式邏輯，試著在任務移出 viewport 的狀態時停留在畫面邊緣，儘管最後的效果看起來不錯，但仔細測試卻發現這些任務的固定效果會慢半拍，直到最後才嘗試出用 RenderSliver 的客製來完美的固定。探究其原因是 Widget 的 setState 會在下一個 frame 才做動，所以 setState 後，程式參考的數據其實都是上一個 frame 產生的內容。

當我學習到更多底層知識後，更能舉一反三。比方說 Cocoapods 出錯時試著猜出可能的狀況，直接破題追出錯誤的邏輯；當 List View 滑起來不順時，我也能知道滑動的原理，並快速得出一些假想結論並驗證，這常常比起看效能分析器並產生一堆數據（Call Stack Tree）快得多。

上一節內容聊的是深度，這一節則是談廣度。不論是 Flutter 工程師或是 App 工程師，系統性思維都是資深人員與初階人員差別很大的部份，他們在經歷過很多工程開發後，透過相當程度的理解並汲取成為自己的知識圖譜。

由上述的方法得到的知識圖譜，可以在處理事情時，以宏觀的角度審視與計畫工作上的種種難題。這也是為什麼我們常常會發現資深人員總會在會議中提出一些關鍵問題。在我的經驗中，一些更資深且更厲害的大神同事，在這方面的表現上，會讓人有種「他是不是無所不知」、「連問題都還沒有提問完，他就已經有全盤的見解與答案了」，這樣驚人的感受。

舉例來說，在 Cake 的 Meet 滑卡實作上，為了給使用者更好的體驗，我們需要預載一些卡片，但數量一次太多初始又太慢。比較好的設計是當發現剩下最後幾張後，會自動再去拿一次。但是向 Server 拿新的預載卡片和使用者滑卡是平行作動的，這樣的模式是生產者與消費者的關係，整個流程因為加入了時間要素而變得複雜，會產生很多的規格定義：

1. 同樣的過濾條件下，同時間只會有一個向 Server 拿新卡的請求。
2. 篩選條件切換後，先前因時間差的關係，晚一點才回來的 Server 請求都不能再使用。
3. 如果網路太慢，預載的卡都被使用者滑掉了該怎麼處理。
4. 滑完一張卡後，通知 Server 的請求發生網路錯誤，必須要恢復這張卡。為了保持新鮮的記憶，要把卡放在愈前面愈好（如果使用者正在滑動下一張卡，我們不能直接置換它而影響體驗）。
5. 其實還有眾多其它考慮細節，我們先略過不看。

因為細節太多，所以很容易超過大腦能保留的範圍，常常是看了後面的邏輯，前面的就忘東忘西，久而久之就會寫出一堆邏輯繞來繞去、交叉相連的程式。我們可以透過系統思維來拆分子系統，更偏向 UI 的預載卡堆子系統以及更偏向 Server 溝通的拿卡子系統。此時需求馬上就能切分了：

1. 卡片預載子系統：滑卡相關的例外處理、篩選條件的邏輯。
2. 卡片請求子系統：處理 Server 的請求，拉卡時的錯誤重試，分辨新舊的預載卡片請求以避免衝突（篩選條件變更時，要馬上拉新卡，縮短等待時間）等等。
3. 子系統之間是平行的關係，它們都需要一些 UI-Model 的資訊，例如已經滑過的卡。

這個範例的方法能將複雜的內容拆分，將多種不同的條件規格拆分在固定的範圍內並各個擊破，自然能將邏輯疏理的更清楚。

在開始任何實作前，我們都應該要認清實作的目的是什麼，這件事通常與專案經理和設計師更有關係，但設計與規格難免有些遺漏，這時工程師的實作就是最終的驗證程序。以程式比喻，工程開始之前的所有規劃就像是定義介面，工程開始就是實作，因此我們常常會在開發期間回去調整介面，加入更多遺漏的規格，而我們的角色天生就具備檢驗的能力。

舉例來說，我們看見按鈕的形狀似乎定義不完，每一個按鈕都有一些不同之處，此時就可以與設計師討論：

1. 這些是他預期的內容嗎？ 如果可以的話，有機會更精簡嗎？
2. 某些按鈕的樣可能只出現過一、二次，那些樣式是必要的嗎，有機會與其它功能按鈕共用嗎？

如果上述的內容有因為再次思考而刪除，或是以共用的方式解決，那麼產品的整體規格就會更精鍊，整個團隊都能省下時間去完成其它有義意的功能。久而久之，歷鍊自然多出別人一大截。

GenAI（Generative AI）的橫空出世震撼了身邊很多人。因為它能完成的任務難度與正確性持續且快速的提升，短短一年增長的幅度，體感上甚至超越過去十年間各種創新框架帶給業界的改變。

我們能試著了解 GenAI 的原理，例如科學家是怎麼設計與訓練的，Attention 機制與大模型為什麼可以產生這麼精準的推論效果等等。我們怎麼利用這些基礎與大量的使用範例，來內化並提升操作 GenAI 的思維，這件事和一直以來追尋怎麼當一位優秀的 Flutter 工程師、App 工程師相差無幾。

未來在工程師心中至高無上的系統架構力有機會降低，因為這些架構是給人看的，幫助人類能夠將龐大的資訊分層分類，來抵抗大腦記憶空間的極限與推論能量的極限。當 AI 愈接近百分之百接管一個子系統時，它能夠自己修復問題，人類就不再需要看內部的狀況。只需要一些指令來清楚描述問題並一同找出解決方法，這其實就像 Tony Stark 在自家實驗室內創造鋼鐵人一般。

總結一下工程師在 AI 世代可以試著強化的能力：

1. 底層知識：透過 GenAI 處理問題時，了解底層的運作能讓問題更明確被定義，GenAI 得知愈多資訊，愈能有效利用它的超強推論能力。
2. 系統思維：拆分系統來降低複雜度，利用 GenAI 來完成簡單或變化性少的部份。
3. 規格的精鍊：先有問題、再有解法、後有規格、高效實作，每一步都可以透過 AI 提升效率。但 AI 再強，最後還是回到我們該怎麼做，為什麼。

那麼 Flutter 工程師和 App 工程師在 AI 世代的優勢會是什麼呢？

1. GenAI 的應用範圍實在太廣，開發者會更專注在以 AI 來提高解決問題的效率與方法。能快速進入市場的跨平台開發需求只會愈來愈多。在不同端點上，如 Web、Desktop Native、App 的程式碼共用能對產品功能的推進有很大的幫助。
2. 當使用者被琳瑯滿目的 AI 解決方案所吸引時，App 美感與體驗的要求會因為前者的質量太大了而造成地位下降。當然這並不表示它不重要了，而是對使用者來說，平台專屬的設計語彙或功能在產品上將不會有太多的差異。想像 5 年後之於現在，與現在之於 5 年前，我們是不是對 iOS 與 Android 的體驗沒有這麼清楚的界限了。

最後還是不得不提，就算 AI 再怎麼熱門，直到 AI 能百分之百接手整個系統前，都不應該去擔心會不會被 AI 取代這樣的話題，因為一個系統不可能只有初始期使用 AI 產生第一版而已，後續人類維護那些全由 AI 生產拼湊出來的程式真的好理解嗎 ? 反而，我們要趕快去享受目前 AI 能為 Flutter 工程師和 App 工程師日常帶來的優勢，那些有趣且令人從沒想過的體驗，才是這個時期最令人開心的事。

Cake Flutter 團隊徵才中，目前共 2 位Flutter工程師。我們有自己研發的 Framework，改善市面上熱門項目的痛點，將生產力更加提升，經過一年開發回饋的調整與驗證後，將於近期以開源方式貢獻社群，大家將會愛上它的易用性與高生產力。

團隊主要是開發 Cake App，現在已知有相當多有趣與具創意的需求等著我們，你能體會到以 Framework 思維來進行高技術力與高生產力的開發經驗。