转载

软件架构设计原则之“KISS”的总结使用原荐

今天聊一聊软件架构设计中的 KISS 原则。

对！

就是亲嘴的那个 “KISS”！

一定要多练习。

...

... ...

...

作为一个程序员我是推荐理解为“亲嘴”的，可以很好的解决单身问题，但作为一个架构师在“亲嘴”的同时，希望还能理解它另一层含义。

KISS

KISS = Keep It Simple, Stupid.

它的核心就是把一切事情简单化，用最简单的解决方案来解决问题。

把一个事情搞复杂是一件简单的事，但要把一个复杂的事变简单，这是一件复杂的事。

简单的人生就是幸福。但是这里需要说明的是简单是优秀的，但简单是有底线边界的，超过底线的简单也有变得稚幼。KISS原则来源于《UNIX编程艺术》中总结的。

简单是软件设计的目标，简单的代码占用时间少，漏洞少，并且易于修改。

核心：

拆分，把复杂的逻辑拆分为一个个单一执行单元。
简洁，只允许串型依赖的调用关系。
简单，单个执行单元代码量一定要尽可能少。

我们应该如何从KISS原则中获益？

你会以更快的速度解决更多的问题
你会以很简洁的代码来解决很复杂的问题
你能写出高质量的代码
你能完成更大的系统并且它很容易维护
你所编写的代码会更加灵活，易于扩展、修改或重构
你能得到比你原本想象的更多
自从你将代码变得 Stupid&Simple，你就能有机会在更加庞大的产品团队或者项目团队中工作

软件架构设计原则之“KISS”的总结使用原荐

如何在工作中实践KISS原则？

1、保持谦虚，第一个容易产生的误区就是总认为自己才是天才。保持谦虚你将最终实现超级天才的状态，反之，没有人会在乎你。尽量保持代码的简洁，否则你只能要求与你工作的都是天才。

2、将你所面临的问题拆分成多个小块，每个问题解决需要的类的个数不应该太多。将任务拆分成完成时间在4-12小时之间的代码量，并让任务的依赖尽可能的是单一的关系。

3、尽量缩短每个方法，每个方法只要负责解决一个问题就足够了，每个方法的代码最多不要超过30-40行。如果在方法中需要兼容很多条件，那么你应该将这些条件拆分为更小粒度的方法。

4、控制你的类不要过大，这种方法学（保持较小）同样也被用在我们之前提到的函数方法（methods）上（Keep your classes small, same methodology applies here as we described for methods）。

5、先去解决问题，再考虑编码。很多开发人员喜欢一边思考一边编码，这么做的确也没什么错。如果你认为自己可以在脑袋中一边将问题拆分的足够小，并且同时动手编码完成这些功能的话，等待你的是今后一遍一遍又一遍 ... 。

6、不要害怕删除代码，重构和重新编码都是非常重要的两个问题。当你遇到不存在的需求 or you weren't aware of when you wrote the code to begin with you might be able to solve the old and the new problems with an even better solution. 如果你遵循上面两个原则那么重写的代码将会变得很少，否则代码也许会大量被重写。

在其它所有情况下，尽量保持代码的简洁，这是才是最难的行为模式，但是一旦你这么做，当你再次回头看时你会说：“我真的不能想象我以前是怎么工作的”。尽量保持简单，听起来很容易，其实它是在说耐心，而更多的是在说你自己。