聊聊系统思考

之前有球友问做需求时,怎么判断应该采取什么样的技术方案,怎么设计好一个技术方案?
一个好的技术方案,可以让你在开发的时候顺畅许多,像我们公司,开始开发(kick off)之前都会让开发人员进行估时,如果技术方案做的不好,考虑的不全,开发到一半,甚至临上线前,就会发现一些巨坑,可能花费你一两天时间去填,这样项目铁定延期。
另外通常复杂项目的技术方案,都需要拿出来评审,这也是你展示自己的一个机会,如果技术方案做的详细、周全、清晰有条理,对打造你个人影响力、在同事间传播你的口碑,是有很大帮助的。
相反,如果你的技术方案拿出来后,别人随便问几个问题、举几种状况,你的方案都没有涉及、解决不了,是很影响项目成员的士气的。
通常后端主力开发都是一个项目的大脑,大脑都不靠谱,这个项目就很悬了。
设计好一个技术方案,需要方方面面的能力:

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

前面两点主要用于「需求分析」阶段,帮助你充分的理解你所要开发的需求,可能你要反反复复读几遍需求文档,可能需要你之前就了解过这块业务、这个领域,读过相关的书籍、资料等等,这点我们后面再详聊。
后面两点主要用于「技术方案设计」阶段,帮助你用合适的技术选型实现产品的需求,这时候就很考验你对各种各样技术的掌握程度了,一个对 MySQL 理解的很深的工程师设计出来的表结构、索引、写出来的 sql 语句肯定是很让人放心的,一个对各种分布式中间件:kafka、es、zookeeper、apollo…… 都很了解的工程师,在面对同样的问题时,自然多了很多解决方案。
不过,你还需要一项把这些能力整合起来的能力,就是《第五项修炼》里提到的 —— 「系统思考」。
其实「系统思考」,对于所有人来说都是一项非常重要的能力,用《增长的极限》的作者德内拉·梅多斯的话来说:

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

人们的行为都是被系统所影响的,结构模式影响行为,而如果你看清了系统,看清了系统如何影响人的行为,你也就能从底层去影响他人。
事实上,很多被人们奉为行业经典的书籍,都是用系统思考的方式,给你讲清楚系统的底层逻辑,《卓有成效的管理者》、《国富论》、《深入理解计算机系统》。
而对于工程师来说,「系统思考」则更为重要,我用书里提到的几个「法则」来举例子。
法则 1 – 今天的问题来自昨天的解决方法
很多时候我们为了解决一个 bug,用尽了我们的才华,做出了自认为绝妙的技术设计,但上线后就发现虽然改了一个 bug,但是却又引入了一个 bug。
法则 2 – 选择更容易的办法往往会无功而返,甚至可能加剧状况
有时候我们容易犯懒,觉得这样简单,那就这样来,但如果出于尽快解决问题的目的,就会使用非系统的解决方案,而缺乏系统思考做出来的决定,往往会忽略了影响范围,导致改了一个 bug,却在另一个模块引发另一个 bug,或者忽略了未来的产品规划,导致后面做新需求的时候,发现自己之前做的方案,完全不适用。
法则 3 – 快就是慢
这个不用多说,程序员都知道。
法则 4 – 鱼和熊掌可以兼得 —— 但不是马上
有时候我们一开始想技术方案,就在纠结要处理这么多数据,性能会不会很慢,但其实一开始写完全不必想太复杂,先把功能正确实现了,再去考虑优化它。
……
现在做技术方案,我已经习惯问自己三个问题:

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

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

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

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

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

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

这两本就够了,当然还有另外两本,大家有空可以翻一翻,豆瓣有网友整理了这四本书的关系:
img
其实《第五项修炼》里讲的不只是「系统思考」,还讲了如何用「系统思考」以及另外四项修炼,来打造一个具有团队核心学习能力的学习型组织,其实是一本「管理类」的书籍:
img
以上。