软件设计中有很多原则，其中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.（或者在你最开始编程的时候并没有意识到这类需求，其实你反而有可能在重构和重新编码的过程中发现更好的途径把新旧的问题一并解决）。如果你遵循上面两个原则那么重写的代码将会变得很少，否则代码也许会大量被重写
在其它所有情况下，尽量保持代码的简洁，这是才是最难的行为模式，但是一旦你这么做，当你再次回头看时你会说“我真的不能想象我以前是怎么工作的”

是否有KISS的典型例子

的确有很多KISS的典型例子，我会尽量找一个权威的例子，但是在这里我想说的是：一些世界上最大的算法的代码量总是很少的。并且通过阅读那些代码，我们可以很容易的理解其含义。算法的创造者，将问题简化简化再简化，最后再去实现它。很多最伟大的人，（他们）并不是编码高手，但是却创造了伟大的代码。

是否KISS原则只适用于JAVA代码

当然不是了，它适用于其它所有编程语言并且它也适用于你平常的生活。但是这些原则却不适用于：情感、爱情，更重要的，它也不适用于你的婚姻

【译】软件设计中的KISS原则相关推荐

软件设计中的一些原则
本文为大家介绍软件设计中的一些原则,都是经过长期经验总结出来的知识,每一个程序员都应该了解,相信对大家在进行软件设计的过程中会有很大帮助. Don't Repeat Yourself (DRY) DR ...
《盘点软件设计中的七大原则》
说在前头:本人为大二在读学生,书写文章的目的是为了对自己掌握的知识和技术进行一定的记录,同时乐于与大家一起分享,因本人资历尚浅,能力有限,文章难免存在一些错漏之处,还请阅读此文章的大牛们见谅与斧正.若 ...
【转载】软件设计中的易用性
软件设计中的易用性摘要: 这篇文章介绍了软件设计中"易用性"的概念并解释了为什么它在软件设计项目中应该是一个重要的部分. 介绍应用"易用性"到软件开发中 & ...
C#软件设计——小话设计模式原则之：依赖倒置原则DIP
前言:很久之前就想动笔总结下关于软件设计的一些原则,或者说是设计模式的一些原则,奈何被各种bootstrap组件所吸引,一直抽不开身.群里面有朋友问博主是否改行做前端了,呵呵,其实博主是想做" ...
第九十期:哪种人是软件设计中的稀缺型人才？
好的系统架构离不开好的接口设计,因此,真正懂接口设计的人往往是软件设计队伍中的稀缺型人才. 作者:从码农到工匠好的系统架构离不开好的接口设计,因此,真正懂接口设计的人往往是软件设计队伍中的稀缺型人才 ...
哪种人是软件设计中的稀缺型人才？
阿里妹导读:好的系统架构离不开好的接口设计,因此,真正懂接口设计的人往往是软件设计队伍中的稀缺型人才. 为什么在接口制定标准中说:一流的企业做标准,二流的企业做品牌,三流的企业做产品?依赖倒置到底是什 ...
漫谈 · 软件设计中的具象化
本文微信公众号链接:https://mp.weixin.qq.com/s/PiZU1biNR5DeqrjnhXE9ag 何为具象化?要说具象,就要说说与具象有关的抽象.表象. 抽象与具象: 抽象是通过 ...
C#软件设计——小话设计模式原则之：接口隔离原则ISP
前言:有朋友问我,设计模式原则这些东西在园子里都讨论烂了,一搜一大把的资料,还花这么大力气去整这个干嘛.博主不得不承认,园子里确实很多这方面的文章,并且不乏出色的博文.博主的想法是,既然要完善知识体系 ...
从奥运门票系统瘫痪到家乐福踩踏事件看软件设计中业务模型的处理
从奥运门票系统瘫痪到家乐福踩踏事件看软件设计中业务模型的处理作者:郭方明完成日期:2007-11-17 version 1.0 联系信箱:gfm.job@Gmail.com 注:转载文章,请注明作 ...
面向对象软件设计的“开—闭”原则
1．什么是开闭原则 "开-闭"原则是指软件实体应当对扩展性开放,对修改关闭.即软件实体应该在不修改的前提下扩展,这个原则实际上为软件设计指明了目标.我们知道软件设计 ...

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