聊聊系统思考

之前有球友问做需求时，怎么判断应该采取什么样的技术方案，怎么设计好一个技术方案？

一个好的技术方案，可以让你在开发的时候顺畅许多，像我们公司，开始开发（kick off）之前都会让开发人员进行估时，如果技术方案做的不好，考虑的不全，开发到一半，甚至临上线前，就会发现一些巨坑，可能花费你一两天时间去填，这样项目铁定延期。

另外通常复杂项目的技术方案，都需要拿出来评审，这也是你展示自己的一个机会，如果技术方案做的详细、周全、清晰有条理，对打造你个人影响力、在同事间传播你的口碑，是有很大帮助的。

相反，如果你的技术方案拿出来后，别人随便问几个问题、举几种状况，你的方案都没有涉及、解决不了，是很影响项目成员的士气的。

通常后端主力开发都是一个项目的大脑，大脑都不靠谱，这个项目就很悬了。

设计好一个技术方案，需要方方面面的能力：

• 对产品需求、对业务所在领域的理解和分析能力
• 和产品以及团队其他成员深度沟通、交流的能力
• 对当前技术架构的认识、理解能力
• 对各种常用技术的理解、灵活运用的能力
• ……

前面两点主要用于「需求分析」阶段，帮助你充分的理解你所要开发的需求，可能你要反反复复读几遍需求文档，可能需要你之前就了解过这块业务、这个领域，读过相关的书籍、资料等等，这点我们后面再详聊。

后面两点主要用于「技术方案设计」阶段，帮助你用合适的技术选型实现产品的需求，这时候就很考验你对各种各样技术的掌握程度了，一个对 MySQL 理解的很深的工程师设计出来的表结构、索引、写出来的 sql 语句肯定是很让人放心的，一个对各种分布式中间件：kafka、es、zookeeper、apollo…… 都很了解的工程师，在面对同样的问题时，自然多了很多解决方案。

不过，你还需要一项把这些能力整合起来的能力，就是《第五项修炼》里提到的 —— 「系统思考」。

其实「系统思考」，对于所有人来说都是一项非常重要的能力，用《增长的极限》的作者德内拉·梅多斯的话来说：

真正深刻而且不同寻常的洞察力，来自观察系统如何塑造自己的行为方式。

人们的行为都是被系统所影响的，结构模式影响行为，而如果你看清了系统，看清了系统如何影响人的行为，你也就能从底层去影响他人。

事实上，很多被人们奉为行业经典的书籍，都是用系统思考的方式，给你讲清楚系统的底层逻辑，《卓有成效的管理者》、《国富论》、《深入理解计算机系统》。

而对于工程师来说，「系统思考」则更为重要，我用书里提到的几个「法则」来举例子。

法则 1 - 今天的问题来自昨天的解决方法

很多时候我们为了解决一个 bug，用尽了我们的才华，做出了自认为绝妙的技术设计，但上线后就发现虽然改了一个 bug，但是却又引入了一个 bug。

法则 2 - 选择更容易的办法往往会无功而返，甚至可能加剧状况

有时候我们容易犯懒，觉得这样简单，那就这样来，但如果出于尽快解决问题的目的，就会使用非系统的解决方案，而缺乏系统思考做出来的决定，往往会忽略了影响范围，导致改了一个 bug，却在另一个模块引发另一个 bug，或者忽略了未来的产品规划，导致后面做新需求的时候，发现自己之前做的方案，完全不适用。

法则 3 - 快就是慢

这个不用多说，程序员都知道。

法则 4 - 鱼和熊掌可以兼得 —— 但不是马上

有时候我们一开始想技术方案，就在纠结要处理这么多数据，性能会不会很慢，但其实一开始写完全不必想太复杂，先把功能正确实现了，再去考虑优化它。

……

现在做技术方案，我已经习惯问自己三个问题：

• 这个技术方案，能满足这次新增的功能吗？
• 这个技术方案，对已有模块的功能，会造成什么影响吗？
• 这个技术方案，是否能够支持未来可能有的变动和新的功能？

这里就不再展开分享了，下次再和大家分享这本书。

今天就想表达一个观点，另加推荐两本书。

想表达的观点是： 「系统思考」很重要，尤其对于你做技术方案设计。

就这么简单，然后推荐大家去阅读相关的书籍：

• 《系统之美：决策者的系统思考》
• 《第五项修炼：学习型组织的艺术与实践》

这两本就够了，当然还有另外两本，大家有空可以翻一翻，豆瓣有网友整理了这四本书的关系：

img

其实《第五项修炼》里讲的不只是「系统思考」，还讲了如何用「系统思考」以及另外四项修炼，来打造一个具有团队核心学习能力的学习型组织，其实是一本「管理类」的书籍：

img

以上。

• Previous

  MySQL 的 MRR 到底是什么？