如果是让当前的我来排的话，是两个，一个是稳定性，另外一个是清晰度。

其中代码稳定性是排第一的，知道为啥吗？

因为那是IT团队保命用的。

这些年，见过太多太多人因为IT故障而不得不走，也见过太多太多因为故障，整体IT部门的绩效被打得很低很低。

因为故障走的角色，大的有CTO、技术总监，中间有技术经理、技术组长，小的就是普通程序员。

而技术管理者一走，新的管理者入职，往往又会带来一波团队调整，甚至离职潮。

所以，在真实的软件开发里，稳定性永远是最重要的。

但是我这里说的稳定性，不是说：那段代码能跑就行，别动它。

而是你应该通过各种技术手段去保证系统长期稳定运行。

比如：

• 好的架构设计；
• 降级；
• 异常处理；
• 告警；
• 限流；
• 熔断；
• 超时控制；
• 灰度发布；
• 自动化测试；
• …

这些能力，很多在平时，的确感知不到价值。但真正线上出一次故障，你就知道它们为什么存在了。

而排第二的是，清晰度。什么叫代码的清晰度呢？

我引用一下软件开发方法学大师 Kent Beck 提供的一个例子：

input(); process(); output();

就这么简单。别人打开你的代码，不需要猜，就知道程序的关键流程是什么。

我一直觉得，作为程序员，应该以能写出清晰的代码为傲。因为它不仅对自己有利，对团队也有利。三个月后你回来改代码，最感谢的就是当初那个写得清晰的自己。新人接手，也不用一边看代码，一边猜作者当时到底在想什么。

但是呢，写清晰的代码，跟会不会设计模式，并没有直接关系。

真正决定代码是否清晰的，我个人觉得更多是下面四件事：

• 封装；
• 组合；
• 分离关注点；
• 控制复杂度。

把这四件事做好，代码自然就会越来越清晰。

反过来，如果一个方法几百行，一个类承担五六种职责，到处都是 if-else，变量名含糊不清，即使把二十多个设计模式都用上，代码也不会好到哪里去。

所以，你就记住两点：

第一，保证系统稳定。

第二，让代码容易理解。

前者决定系统能不能长期稳定地运行，后者决定团队能不能长期维护下去。

至于设计模式、DDD、微服务、各种架构思想，我现在更愿意把它们看成实现这两个目标的工具，而不是程序设计本身。真正的程序设计，而是为了让软件能够稳定运行，并且让后来的人愿意继续维护它。

好，结尾的话，我来一个金句：

稳定性是保命的，清晰度是续命的。