开发模式の不可能三角

image.png

质量：功能正确，BUG少
性能：代码运行的速度快
效率：开发效率高，按时或者提前交付

优缺点和必要性

质量

这是必须的，功能正确大于一切，否则就没有意义

效率和性能

要想写出性能好的代码，需要开发人员精心设计，使用巧妙的数据结构、引入中间件等，因为引入了一些复杂的东西，所以容易出错，需要花很多的时间自测、调参，所以效率不高；想要追求开发效率，提交交付速度，那么必然无法兼顾代码性能，你能指望一个快速写完的代码性能有多好？所以这两个指标在大部分场景下是互斥的。

那么我们究竟该怎么选择呢？

首先从公司的角度来考虑一下这个问题

公司希望能够快速的迭代，快速抢占市场，快速验证产品模型和思路，所以有『效率』的诉求。公司同时也希望代码性能高，客户体验好。但是如果一定要二选一，那么公司必然会选择『效率』。因为效率上去了，产品够丰富、够深度，客户才会来使用；而体验好，只是锦上添花的东西。对于客户来说，功能不好用，客户都不会掏钱购买，再快没用。而且为了追求性能，需要开发人员花费很多的时间来设计，这部分时间公司也都是花了钱的，而如今人比机器贵，一个应届生月薪至少9K起，日薪400，而一台4核8G机器一年只要 2800，一天7元，一个应届生优化一天，赶得上购买57天的4核8G机器了，而4G redis，一年只要540元，用redis优化比人优化要便宜地多得多。

站在开发者的角度

人，都要实现『劳动价值』，所以开发者加入公司后，就要在公司劳动，实现价值。而劳动就是去实现一个一个的业务需求，为公司创造价值。但是根据『马斯洛需求』，人都有潜在的『自我实现』的需求，那么当一个开发者熟练掌握业务需求的实现套路后，必然谋求更进一步的发展。而对于『性能』这个东西，当你实现几遍之后，就差不多摸清楚了套路了，再去实现无法得到有效的提升。举一个实例的例子，大家都知道不要在循环里查询数据库，因为反复IO带来了性能损耗，也都建议改批量为单次。但是当你在业务需求里实现了好几遍之后，在你掌握之后，你再去做这个优化，已经没有太大的意义了，无法得到提升，而写这块代码又比较花费时间，所以有经验的开发者会止步不前。

solution

所以无论是从公司角度出发，还是从开发者角度出发，“过度”追求性能，都是弊大于利的事情（当然了对于初入职场的同学，或者对优化手段还不熟练的同学，追求性能是一个提升很快的事情），所以我们需要摆脱这个束缚，轻装上阵

当我们不再追求性能指标之后，事情就开始变得有意思了起来。首先不用花时间过度优化代码，那么时间就有富余，此时就可以去挑战一些更有难度的问题了。而这些问题无一不是困扰了公司很久的问题，也是客户抱怨已久的问题。一方面开发效率变快，公司满意，客户满意；另外一方面，有经验的开发者可以腾出精力来挑战难题，获得成长的同时修复了历史问题，公司满意、客户满意、开发满意，怎么看都是三赢。