这篇文章是编程语言 Clojure 的作者 Rich Hickey 的分享，原文中涉及到一些技术问题因为知识欠缺我也无法透彻的理解。这里摘录的是我从概念层面理解的他说的「Simple Made Easy」，欢迎指正勘误。
我们日常经常说产品要简单，但是在许多场合这个「简单」其实会有两种含义，一种是 Simple，一种是 Easy。
为了方便理解，我们把 Simple 翻译成简单，把 Easy 翻译成容易。从英文词源上来看，Simple 是 Sim + Complex ，意思是把一个东西折叠编织 —— 一个东西是否简单，取决于如何联系和交织在一起。
简单往往指的是只有一个角色，完成一个任务，只有一个目标，或者说是解决多维度问题中的一个维度。简单不是意味着非此即彼独一无二，而是不把问题交织在一起。更关键的是，简单是客观的，可以深入研究的。
而 Easy 的词源则是靠近，靠近一些熟悉的事情。而最关键的是，每个人对于 Easy 的理解都是不同的，Easy 是主观的，相对的。
举个例子，通过 PS 处理照片对我来说很 Easy（因为训练过很多年），但是 Instagram 调整照片更加 Simple ，因为他的功能只有这么简单。
许多时候我们说一个产品简单，是相对自己的，其实更应该用词为「容易」；而真正的简单，是不和别的东西耦合的，独立的东西。多数时候我们在产品开发过程中的冲突在于，产品经理喜欢说自己的设计是简单的（Easy），但是开发同学认为复杂（不符合自己开发的 Easy），但是却忽略了，用户要的是 Simple
这样说你会发现，我们做的许多事情，往往都是从 easy 开始，而不是 simple 。 easy 开始的加速度很快，但是随着项目的扩展，复杂度越来越高，速度慢慢就掉下来了 —— 想想每次重构代码的痛苦吧。而 simple 则刚开始很慢，因为需要定义许多的东西，抽象归纳许多对象，但后续推进则是越来越快 —— 因为结构清晰构件完备。
我曾吃过一个亏就是在设计药品库的时候，因为对这个体系不是很了解，就开始用国药准字做唯一的 ID，参考的就是基础的电商模块。但是做到后面就发现坑了，因为国药准字居然不是一一对应的，有些情况下会出现一个ID 对应两种药的情况，在和供应商对接的时候发现会有冲突，而且一旦发错药后果很严重。所以不得不在半路更换为商品条码。
刚更换完又出现了一个糗事，就是当时为了简单只考虑了对接一个供应商的情况，所以数据库是定时和对方同步的。但是有些药对方没有，不得不对接第二个供应商，这就会造成我们的药品库底层无法同时支持两个供应商的情况。
改造完之后以为就完了？不，这时候新的供应商说，可以给我们浮动价格，而不是一刀切的佣金（之前都是 x% 的一刀切，所以代码写死就好了）。
看到这里是不是已经吐血了…… 后续还有好几次折腾，这个药品库整整改造了一个季度。而当时如果耐心下来好好设计下，了解下行业背景，做做调研，给未来的谈判留下余地（开做之前就确实考虑过将来要推进非一刀切佣金），或许反而后续会更快。
所以，一个产品是否简单，从战术层面来看是 UX 关系的易用性；但是从战略层面来看，则是本身对于产品本身价值定位是否清晰，以及为了实现这个价值，抽象出来的对象和实体，以及实现方式是否避免过分耦合。
即使不编程，我们也应该在生活中控制复杂；复杂看似能让我们显得「很有深度」—— 想想那些不看完几个教程都无法上手用的产品吧，但是实际上最终会带来速度的降低甚至系统的崩溃；想想那些复杂的笔记方法，时间管理办法，最终有多少人坚持下来了？
而复杂背后其实有很多隐患 —— 我们怎么能指望一个自己都不理解所有结构的人，建立出来一个靠谱的东西？以及在未来，如何具有拓展性？
复杂性其实还会伤害我们的理解，因为人们一次只能处理很少的事情，当事情交织在一起的时候，这就变得更加困难了。而纠缠提高了复杂度，当他们全部耦合在一起时，我们只能整体来看待他们。所以有许多人写的东西都是汉字，但是合在一起却无法理解。
如何设计简单的东西？
- 使用能生成简单工具的构造：比如慎用专属格式或复杂的程序
- 重要的是构件，而不是编写工具：可以自己使用的很复杂， 但是呈现出来的产品很简单。
- 在开始之前，简化问题：是不是有些事情不必要放在其中解决
- 前期设计好抽象，来达到简单的目的
选择简单的工具，写简单的东西，简化别人的工作。简单是一种选择，避免复杂的文化，避免产生复杂输出的工具。简单易于理解，易于改变，易于调试。看看下面两个城堡，都很好看，但如果未来让你改变其中某些结构，你会选择那种构成方式？
达芬奇说：简单是最终的复杂（Simplicity is the ultimate sophistication）