前言
之前在开发的设计阶段，我经常喜欢把一个组件设计的很复杂：
这个时候我的leader和我提出了一个原则：KISS 原则，简单跟我们介绍了一下，大致的意思是就是我们要把组件设计的更简单，也对我年轻的想法表示理解，露出了长辈看待晚辈慈祥的目光。
于是，我打算去了解一下什么是 KISS 原则，就产生了这篇文章。
KISS原则
概念
我去搜索 KISS 原则的时候，关于该原则的起源众说纷纭：
- David Mamet（大卫马梅）的电影理论
- 美国洛克希臭鼬工厂的凯利.约翰逊(Kelly Johnson)
- 美国军方的软件开发
但是这个不重要，重要的是领会其精神内核。
KISS 是英文 Keep it Simple and Stupid 首字母的缩写，意思是“保持简单和傻瓜”。
以下内容来自百度百科
KISS 原则是指产品的设计越简单越好，任何没有必要的复杂都是需要避免的。其最完美的案例是傻瓜相机，傻瓜相机操作简单，似乎连傻瓜都能利用它拍摄出曝光准确、影像清晰的照片来。
KISS 是一个描述性的原则，它认识到两件事情：
- 人们通常喜欢简单的，容易学习和使用的事物。
- 制造产品或提供服务的公司会发现简单对公司来说也有一个好处，因为这将缩短时间，降低成本。
虽然公司尝试站在用户角度使用这个原则之处的设计时间也许会更长，成本会更高，但其实际效果将会非常有利，因为从长远角度来看，容易学习和使用的产品或服务，其将来的生产和服务的成本将会大大降低。
各个领域的应用
以下内容来自百度百科
广告设计
广告创意必须简单明了、纯真质朴、切中主题，才能使人过目不忘，印象深刻。
广告大师伯恩·巴克认为：“在创意的表现上光是求新求变化、与众不同并不够。”杰出的广告既不是夸大，也不是虚饰，而是要竭尽你的智慧使广告信息单纯化、清晰化、戏剧化，使它在消费者脑海里留下深刻而难以磨灭的记忆。如果过于追求创意表现的情节化，必然使广告信息模糊不清，令人不知所云。
企业管理
- 较简单的系统更容易构造、运行和维护；
- 较简单的解决方法总是更具弹性、柔性；
- 较简单的系统更便宜；
- 较简单的系统更容易被更快地实现、获得更快的回报；
- 较简单的方法使用者更喜欢；
- 较简单的系统更容易分阶段地执行；
- 较简单的系统更容易被使用者了解。
目标管理
- 让它简单些，连笨蛋都看得懂
- 好的目标不是越复杂越好，反而是越简洁越好
- 符合 KISS 原则的目标都是关键的，而非包罗万象
- 目标必须确定优先顺序，而关键的目标则是资源和努力的重心
网页设计
- 网页的下载不要超过 10 秒钟
- 尽量使用文本链接，而减少大幅图片和动画的使用（
寒草理解不能） - 操作设计尽量简单，并且有明确的操作提示
- 网站所有的内容和服务都在显眼处向用户予以说明等
产品设计
KISS 原则是DFMA中最重要的一条设计原则和设计思想，几乎贯穿于 DFMA 的每一条设计指南中，减少零件数量是 KISS 原则在 DFMA 的主要体现。
一般来说，产品中的零件数量越多，产品制造和装配就越复杂和越困难，产品制造费用和装配费越高，产品开发周期也就越长，同时产品发生制造和装配质量问题的可能性越高。在确保实现产品功能和质量前提下，简化的设计、更少的零件数量能够降低产品成本，缩短产品开发周期，提高产品开发质量。高水平的机械工程师把复杂的东西设计得很简单，而低水平的机械工程师则把简单的东西设计得很复杂，此时也可以把 KISS 原则应用上。
对于机械工程师来说，减少零件数量、简化产品设计能够大幅减少工作量，一个零件在其开发周期中的任务包括零件设计、生成二维工程图、样品制作、零件试产、零件装配、零件质量和功能验证等等，无一不是繁重的任务。减少零件数量、简化产品设计对于工程师来说是看得见的实惠，能够让工程师把更多的时间和精力放在提高产品设计质量上来。
KISS 原则在编程中的应用
来源于每个程序员都应该了解：KISS：60年前美国军方的编程原则
当今的软件工程师和开发者们有个共同的问题，那就是他们总是慢慢地使得问题复杂化。 正确的做法应该是当开发者遇到一个问题后，把问题拆分成一个个能够明白的小块，然后进入编码阶段。
你需要先想好问题的解决步骤一共分为几步，然后再进入编码。
而不是拿到需求后，就开始一边写代码一边去满足需求。这样做的好处就是你的代码会变的足够容易理解和足够清晰。
运用KISS原则，能获取到什么好处？
- 你可以更好地解决更多问题。
- 你将可以通过很少的几行代码去解决复杂的问题。
- 你将可以产出高质量的代码。
- 你将可以构建更大更易维护的系统。
- 当新的需求来了后，你的代码将会更加的灵活，易于扩展、易于修改和重构。
- 你将完成比你想象得更多的事情。
- 你将能够工作在一个大型开发团队和大型项目中，因为所有的代码都是stupid simple。
如何把KISS原则用到我的工作中？ 这里有几个简单的步骤可供执行，但有一定挑战。就像说起来的那么简单，keep it simple，主要是需要耐心，更多的靠你自己。
- 要谦虚，不要认为自己是个天才。只有谦虚了，你才能真正达到超级天才的水平，即使不行，who cares！你的代码那么stupid simple，所以你不需要是个天才！
- 将你的任务分解为4-12小时的子任务。
- 把你的问题拆分成多个小问题。每个问题用一个或者很少的几个类来解决掉。
- 保持你的方法足够小，每个方法永远不要超过30-40行代码。每个方法都应该只处理一个小小的问题，不要搞太多uses case进去。如果你的方法中有多个分支，尝试把他们拆分成多个小的方法。这样不仅容易阅读和维护，找bug也更快。慢慢的你将学会爱。
- 让你的类也小点，原则和上面的方法是一样的。
- 先解决问题，然后开始编码。不要一边编码，一边解决问题。这样做也没什么错，但你有能力提前把事情切分成多个小的块，然后开始编码可能是比较好的。但也请你不要害怕一遍遍重构你的代码。另外行数还不是为了衡量质量的标准，只是有个基本的尺子而已。
- 不要害怕干掉代码。重构和重做是两个非常重要的方面。如果你遵循上面的建议，重写代码的数量将会最小化，如果你不遵循，那么代码很可能会被重写。
- 其他的任何场景，都请你尝试尽可能的简单，simple，这也是最难的一步，但一旦你拥有了它，你再回头看，就会说，之前的事情就是一坨屎。
许多伟大的问题解决者（problem solver）都曾不是伟大的程序员，但他们却产出了伟大的代码！编程是为了解决问题，我们不只是程序员，我们不只生产代码，让我们一起成长为伟大的问题解决者。
对于 KISS 原则的感悟
我也是作为一个该原则的学习者，由于我之前喜欢加入一些花活儿使得组件更加复杂，所以不能说对这个原则一窍不通，只能说我啥也不是。但是通过学习其概念，我也会有一些自己的感悟。
我试图思考某些经典的案例得以成功是否也是源于其简单的设计，比如：
- 苹果公司的产品和操作系统
- 脑某金的广告
- ...
可能冥冥之中都符合这个原则，使得他们有着空前的影响力，而我怎么在工作去用好 KISS 原则也是一个大问题，我想到的是几个方面：
- 开发前准备工作
- 组件职责设计
- 工作流程
具体也是要和上面那些结合起来，从现在起我可能会努力不再热衷于一个强大的可以做更多事情的组件或者类，而去做能力的解藕和拆分，使其更简单易用，职责清晰。
我在想是否需要举一个实例：
之前在聊天的时候，说到一个这样的需求，比如一个表单组件，可能就是编辑器和新增器组件会用到它，但是如果查看器说不定也会需要信息展示。
我当时就提议：
“给表单组件加一个 type 是 view，当组建的类型是 view 的时候，添加一个 css，把表单项的边框去掉并且 readonly 。”
这个想法是不是听上去很诡异～
然而现在看，查看信息并不属于表单能力范畴，现在的我就会去增加一个 xxxLayout 组件了。
结束语
前端不只是技术，思想原则亦是软实力。这次结束语不扯有的没的啦，直接求关注，点赞，点赞关注是对我最大的支持。如果有问题或者不同见解欢迎留言讨论✨
资料：
