性能问题？

性能有问题？

如果有，那肯定不是我造成的！

如果没有，闲的蛋疼不！？我们需要考虑它吗！？


提到性能问题，大多数程序员的反应基本上就是如上那样的。

我们现在听到最多关于性能的”真理“就是：不要过早做性能优化。

通常情况下还会伴随着另外一个“真理”：现在硬件已经很快了，足以支撑大量消耗掉的cpu和内存，所以我们更无需担心。


之所以称其为真理，是因为它被很多人信奉。戈培尔说谎言重复一千遍就是真理，用在这里那可是再好不过。


真理自有真理的好处：不容被挑战。但凡一个不谙世事的程序员提出性能优化，必定被教徒们群殴致死；当然运气或者人品够好的话还不至于那么糟。


这条”真理“是否正确，我们姑且先不要去纠结。凡事得实践过才知道。

但是这句话本身就有很多模糊不清的地方：什么是过早？什么才不是过早？

这句话适用于所有层级的程序员吗？


也许很多人不愿意承认，或者是习惯了自欺欺人刻舟求剑，但是在这个行业里面，大部分项目，它们压根就活不到遇到性能问题的那一天。你说花那么多精力在性能上面这嘛不是扯淡嘛，除了带给自己很NB的感觉（也许还有一两个崇拜者），嘿，啥都没有，也就一自娱自乐。


这样看来，性能真理那可真是真理，这也很能解释为啥它能存在这么久。


但是话说回来，如果一个程序员的项目经历里面没有遇到过性能问题，那就很有问题了，别的行业我不清楚，至少在互联网行业是如此。大的互联网公司有个好处就是你有机会遇到这些别人可能一辈子也遇不到的问题，而成功解决这些问题给程序员带来的成长则是不可多得的。也许很多人觉得大公司的技术产品都是很nb，代码都写得很精妙，每个字节的内存都用得恰到其处。事实并非如此，就阿里而言，很多系统的代码也是写的很糟的（不要拍我）。

但是就如同其他公司一样,大部分系统还没到那一步,至少看上去都运行良好，大家都很高兴。问题可以掩盖，但是事实就是事实。在表面的稳定之下，潜伏着很多隐患；而一旦它们爆发，就可能是一个又一个的生产故障了。


当然也不能完全怪罪于程序员，很多时候都是人在江湖身不由己，特别是互联网行业，讲的就是快。需求和业务往往多而杂，程序员疲于奔命于一个由一个的业务需求之中，没有多少时间停下来思考自己的代码内在的东西。性能就更不用说了，它往往是项目最后一个被考虑的问题。


出来混总是要还的。该吃的苦头总是要吃的。随着业务的发展和膨胀，性能问题会越来越严重。当这些问题出现的时候，我们大脑闪过的第一个念头就是加机器。的确，加机器是一种非常有效而简单可行的方法。但是加机器有两个问题：第一，机器是有成本的，公司在这方面的预算不可能无限增加；第二，当机器数达到一定程度的时候，量变引起质变，无论是运维层面还是系统层面都将面目全非。


前不久淘宝某核心业务部门（名字就不说了）开展了性能调优的项目，目标就是在不加机器的前提下提高现有系统的QPS和TPS。经过这一两月的努力，成效非常显著。具体的数字不方便透露，总之是非常impressive。


这个事情可以看出其实现有的系统往往都有很大的优化余地。为啥会这样，说得不好听一点就是代码写的烂。。。设计不合理。。诸如此类。


究竟要怎么做？

多么简单而又复杂的问题。


每个公司都有自己特有的业务场景，这个问题也因此而千人千面。

但是经验上讲有一点很重要：性能意识。


什么是性能意识？就是程序员对性能问题的发自内心的自然认知。这种认知是逐渐培养出来的，最终将变成一种习惯。当你写代码的时候，很自然就意识到哪些是可能有性能问题的，哪些是火坑，哪些是灭火器。比如一个开发分布式系统程序员就应该知道远程过程调用是要尽量避免的。一个拥有性能意识的程序员，不仅写出来的代码不容易出现性能问题，而且通常代码本身也会比没有这种意识的人的代码更加优雅和精炼。

最重要的是，这种自然而然的意识并不会给项目进度造成什么大的影响，不会说为了性能考量而拖慢整体进度和时间。


培养这种意识不是一蹴而就的事情，平时写代码的时候，就得多思考多自测，本着对用户对产品对自己负责态度去写每一行代码。坚持，才能走到最后。


以上内容纯属个人扯淡。

--EOF--