大家好，我是老劉。
老劉的工作經驗還算豐富，光Flutter就做了6年多了，大廠、外企、創業公司都幹過。
今天想和大家聊一個特別有意思的話題——“為什麼有些技術團隊加班到禿頭還做不好項目，而有些團隊卻能喝着咖啡輕鬆上線？”
答案可能就藏在那些看似平常卻影響深遠的“關鍵決策”裏。

一個人一生中往往影響最大的是那寥寥幾次的重要決策，比如：

• 高考考哪個學校，選哪個專業
• 大學畢業去哪個城市，從事什麼工作
• 選擇人生的伴侶

其實在軟件開發的世界裏也是一樣，那些關鍵的決策決定了整個項目的前途，比如：

• 客户端開發，選擇原生開發還是Flutter、RN、Uniapp
• 架構設計
• 開發流程TDD還是瀑布流

今天我們就來扒一扒，客户端開發的世界裏那些“20%的選擇如何決定80%的成敗”。

一、技術選型：選對框架，少打十年工

原生開發 VS 跨平台框架（Flutter/RN/Uniapp）
原生開發就像自己蓋房子：磚瓦水泥自己把控，但工期長、成本高。
跨平台框架更像是精裝房：拎包入住快，但隔音差（性能問題）、裝修風格受限（平台特性兼容）。

技術選型沒有那個好那個壞的標準答案，更多的是根據需求、項目、團隊等情況做出的權衡取捨。
比如團隊已經積累大量原生組件庫，這時候非要選一個跨平台框架可能反而事倍功半。
再比如項目需求是高度的多端一致性，這時候選擇RN這樣的中間層技術就不合時宜了，Flutter可能是更好的選擇。

血淚教訓：
“去年前端團隊為了趕進度，並且本身熟悉js，選了Uniapp，結果遇到不少平台兼容性問題，需要在原生開發環境中定位，全員加班一個月——選型時省下的時間，全在填坑時還回去了。”

下次當你面對技術決策時，不妨先問自己：
這個選擇三年後會不會讓我後悔？
如果出問題了，有沒有Plan B？
團隊的知識儲備hold得住嗎？

二、架構設計：蓋樓先打地基，寫代碼先畫藍圖

這兩年接了不少Flutter方面的外包和諮詢類的項目，發現一個有意思的規律。
好的架構各有各的特色，混亂的架構都有一個共同的原因：項目初期的趕進度。
很多項目做到最後實在推進不下去的原因不是中後期的問題，而是在項目最開始的時候把力氣用錯了地方。
這些項目在剛剛開始的時候為了快速交付試錯，開發流程異常奔放，找幾個人分一下功能就開幹。
不做任何的統一設計和規範，大家各玩各的，一個項目中用了多套不同的UI庫和狀態管理框架的我都見過。
剛開始的時候看起來是比較快，但是隨着功能增加，項目推進的越來越慢。
到後期想加新需求就不得不把原先的代碼推翻重寫。

見過最騷的操作：某個團隊為了趕618大促，在核心支付流程裏寫死參數。結果雙十一流量翻三倍，系統直接崩潰——臨時方案活不過三個月，否則就會變異成祖傳代碼。

其實好的架構設計能夠把問答題變成填空題。
當你面對一個需求的時候，好的架構可以告訴你如何進行功能拆分，甚至生成框架代碼。
開發者只需要在框架對應的部分填充需求具體的內容即可，例如在UI部分填充頁面佈局，在業務邏輯層填充服務端接口調用和數據解析。

所以在項目開始的時候彆着急寫代碼，大家坐下來討論一下架構如何設計，代碼拆分如何規範。
有了一個好的地基，隨着開發人員對項目的熟悉以及公共模塊的補充，開發速度是越來越快的。

反之，技術債是會自己生長的，越底層的問題越會隨着功能的增加而繁殖。

三、開發流程：用對方法論，加班少一半

你團隊的晨會是不是這樣？
開發：“我在改昨天測試提的BUG”
測試：“我在測開發剛改的BUG”
產品：“我在寫新的需求文檔”

是不是覺得很正常，好像沒啥問題？
但在晨會就有些不太合適了，因為晨會是用來對齊目標發現卡點的，而不是彙報工作的。
一個簡單且合理的晨會大概是下面的流程：

而比晨會怎麼開更重要的是你的團隊是否需要晨會。
現在很多團隊看到別人開晨會，自己也開。看到別人搞看板，自己也搞一個。
但其實晨會和看板等等工具都是敏捷開發的實踐，都是為了解決具體問題發明的工具。
我們當然可以把這些工具單獨拿來使用，但是一定要明白這些工具解決能幫我們解決什麼問題。
比如晨會，在敏捷開發中，通常是把需求拆解為用户故事，然後再拆解為粒度更細的case，然後在晨會上核對一下今天需要完成哪些case。
看板也是為了快速輕便的計量用户故事和case的推進情況。
如果你用的不是敏捷流程，那麼看板和晨會是否真的能幫助到你呢？
把一個拆解到兩週的工作內容塞到看板裏面是否是削足適履呢？

前面其實老劉想説的就是要選擇和你們的流程相匹配的管理工具，而不是跟風。
那麼接下來我們聊聊如何選擇合適的開發流程。

熟悉老劉的朋友都知道我個人是比較推薦敏捷開發以及TDD的。
一開始我覺得這套方法論適用於大多數的團隊及場景。
但是這兩年隨着諮詢業務和敏捷教練方面的業務，接觸的公司和團隊多了，我發現未必是這樣的情況。
首先敏捷開發或者更小範圍一些的TDD確實是非常好的方法論，也確實能在大多數團隊的場景中取得非常好的效果。
但是這一切的前提是團隊有能力熬過剛剛開始轉型的動盪。
任何流程的推行，其本質是要求團隊成員特別是管理者清楚的知道每一個步驟的目標是什麼，是要解決什麼問題。
而在流程切換的過程中必然伴隨着一定程度的混亂和問題。
如果你沒有和你的老闆溝通清楚後續的變化，貿然上馬敏捷開發或者TDD，那麼一旦出現問題比如bug增加，很可能會被問責以及停止回退。
最終結果就是你們吃力不討好，搞了一個半成品或者折騰半天回到原點。

但是如果你做好了準備工作，不論是敏捷開發還是TDD，都會給你帶來超出預期的回報。
你的團隊能夠以精準可控的節奏推進項目。
代碼質量會維持在比較高的水平，綜合bug率會大幅度降低。
項目是真的可以每天喝喝咖啡輕鬆上線的。

總結

其實讓一個項目很好的推進下去只需要做好三件事。
“技術選型是方向，架構設計是骨架，開發流程是節奏——這三板斧砍對了，剩下的80%工作量都是水到渠成。”
最後送大家一句話：選擇比努力更重要，但別忘記努力做選擇 。

好了，以上是最近看到一些項目的感想，如果看到這裏的同學對客户端開發或者Flutter開發感興趣，都歡迎聯繫老劉，我們互相學習。
點擊免費領老劉整理的《Flutter開發手冊》，覆蓋90%應用開發場景。
可以作為Flutter學習的知識地圖。
覆蓋90%開發場景的《Flutter開發手冊》