这篇文章是编程语言 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)