刚工作那几年，我也特别关注各种编码规范。
比如驼峰命名、方法不要太长、少写 if else、多写注释，这些我现在也一直在做。
不过，写了十几年代码以后，我发现真正影响代码质量的，并不是这些，而是一些思考习惯。
下面几个习惯，我基本每天都在用。
第一，需求评审结束后，我先想的不是怎么实现，而是有哪些非功能性的场景。
刚开始工作的时候，一个需求评审结束，我脑子里想的是：
- 这个功能怎么写？
- 数据库怎么设计？
- 接口怎么定义？
现在完全不一样了。现在评审一结束，我脑子里先过一遍的是：
- 异常场景有哪些？
- 边界数据有没有考虑？
- 重复提交怎么办？
- 并发会不会有问题？
- 流量突然涨几倍怎么办？
- 第三方接口超时怎么办？
- Redis 不可用怎么办？
- MQ 投递失败怎么办？
- 降级策略是什么?
这些东西，需求文档里通常都不会写。但真正上线以后，很多线上故障，恰恰都是这些地方出了问题。
这些年经历过太多线上故障以后，会觉得，真正难的，从来不是把功能做出来，而是让它在各种异常情况下还能正常运行。
你不能说，一遇到异常场景，代码直接撂挑子不干了。
所以现在每接一个需求，我都会花不少时间把这些场景想一遍。
你可能会认为，有必要吗? 那我只能说，当你跟我一样，十几年来遇到N多个大小故障后，也会跟我一样的想法的。
我也始终认为，我上面说到的，是一个高级程序员应该具备的习惯。
第二，我希望代码体现的是业务流程，而不是实现细节。
我不太喜欢点进一个方法，就是上百行代码。
我更希望别人点进来，第一眼看到的是业务流程。
例如：
createOrder() {
validate();
calculatePrice();
lockStock();
createOrder();
sendMessage();
}
整个流程一眼就能看懂。真正的业务实现，都放到对应的方法里面。
这样做有一个很大的好处。以后需求变更的时候，只需要找到对应那个业务步骤修改。
其他步骤基本不用动。业务流程一直保持稳定。
代码首先应该表达业务，其次才是表达实现。
如果别人打开你的代码，看两分钟还不知道整个流程在干什么，那这段代码大概率还有优化空间。
第三，设计优先，而不是编码优先。
以前写代码，我也是打开 IDE 就开始写。
现在我不会了。现在一个需求下来，我会先花时间思考。那思考什么呢?
- 一个是我上面提到的非功能性场景；
- 一个也是我上面提到的代码清晰度；
- 一个是写「结构化」的代码， 其他同事需要改代码，按照固定的结构改；
- 最后是复用；
我都是想的非常清楚后，才开始写代码的。现在有 AI 以后，我就更加推崇这种方式了。
我现在基本都是规格驱动开发（Spec Driven Development）。很多时候，我会花几个小时去写一份 Spec。Spec 写完以后，再交给 AI 生成代码。
很多人觉得，写 Spec 是在浪费时间。我正好相反。我觉得，**写 Spec 的过程，其实就是思考的过程。**很多设计问题、边界问题、异常场景，都是在写 Spec 的时候发现的。
等 Spec 写完以后，代码反而只是最后一步。我基本都是一次性就生成高质量的代码的，一次过的，爽的很。
小结一下：
如果你想成为一个专业的，在外人看起来是一个靠谱的高级程序员。那么我是建议可以参考上面的做法。
程序员和程序员之间，其实拉开差距的，就是上面那几点。
