腾讯曾经有句很经典的话——先抗住再优化。
优化和需求相比，永远都是排在第二位的，唯快不破，首先是要业务生存下来，然后才是如何稳定运营业务。
见到一些技术人员，包括刚工作是的自己，恨不得把架构代码打磨得无可挑剔，用当下最流行最“高效”的技术。而且还会说“要有技术追求；不能等到撑不住的时候再优化，那就来不及了……”
到底应该如何优化，什么时候优化，要遵守以下几个原则。
先弄清极限容量，自己能撑多少
先弄清楚现在系统的容量，什么地方是瓶颈，到多少访问量、用户的时候才会有问题。如果说目前用户1万，到100万时有问题，公司要5年后到达这个量级。那么可以停下了，先做其他需求去，在这五年内有好多事可以做。
如果马上就要撑不住了，那么就是最重要的问题了，要着手处理。优化的原则是不影响当下的体验，有时即使发现从前的地方有问题，也要先保证功能不变，完成优化后再进行修改。
有些人会以语言性能不行，换框架、或语言，说新的更优，速度更快。但是你的用户量到达拼最底层速度的时候了吗，是不是中间的逻辑没写好，真正的瓶颈在哪？你弄清楚了吗？
突破业务瓶颈后，都有哪些地方要优化修改
先弄清容量后，要处理预案。万一哪天到达瓶颈，是不是扩充机器，或者用什么其他资源置换的方法，能够撑过去，保证业务稳定前行。然后用计划的优化方法慢慢处理。要先有预案，但不用马上执行，真到来的时候，按部就班就能够应对了。
评估优化的方案，真的有所提升吗
有些人说c比php快，要早换语言，能够让性能提升。这是“政治正确”的，但是有没有想过，真的用户量大了以后，代码的设计架构都要修改了，用c就能解决一切问题？
总之，是否优化要心里有数。在开发设计之处，就要考虑到扩展性，把一些不容易改变的（协议、架构）先确定，有些就是要牺牲和不同时间不一样的。一万用户时的投入量和百万用户时的投入量肯定是不一样的，很多过早优化都没有考虑全面，到后面还是避免不了优化。