原文自国外技术社区dzone，作者为 Kevin Hooke，[传送门]https://dzone.com/articles/what-defines-simple-code)
Keep it simple。
简洁的代码意味着不复杂。好吧 :laughing:，那复杂的代码是怎么样的呢？我们不希望而且不想看见复杂的代码因为：
- 难以阅读
- 难懂
- 难以升级和维护
OK:ok_hand:，所以简单的代码是指：
- 容易阅读
- 容易理解
- 容易升级和维护
由于上述所提到的，其他好处也变得更容易达到了。例如，简洁的代码更容易做单元测试。
我们要怎么做才能确定我们写的是简洁的代码呢？许多总所周知（但不常用）的行业最佳实践引导更简单的代码。例如：
单一责任原则：Bob Martin 将其定义为“改变的唯一理由”。一个类应当只有单一的责任功能 — 它所负责的一个特性。如果有超过一个原因需要对类进行修改的话，这个类的所肩负的责任就会超过一个从而会导致需要做太多的事情。
一个类或者一个方法应该只做一件事并且要把这件事情做好 — 不是10件，不是5件，就唯独一件。限制在一件事情上减少了复杂性潜入的机会（这和单一责任原则是一样的）。
简单的方法是指那种足够短能够让你更容易去理解并且掌握它的用意。太长是指在你阅读的时候必须一页一页地翻滚，在这个点上，如果不反复滚动和重新阅读，就能难理解这个方法的全部目的。
容易懂的形式命名变量、方法以及类：一个能够描述变量的作用（目的、代表什么等等）、方法的作用、类的作用的明确名字能够有助于传达或理解。一个方法所做的事情如果并不像它名字所描述的话是难以被理解的。程序员并不喜欢惊喜。
清晰的文档描述：在 Java 中，我们使用 JavaDoc。你的 JavaDoc 需要去描述类的作用以及每个公共（至少）方法的作用。它不应该陈述那些显而易见的表象；它不应该重复那些已经在类和方法名中清晰表明了的功能描述。如果只是重复方法名表示的内容，就不利于方法的可读性；这只是多添加一些我不得不读但没有任何收获的内容而已。例如在下面这种并没什么作用的文档，虽然许多开发者会这样做：
/** * 这个方法是用来创建一个账号。 */public Account createAccount(){ ...}
。。。因为作为一位开发者，我当然知道这是一个方法，你不需要告诉我这个。从方法名上我也知道这个方法是用来创建账号。这个 JavaDoc 没有什么额外的价值，并且如果没有价值的话，最好的方法就是去除它。
如果你从一开始就想创造更简单的代码，那么这种事比起创建过于复杂的代码然后尝试去简化它更容易实现。重构是你编码时的好朋友，并且当你完成你代码工作的第一次迭代的时候，你应该花费一点时间来重构你的代码。然而，如果从一开始就意识到要避免复杂性的操作，你可以使你的工作变得更容易一些。