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

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

对！

就是亲嘴的那个 “KISS”！

必定要多练习。

...

... ...

...

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

KISS

KISS = Keep It Simple, Stupid.

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

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

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

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

核心：

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

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

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

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

一、保持谦虚，第一个容易产生的误区就是总认为本身才是天才。保持谦虚你将最终实现超级天才的状态，反之，没有人会在意你。尽可能保持代码的简洁，不然你只能要求与你工做的都是天才。

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

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

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

五、先去解决问题，再考虑编码。不少开发人员喜欢一边思考一边编码，这么作的确也没什么错。若是你认为本身能够在脑壳中一边将问题拆分的足够小，而且同时动手编码完成这些功能的话，等待你的是从此一遍一遍又一遍 ... 。

六、不要惧怕删除代码，重构和从新编码都是很是重要的两个问题。当你遇到不存在的需求 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. 若是你遵循上面两个原则那么重写的代码将会变得不多，不然代码也许会大量被重写。

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

关注

做者：Owen Jia

做者我的博客：Owen Blog

一路荆棘，一路前行，风雨无阻。