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