【译】软件设计中的KISS原则

软件设计中有很多原则，其中KISS就是一个很典型的例子，其核心思想就是“解耦，解耦，再解耦”，职责单一化，功能单一化为以后的维护和重构都会带来极大的便利。
我google了一下，能搜到不少关于KISS原则的文章，但是从理念的理解和具体实践上感觉下面这篇文章说得才算比较到位，也很容易理解。（本文的行文结构也很简单，貌似也是遵循KISS原则写成的吧？）
本文翻译自Apache官方网站的“KISS Principle”
英文原文链接：The Kiss Principle

KISS原则

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

KISS原则是什么？

KISS是Keep It Stupid Simple或 Keep It Simple,Stupid。

KISS原则的含义是什么？

这个原则是我多年软件工程中获得成功的一个关键。现在的工程师和开发者们都曾经碰到的一个具有共性问题--将问题复杂化

一般来说，当开发者面对一个问题他们首先会将其拆分为可以理解的（雷涛注：功能上独立或者完整）的一个个小的模块，然后通过编码实现。但是，我敢说十有八九的工程师都会出现这样的错误，就是没有将问题拆分的足够小并且易于理解。这样做的后果其中一方面就是以很复杂的方式去实现一个很简单的问题，另一方面就是出现spagetthi code（雷涛注：一种高度耦合的代码），有时原本我们认为只有在BASIC中才会出现的goto语句，在一个400-1000行的java代码中，可能会出现一个数百行的方法。这种混乱代码的最终结果就是当开发人员输入代码的时候却发现以前的代码存在异常。如果开发者能把问题更进一步细分，这些异常问题都可以解决得了（These exception cases would have solved if the developer had broken down the problem further.）

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

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

如何在工作中实践KISS原则

的确有些非常简单的步骤可以遵循，但是对于有些人可能也算有些挑战。听起来很容易，尽量保持简单，其实它是在说耐心，而更多的是在说你自己。

保持谦虚，第一个容易产生的误区就是总认为自己才是天才。保持谦虚你将最终实现超级天才的状态，反之，没有人会在乎你。尽量保持代码的简洁，否则你只能要求与你工作的都是天才
将任务拆分成完成时间在4-12小时之间的代码量
将你所面临的问题拆分成多个小块。每个问题的解决需要的类的个数不应该太多
尽量缩短每个方法，每个方法的代码最多不要超过30-40行。每个方法只要负责解决一个问题就足够了。如果在方法中需要兼容很多条件，那么你应该将这些条件拆分为更小粒度的方法。不但要尽量保持使得代码易于月的和维护，而且同时应该能够让人快速的发现其中的bug。并且你应该经常重构你所编写的代码。
控制你的类不要过大，这种方法学（保持较小）同样也被用在我们之前提到的函数方法（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.（或者在你最开始编程的时候并没有意识到这类需求，其实你反而有可能在重构和重新编码的过程中发现更好的途径把新旧的问题一并解决）。如果你遵循上面两个原则那么重写的代码将会变得很少，否则代码也许会大量被重写
在其它所有情况下，尽量保持代码的简洁，这是才是最难的行为模式，但是一旦你这么做，当你再次回头看时你会说“我真的不能想象我以前是怎么工作的”