对软件架构三大原则的思考与批判：KISS、SOLID、内紧外松

按：《原则》、《穷宝典》都在告诉你要学会去构建自己的原则。关于互联网技术的原则Rule很多、Law很少，大多都是经验性的。在架构设计过程中大家都容易互喷，因为极少人思考Law。KISS、SOLID、内紧外松是经典的三大原则，没有经过反思和批判的学习，是不彻底的，是一知半解的。本文来自王概凯老师的分享，希望给大家一些启发。

在架构设计的领域，⼈们总结出了很多原则。这些原则的⽤语⼤都很简略，容易传播。但是提出这些原则的⼈，往往不会告诉你，为什么应该是这样的原则。哪怕说了背景，过了⼀段时间，听的⼈可能已经不知道原则提出⼈的初衷。⽽且这些原则，粗看起来是很有道理，可是在实践中，却往往不是这么回事，那么就沦为⼼灵鸡汤了。在看这些原则的时候，每个⼈都要形成⾃⼰的判断能⼒，不要⼈云亦云才好。以下是个⼈对⼀些设计原则的思考，不⼀定正确，期望能够引发读者⾃⼰的思考，形成读者⾃⼰的判断。

 

KISS 原则

KISS(Keep It Simple, Stupid) 原则，翻译成中⽂就是“保持简单、愚蠢”。这是⼀句没有主语的话，猜想主语应该是指设计师，并且这个“It”应该指的是设计师所设计的⽬标系统。这条原则⼤意应该是告诉设计师在设计时要保持系统的“Simple and Stupid”。这个原则仔细分析⼀下，有两个⼤问题：

⾸先，“Simple and Stupid”的判断原则是什么，怎样才算是“Simple and Stupid”︖这是这个原则中最让⼈迷惑的地⽅，⼀般⼈下意识给出的是⾃⼰所认知的“Simple and Stupid”，这未必是提出这条原则的⼈所理解的“Simple andStupid”。比如让⼀个体操队员来做⼀个后空翻，对于他来说，这是“Simple and Stupid”。可是让⼀个没经过体操训练的普通⼈做⼀个后空翻，这绝对不“Simple and Stupid”，可能会摔断脖⼦出⼈命的。

也就是说“Simple and Stupid”是因⼈⽽异的，对于技术⽔平不同的⼈，他会的或者他能够熟练掌握的技术才是“Simple and Stupid”。⼀个⽔平很⾼的设计师，看到⼀个系统，他可以给出他设计的“Simple and Stupid”⽅案，可是如果实现的⼈水平很糟糕、技术⽔准达不到，勉强去实施的话，有可能会实现不出来的，哪怕做出来了也⼀定是问题多多，弄不好要搞出⼤事情。因此，要设计⼀个系统，要根据实施团队的⽔平，做适合他们的架构设计，这样才可以算得上是“Simple and Stupid”。

其次，⼀个系统的⽬的是为了给⽤户来使⽤的。⼀个设计师设计了⼀个“Simple and Stupid”的系统，那么这个系统对⽤户来说就⼀定好⽤吗︖如果⽅便了设计师，或者说⽅便了实施⼈员，说不定会影响使⽤系统的⽤户呢︖恰恰是让⽤户⽤起来“Simple and Stupid”的系统，才是⼀个好⽤的系统。那么给系统的设计师⼀个“Simple and Stupid”的原则，到底是在帮助谁︖损害谁︖符合业务⽬标吗︖许多公司的设计师在设计系统的时候，不断的和业务团队冲突，为了保持设计师所持的“Simple and Stupid”理念，很容易会降低⽤户的体验，导致最后⾃⼰也⼀点都不“Simple and Stupid”。

可见，这个设计原则⽤到软件⾏业是有问题的，我们不能够为了“Simple and Stupid”去设计，不能够设计⼀个系统时，依照“Simple and Stupid”为⽬标去设计。因为设计⼀个系统的⽬的是为了更好的完成系统所服务的⽤户的访问，⽽不是为了设计者或者实施者。考虑设计者和实施者的时候，是在这个完成⽤户访问的前提下，怎么做到低成本的、可持续的迭代。因此，如果⼀个设计者不能够理解⽤户的需求，不能够理解⽤户通过不同的访问⽣命周期来达到⾃⼰的⽬的，是无法设计好⼀个系统的。

只有通过对⽤户的业务⽣命周期、访问⽣命周期进⾏分析，根据流量的压⼒不同，进⾏合理的树状拆分，也因此形成不同的系统，那么这些所形成的系统⼀定是内聚的，边界⼀定是清晰的，也⼀定是“Simple and Stupid”。也就是说，只有从业务上去分析、去拆分，才能够得到⼀个“Simple and Stupid”的结构，这是⼀个副产品，⽽不是⽬标。如果依照这个原则为⽬标去设计，则可能会破坏业务本身的整体。

这个原则本身是从军⼯⾏业出来的，说明“Simple and Stupid”含义是有军⼯背景的，有军⼯⾏业⾃⼰的标准，读者感兴趣的话可以去研究⼀下。不去了解⼀个概念的历史，盲⽬的直接引⽤到软件⾏业来，很容易