你是否还记得KISS原则？

Unix编程艺术作者提到，所有的Unix哲学都可以浓缩为一条铁律，那就是KISS原则（Keep it Simple and Stupid）。

张小龙说，简单是个非常高的目标，而不是一个简单的目标。他认为简单可以替代美观、合理、优雅，在他看来简单是美的，也是最好的。

十多年来微信增加了很多功能，但让他庆幸的是，微信还像十年前一样简单。

看乔布斯传，提到了少即是多，这虽然是一句简单的话，很多人自以为知道了其中的奥秘，但很少人能做到。

据说iPhone的灵感在于抽水马桶，马桶上只有一个按钮可以做就可以做这个马桶最需要做的事情。这个创新在当时塞班手机、功能手机那么多按键的时代被提出来是需要多大的勇气。又有多少人可以抛掉思维惯性，回过头来做这样一款只有一个按键的手机？

把一件事情搞复杂是非常容易的，把复杂的事情变简单这却是非常难的。

软件工程很多设计并不是简单的，一方面受限于工程师的认知和能力，他们无法对现在面对的问题抽丝剥茧；另一方面迫于晋升压力，想要证明自己的技术价值，重复造轮子，上价值，为了所谓的技术沉淀，把简单的事情复杂化。

为什么他们的认知和能力上不去？

首先他们将自己的思维固化在现有的认知里，他们的能力不够，缺少抽象与逻辑思维，还是在靠经验在解决问题。

而不是从问题原点来的，那就缺少了思考路径与取舍过程，在他们脑中只有一个方案，也就是这唯一的一个。

在业务领域流程引擎是个奇葩的存在，相信很多同学在不同团队都看到过自己的流程引擎。

虽然他们都叫流程引擎，但是解决的问题并不一样。很多同学可能发现，学会这个流程引擎是怎么运作的，比掌握系统业务逻辑难多了，这不就是刻意制造困难吗？

为什么流程引擎不能降低复杂度，反而添加了新的复杂度？

比如我们通过代码不能看明白逻辑全貌，需要跳脱出原有代码逻辑去看相关的配置、DSL，这种跳入跳出不断增加了思维断点，也就提升了复杂度。

所以对于很多系统来说引入流程引擎是完全没有必要的。

那什么样的系统适合引入流程引擎呢？

我想我就不提供建议了，不然这个建议可能变成了一些人新的锤子。

所以把事情做简单不是一件容易的事情，它需要打破常规、不破不立的勇气；要能洞察事务本质，还有化繁为简的能力，这往往是深度思考的能力。

KISS原则对于程序员来说，是尽量将复杂留给自己，把简单留给他人，而不是反过来。

我见过一些配置化方案，研发觉得挺酷，方案很复杂，但整个操作流程对于产品或者运营一点不友好，以至于产品和运营每次操作心惊胆战，一旦顶着压力搞完了一套配置就再也不想动了，所以大家都是一股脑的加配置，老配置是不敢轻易修改的。详见：配置化有哪些问题？

一个工程师有没有简单思维，往往看他设计的API或者接口就行了。因为接口的一面是使用者，一面是实现者。

站在使用者角度是否更便于理解，便于扩展。对于实现者是否能表达抽象逻辑与含义。

Bad Case就是接口完全没有扩展性，他在设计这个接口时，我猜他有的只是产品的PRD里面的样子，而没有这个业务逻辑或者产品形态的样子。

代码写的怎么样，方案设计的怎么样都是这个人思维的投射。

思维逻辑清晰的人，他的方案与代码写的是有条理的；头脑混沌的人，他的代码与方案就是网状的，找不到方向与线头。这种是最可怕的，他们看似很努力，但越努力越错。

之前说的，我们能力的组成，最下面是素质，上层是技巧。

对于研发人员来说素质是什么？是编码能力，是抽象能力，是工程设计能力。技巧是什么？是业务理解能力。

很多人在自己的编码素质没有很精进的情况下，就去深度参与业务理解了。这其实是本末倒置的，因为市场上确实有一些人强调了业务理解的重要性，但其实这是对于一些技术素质达到一定程度的人才适用。

如果编码素质不过关，你很难做好抽象、高扩展的代码实现。也就很难做到真正的简单。

我的建议是技术素质起码要积累到P7的水平，在此之前你需要把70%的精力投入到技术学习与技术素质提升上。

