近期收至少不少读者私信咨询，最普通的困惑是「每天都在 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 的冬天有点冷，欢迎大家进群一起抱团取暖