性能问题的背后：流程，技术和能力复制

----加研教练性能讨论的几点思考

对于性能这个话题，我感觉我们要从两个方面去考虑，第一个方面是流程，对应工程性能，第二个方面是技术，对应产品性能。

【流程方面】
流程方面的一个重大特点就是谁的权力大，谁的声音高。
目前在我们的工作中存在很多不合理的流程，那么对于这些不合理流程的改变不可能一蹴而就，那我们就看到一个改一个，看到一部分，改一部分。
举个例子，比如说我们mr合并中有一个限制条件是必须等待若干时间如15分钟之后才能够合入，这个设置在如下的场景中就非常的不合理: 团队成员对某部分代码实现已经达成共识，你知我知，一切都一目了然了，这还要求等待才能合入就很浪费时间。

【技术方面】
技术方面的一个重大特点是谁的技术好，谁的声音高。
关于技术方面，花样很多，教科书式的定式，在实践中的实现方式有很多，比如时间复杂度的考量，空间复杂度的考量，是通过软件实现还是硬件实现的考量，是在KERNEL层做还是在应用层做的考量，使用微服务还是单体服务的考量，数据一致性、可用性和分区设计的考量，有状态计算还是无状态计算的考量。

不管你用什么花样，最终决定你的实现是不是最优要从如下三个维度去看:
代码是不是最少？【在流程中就是步骤是不是最少？】性能是不是最好？复杂度是不是最小？

【两者关系】
流程与技术是相辅相成的，不能割裂。不能说你制定完流程以后你就交给技术人员去使用就好了，这个是非常不负责任的。因为流程跟技术需要互动起来，在一定场景下这个流程可能是准确的。但是换了一个场景以后，或者换了一个团队以后，因为场景和团队的素质不一样，那你的流程可能就会成为一种拖累，成为一种枷锁。

【能力复制】
能力复制的关键问题是建立有共识的团队。团队的共识需要通过不断的工作过程建立起来，就像军队的共识要通过大量的战斗过程建立起来一样。
在战斗过程中，面对共同的敌人，团队成员需要同仇敌忾，不断的用上面的三个维度来打磨自己的技术，自己的工具，自己的代码，自己的产品。
在上述过程中，如果大家能够把事情做成，那么极有可能就会形成共识，如此往复，他们在做下一个产品的时候就会更加顺利。这样做的事情越多，共识的作用就会越强大，等到各个团队成员分开去成立各自的团队的时候，也会把这种共识带到新的团队当中去，这样能力的复制性就越强。

【小结】
技术之于流程，就像水之于容器。容器简单，水的形态就会简单，容器复杂，水的形态自然也会复杂。

流程解决的是端到端的客户问题，他是跟需求紧密相关的。技术可以帮助建立合适的流程。流程反过来就会对技术的实施提供强大的助力。

性能问题是两者组成的一种外在表象。由此，我的观点如下:
解决性能问题，检讨的顺序应该是流程，技术，流程，技术、、、

当然，我们要时刻关注产品的价值，不然我们做的努力再多也没有意义。
【抛砖引玉，暂到这里】