把系统写简单一点

看到新框架、新架构，总会有一点想试的心情。写系统的人大概都懂：明明手头的做法也能用，还是忍不住想，换成那个会不会更漂亮。

问题在于，想试和需要，是两回事。

多拆一个服务、多加一层抽象时，理由往往很充分：方便扩展，降低耦合，为以后留余地。可如果追问以后究竟会怎样变化，自己又说不太清楚。此时做的设计，有多少是为眼前的问题，又有多少是怕方案看起来不够周全？

我也会有这种顾虑。简单的实现摆在那里，很容易让人觉得没费什么功夫；复杂的图画满一页，反倒显得考虑得多。但系统上线以后，图有多漂亮就不重要了。出问题时能不能查清楚，新同事能不能接着改，这些才会天天遇到。

先看看不加会怎样

现在遇到拿不准的设计，我会先想不做它会有什么后果。如果现有实现已经能满足需求，也没看到具体的风险，就不急着增加一套机制。

“以后可能用上”并不是毫无道理，只是可能性太多，没法每一种都提前准备。新代码一写出来，就得维护、测试，还得让别人理解。哪怕后来一次也没用过，这些事也省不了。

拿不准时，我更愿意选直接一点的实现，把边界说明白。等需求真的出现，手上的信息通常比现在多。到时再改也有成本，但至少知道自己为什么改，不是在替一个猜来的需求花力气。

省掉的不能是必要的部分

简单也有做过头的时候。把错误处理删了，把数据校验省了，或者为了少几个文件把所有事情挤在一起，眼下看着短，出了问题会更麻烦。

所以我说的简单，主要是让一件事有一条清楚的实现路径。函数名能说明用途，调用关系不绕，出了错有地方查。团队里刚接触项目的人，不用先听一整套设计哲学，才能改一个小功能。

这件事没有一个到处适用的标准。我能做的，是在每次增加东西之前多问一句，在维护变得费劲时愿意回头删。能少解释一层，就先少解释一层。