软件工程之所以叫软件工程，是因为这不是一个人的事情。哪怕是一个简单的 App，从你上层的业务逻辑到所使用的官方库（UIKit、Android Framework 等），都能组合成一个复杂的软件架构，但如果上层业务简单，那么难度重心就在给上层提供支持的 Framework 里，如果是一个复杂的 App，那么也有可能偏向上层。

但这终究只是偏向的问题，如果你所处的团队或者公司，已经是一个有着相当复杂的业务（哪怕在用户眼里，其实没那么复杂），那么这些想法可能是错的：

• 我们复杂的东西没有难度，不需要做极致的优化
• 因为做的东西没难度，甚至也没有涉及到高深的算法，因此做的事情没有价值

正如前面说的，不同层级的难度其实是不一样的，因为他们的「客户」是不一样的，但基本都是给上层业务服务。但作为软件工程的一个分子，其实有些想要解决的问题，本质都是一样的：

• 如何把性能发挥到极致？内存分配是否合理？
• 如何把耗时降到最小？
• 如何设计好一个 API 集，提供合理的，调用安全的同时扩展性和易用性都很强的 API 能力？
• 如何设计好一个层级架构，使其能跟随着业务 scale？并能很好地跟测试框架等结合，给 DevOps 加速？

在跟一个朋友聊天的时候，他提到一点我觉得很合适，意思基本是：

大多数人不知道软件工程内部的很多东西其实就是 trade-off。

我们始终无法做到 100 分，也无法做到没有任何 bug（这件事情本身就是一个 bug），但每一个层级的开发人员，都有能力去把这个 trade-off 做到尽量地少，这样对个人以及所在团队的成长才有好处。