程序员不要和陌生人说话——漫谈一些有趣的架构原则waitrabbit的博客-

这篇让我们看看那些有意思的架构原则。俗话说嘛，不懂架构原则的项目经理不是好产品！

1. Kiss 原则

先温习一下 Kiss 原则——Keep it simple and stupid。

含义：

不要开始就上大而全、复杂的架构，而要随着需求和业务的变化，让架构自然生长演进。只要能满足现有需求，就不引入不必要的复杂性。保持系统的简单甚至是我们的目标。

Kiss 原则被很多架构师推崇，甚至有产品经理说这最早产品设计的一个原则。举一个最常见的例子你就知道了，谷歌的主页和苹果的ipad的一个按钮 。 

在我们应用 Kiss 的过程中，能给大家的建议是：

1，简单的含义要理解为在“人”的层面对系统的理解简单，而不是在机器层面。那可能意味着我们要做更多的面向对象操作，最新的“领域驱动设计”了解一下。其实很多科技的发明，许多创新都可以归为“与人的接口的进化”，从指针到面向对象都是这个道理。

面向对象：以客观世界存在的事物为原型来组织设计程序的一种方法论

2，当架构在系统的演进中变为瓶颈（此时 Kiss 已经没有当初的感觉），你就需要安排重构了。有人说架构是在重构中诞生的，显然这是对 Kiss 原则的佐证。

2.“别重复自己” 原则

“别重复自己” 这一说法可能来源于《阿甘正传》，主人公取得了一系列成功，没有一个是重复的。这个原则还有其他名字，比如 “语义一致性原则”、“用同一种方法做同一种事”，讲的都是一回事。

含义：

当我们在两个或多个地方的时候发现一些重复代码的时候，我们需要把他们的共性抽象出来形一个唯一的新方法，把它放在一个地方，改变现有的地方的代码，让它们来调用这个新的方法。

地方可以指一个函数、一个类或一个服务。这条原则是程序员的基本功和基本规范了，被许多架构书反复强调。

建议所有公司在面试时程序员，考是否看过 Forrest Gump。

图1，从不重复自己的阿甘 

3.“不要和陌生人说话” 原则

看到这里证明我真的没有标题党，“不要和陌生人说话”原则还有一个官方说法 “迪米特法则”，是我的邻居迪米特告诉我的。

含义：

一个对象实例的一个方法内，应该只有以下变量成员

• 对象实例本身（就是 This）

• 方法的入参

• 在方法内创建的实例变量

• 对象内的其他成员变量和方法

• 对象实例具有访问权限的全局变量

而禁止有其他成员，比如和运行环境耦合的东西，如界面元素、或者是第三方的网络接口。

它背后道理，下面这张图就说的很明显了：

图2，和邻居说话，不要和陌生人说话，因为下次你想和他继续说话时，他可能不在了

如果你的程序里耦合和很多“陌生人”，那么这些不可控的因素，会使你的程序脆弱无比，你总不会希望用户散步出服务区时，你的程序界面突然变得很难看。 

依赖外部资源的东西，尽可能本地化，比如依赖包。

如果确实需要访问第三方 API，那么怎么办？ 

“代理者模式！”

好，独秀同学你坐下。关于代理这模式的内容这里就不赘述了，我们应用内部向系统外部调用时，应该都通过代理类。包括微服务中的熔断机制，也是让你不至于等陌生人等的太辛苦。

记住，程序员要学会保护自己，别和陌生人说话！

4.“你懂的” 原则

现在有人说话老爱夹杂一句，“你懂的” ，“You know” 什么的，其实也许对方什么也不懂。架构原则里正好有一个一样的原则，学名叫“ 约定（或者说惯例）优于配置”（Convention over Configuration）

含义：

简单点说，就是将一些公认的配置方式和信息作为内部缺省的规则来使用。例如，Hibernate的映射文件，如果约定字段名和类属性一致的话，基本上就可以不要这个配置文件了。Maven也使用了CoC原则，当你执行mvn-compile命令的时候，不需要指源文件放在什么地方，而编译以后的class文件放置在什么地方也没有指定，这就是约定优于配置原则。

简单来说，架构中不要那么追求过分的灵活性，要尽量优先使用约定俗成或者惯例的东西或框架。同样，在你自己的技术架构中也可以约定一下东西以提高效率。

Rails中很少有配置文件, Rails 的粉丝号称其开发效率是 Java 开发的10倍，估计就是这个原因。

（本文就靠上面这句话带流量了）

图3，你懂的原则

5. 好莱坞原则

据说好莱坞的经济人有一句俗语“Don’t call me, I call you!”, 就是别烦我，我主动联系你，你别主动联系我。后来，那些一直没接到电话的就干了程序员，创建了这个原则。

含义：

程序中每个组件都应该是被动的，对于自己被谁调用，出于什么目的调用，底层组件是不应该知道的。它配合依赖倒置原则使用，上层模块要依赖于接口，而不是底层模块，底层模块实现接口，更不能耦合上层逻辑。

就像介绍微服务架构时，我常说的一句话，“沙不知道河，一个微服务也不应该知道应用的存在，同样我们也不知道造物主的安排”。

似乎也可以叫“知道的越多越麻烦原则”

图4， 好莱坞原则

好了，上面选的这些都是名字听来比较有趣的架构原则。当然还有一些非常好，但名字很晦涩的比如什么“李斯柯夫继承”原则，但思想都是很深邃的。如果本文激发了你的兴趣，就自己去谷歌百度一下吧。

欢迎关注作者微信公众号