不然很多人技术没搞好，业务也懂得半斤八两，这种人其实是最没竞争力的，因为哪一块都没能创造最大的价值。

不知道有多少刚工作的码农还在看项目管理、UML、设计模式、Unix编程艺术、操作系统原理、TCP/IP这些经典的书。

大部分人要么去看所谓的高并发了，结果一问都是各种redis cluster、jedis这种proxy层的东西，那我就揪着你问分布式原理、分布式算法、CAP了。

很多人对CAP侃侃而谈，问你架构设计中是怎么解决P问题的？大部分人没解决过，或者本来解决的是A问题，但他以为解决的是P问题，说明对于遇到的问题并没有深度思考。

还有一部分人把学习Spring源码当成了全部，读好Spring源码可以提升你的编码感觉，因为过程中你肯定学到很多没见过的代码写法，有些是可以拿过来的。

但Spring解决的是技术问题或者代码问题，并不能简单的Copy去解决我们的业务逻辑复杂度问题。

作为技术人，我们要有把控产品的能力，B端产品和C端产品一样都是给人用的，都不应该做的过于复杂，简单永远是产品设计的第一原则。

有些说B端设计要有业务理性，C端要业务感性，B端出发点很少是使用感受上的，而更多是价值、管理、战略层面的。

这句话我赞同也不赞同，只要是产品，使用体验就是第一位的。

不要简单的和过去的CRM、ERP那么丑陋的系统去比。

某种程度来说过去十几年好的技术人、产品人一股脑投入到了C端互联网行业，B端行业大概率都是没那么出色的，他们做B端产品很大程度上就是抄，抄国外上个世纪的一些产品形态，也缺少创新，很多系统的样子都是Win XP时代的。

现在的B端产品，飞书、钉钉、Slack不都是使用体验非常好的吗？

WPS当年就是比Office好。所以使用体验这件事不是由B端产品决定的，而是有人的特点决定的。

有些可以轻易的说出奥卡姆剃刀原则，如无必要、勿增实体。但他们在“行”的层面完全做不到，看似“知”了，但思考的一点不深。

简单这件事不仅体现在代码、方案设计、产品设计层面，也体现在我们人性的层面。

王慧文说成长会有愚昧之巅、绝望之谷、开悟之坡。

大部分人在愚昧之巅而不自知，同时又没有勇气接受掉入绝望之谷，又没有能力爬上开悟之坡。

有的人因为性格原因管理成本太高。那在我看来这就是复杂的，不是简单的。

比如为什么很多老板喜欢用聪明的应届生？

先说聪明，简单就是理解力，老板说什么东西，在他那都是新的，他都会两眼放光的去做，而且是一张白纸，没什么历史包袱，或者脑袋里没有锤子，可以很快的用最简单的方式去想这个问题。

反观一些有过几年工作经验的同学，看似经验多了，但可能多的是拿锤子的经历。

再加上人如果不聪明，可能觉得锤子天下第一，什么刀枪剑戟斧钺钩叉，在锤子面前都不值一提。

有时甚至会出现文不对题的情况。

你和他讨论现在技术遇到的问题？他说锤子可以解决。你和他讨论怎么从管理手段解决这些问题？他说锤子可以解决。你和他讨论扩展性问题？他说锤子可以解决。

一个人如果固执、缺少成长性思维、又不聪明，就会变成这种管理成本非常高的人。

聪明人老板花1个小时辅导，就可以创造2倍价值。普通人老板花2个小时辅导，就可以去创造价值了。这种管理成本非常高的人，老板花4个小时，不一定能创造价值。

老板的时间是有限的，慢慢的就不会在这些管理成本非常高的人身上浪费时间 。也就变成了需要被替换的对象。

罗翔说过类似的话，越是认知能力不够的人，吵架越厉害，他们擅长合理化和单一归因。他们聊天的目的在于证明他们是对的，在他们的世界中没有合适，只有对错。

所以大家要在职场中审视下，哪些人是管理成本高的人呢？

比如：

• 同样一件事老板和你聊得时间最长，你可能是这个管理成本高的人；

• 同样一件事老板和你聊得重复次数最多，你可能是这个管理成本最高的人；

• 团队里面喜欢吵架的人，可能是这个管理成本最高的人；

• 团队里面遇到问题往往急于回答，而不深度去系统思考的人，可能是管理成本最高的人；

• 那些每次讨论问题，在心里总是首先想证明自己是对的人，往往是管理成本最高的人；