系统设计的演绎归纳法：开坑

之前犹豫要不要在公众号的文章里去说一些系统设计的内容。担心自己能不能把一些概念说得深入浅出是其次，更大的阻碍在于阅读碎片化越发严重的当下，受众普遍难以接受高度概念化和相对有深度的内容。最后决定开坑的原因也很简单，就是我写的东西根本没人看！所以以上这些担心都是多余的：）

这个系（da）列（keng）主要有以下的目的：

- 将信息系统里的一些概念通过简单易懂的方式介绍给不是这个领域的朋友们

- 通过这些概念、设计和模式揭示出一些跨领域通用的逻辑和思维方法

- 鼓励大家从偏重演绎法（deduction）的思维方式过渡到演绎、归纳（induction）并重的思维方式

内容会主要集中于如何对特定领域（domain）做出合理抽象。我非常同意一句话，“The hardest part of writing a specification is choosing the proper abstraction”。不管是对于系统设计是这样，对于所有的其他实际问题也是一样的。在我们从小经历的教育过程中会被要求做很多习题。这些习题都有严格和确定的领域设计，以及明确的解决方法。这种教育更多的是教会我们去合理的用特定的方法和工具来解决问题，但缺失了对定义和识别问题能力的培养。这就是为什么大多数人的思维方式会不自觉的偏向于使用演绎，而不善于归纳。

缺乏归纳能力的直接结果是不能找出一件事物在特定条件下的普遍规律，或者说是主要矛盾。其表现就是：各种脑残要求，各种无效工作造成的返工和加班，各种钻牛角尖和不能相互理解造成的沟通障碍等等等等。不能说一个好的思维方式一定能解决以上的诸多问题（其实我自己也时常对这些问题处理得很差），但相信还是能有效减少这种问题发生的概率。

对特定领域做出合理抽象是非常困难的。在绝大多数情况下甚至不可能有最优解，仅仅只能够挑选一个不那么糟糕的。最为困难的一步在于找到一个开始的思路。这个时候人们往往依赖于一种叫“经验”的东西。实际上“经验”这个概念就是对用于做出特定领域合理抽象的各种模式（pattern）的一种模糊化叙述。在人类工程史上，无数杰出的工程师和科学家总结出了繁多的适用于各种领域的合理抽象和模式。其中很大一部分是可以跨领域适用的。但碍于专业的限制，这种跨领域的模式归纳变得非常困难。有幸的是，计算机和程序在现代社会已经渗透到了各行各业，这些跨领域的知识都能够在信息系统中聚集和实现。这使得信息系统不经意中成为了归纳各种跨领域抽象和模式的最佳试验场。从《人月神话》，到Unix&Linux系统的设计哲学，再到各种（程序）设计模式，软件架构演进，这些工程实践中的瑰宝带给我们的启示远远超过了这些工程问题本身。希望在之后的内容中也能带给大家同样的启示。