近期收至少不少讀者私信諮詢，最普通的困惑是「每天都在 CRUD。沒啥競爭力，該怎麼辦」，我覺得這是一個很普遍的問題，也應該是很多人的困惑，我想講講我的經歷，希望對大家能有所啓發。
目前我雖然做的從事的是 Java 後端，不過其實我一開始做的是 iOS 客戶端，16 年我司在移動端業務發展迅猛，業務都高歌猛進，隨之而來的是 iOS APP 工程的急速膨脹，於是一個大問題就出現了：由於工程龐大，打包時間急遽上升，經常需要一小時以上，更惱人的是打包經常失敗，這樣的話從提測，到提交到 appstore 發佈等流程都受到了嚴重影響，甚至影響到了整體的業務迭代流程。這事還驚動了我們的副總裁，問我們是否是 Mac mini 性能太差所致，是否可以換個高配的機器來解決。
當時我剛加入集團不久，做的也是某業務的負責人，其實做的也是 CRUD 的工作，聽到這個消息，立馬意識到這是個巨大的機會，解決好了不僅能讓集團的業務迭代速度大大提升，更是能成爲第二年的晉升的重要加成，於是就在業餘時間着手調研解決方案，當時我們正在實行 iOS 的組件化方案，簡單地說就是把一個工程拆分一個個以業務，功能劃分的組件，這樣的話組件之間的開發互不影響，能極大地提升業務的迭代速度。
如圖示：組件化示意圖，有點類似於微服務架構中的服務拆分，只不過與微服務不同的是這些組件共同組成了一個 app，這些組件編譯歸檔後會生成 ipa，也就是運行在大家手中的 app。
經過觀察不難發現從工程打包生成 ipa 99% 的耗時就在組件編譯生成靜態庫這一步，所以解決方案很簡單，提前將組件打包成靜態庫不就行了，這樣 app 工程就由一個個組件的靜態庫組成，省去了編譯這一步
當然組件打包生成靜態庫這一步還要有工具來實現，調研了一下發現有現成的第三方庫可用，於是將一整套方案整理成文檔第一時間在 iOS 團隊進行了分享，之後各個組件負責人一起加班加點地把這件事落實了下來。
效果也是很明顯的，整個打包時間從一個多小時降低到了 3 分鐘以內，生產力得到了巨大的提升，後續所有 iOS 打包方案也是用的這套方案，可以說徹底解決了打包的問題，第二年晉升我也將此項寫到了我的述職報告中，並得到了評委的認可，當然能晉升還有其他的一些要素，但打包方案的提出可以說是一個重大加成。
仔細看打包的解決方案，你會發現，其實沒啥技術含量，但我把握住了，而且發現痛點後第一時間調研提出解決方案，也取得了顯著效果。
所以雖然說很多人都在擔心一直在 CRUD，但我們其實能做很多來提升我們的技術，提升我們的影響力，我們可以及時發現痛點並解決它，關鍵是要有心，當時我司 iOS 開發人員有十幾個，結果是我主動調研並第一時間先提出瞭解決方案，我覺得我自己的積極主動有很大的關係。
這件事對我們的啓發是我覺得要要爭取成爲解決方案的提出者，提出者貢獻最大，執行雖然重要，但沒有方案，便無從下手，這就好比沒有建築圖紙，如何施工。
所以我覺得雖然很多人都在 CRUD，但只要我們有心，一樣可以提升自己的技術能力，就比如你做 CRUD，關心過接口性能嗎，是否還有優化的空間（比如提升 20%等），上次我看到安琪拉在阿里做的事就頗多感慨，他把接口性能優化的耗時，從三十幾毫秒下降到五毫秒，類似的接口還有十幾個，都是核心接口，還有SQL性能的優化等等，如下是他優化後的效果：
這樣的話你做的每一個優化日積月累必然會給你帶來出其不意的回報！
另一方面，我學得稍微大點的團隊都會有技術分享，可以多去旁聽下其他團隊的解決方案，痛點以便看下是否能引入自己的團隊中。
最後我想再說的是千萬不要覺得 CRUD 就不能提高技術了，關鍵還在於你是否有心。
歡迎大家掃碼關注「碼海」，加我私人微信「geekoftaste」，拉你進技術交流羣，羣裏有很多 BAT 的大咖，可以提問，互相交流，內推等，2020 的冬天有點冷，歡迎大家進羣一起抱團取暖
