怎样写出无BUG的代码？

充分理解

理解业务逻辑

存在即合理。乍一看不合理的逻辑，既然存在，一定有其历史原因。修改的前提是理解它怎样来的。

理解技术原理

基本类型的数据，比如int是可以直接==来判断相等的。但是如果两个数据都是Integer类型，再用==就会出bug了。值比较和对象地址比较的区别。这是一个技术原理上如果认知不清可能会引起bug的简单例子。

作为代码评审的人，可以事先定好规矩：如果评审过程中发现代码编写者不清楚自己写的逻辑、对原理不清楚，可以将代码打回。

理解数据

理解每张表、每个数据库字段。包括其他存储，比如redis、kafka里存的数据。我在做代码审查时，不仅会审查代码，还会去看数据库、redis、kafka里实际存储的数据。可能会发现意想不到的问题，比如功能看起来正常，但是数据库里有几列都是空的；redis里因为存储的类型不合理，数据占用空间大。

做好设计

本周我成功做了一个设计，将两个优化迭代的大需求分解成前端做大部分的处理，后端仅仅增加一个搜索接口。

第一个功能涉及复制，第二个功能涉及excel的上传和下载。我调研了前端技术，首先确认前端实现上没有任何问题。

在前端、后端谁做，都能实现效果的前提下，从合理性上：复制、上传和下载本质上是展示形式的改变，前端作为视觉展示层，这些放在前端是符合其定位的。

道理是道理，前端固有的模式是把这些都放到后端。跟前端沟通时，我首先从上面提到的技术实现和合理性上做分析。我做好了兜底方案：如果前端有些其他的考虑，那我要充分去思考其合理性。以最终最优的方案为目标。如果前端因为目前的基础设施不完善不太想做。我可以在前端代码里替他们开发。时间长了，清晰分层的优势无论前端后端都能享受到。

控制好修改范围

如果是新项目上线，上线后有段时间没有业务，影响是可控的。针对已经有业务在运行的修改要格外小心。修改通用接口等情况可能会造成影响范围扩大，那这时候测试也要覆盖到。而不是局限于需求说明书上的内容。完善的单元测试和回归用例集成测试是确保修改符合预期的有效手段。

善于使用工具

对象之间的转换，传统方法是一顿get、set，这样一旦有改变，有可能漏改。后来大家开始使用基于反射的BeanUtils方法进行拷贝，但是效率低，现在流行的是MapStruct这种编译方法的实现来解决。

AI代码工具，我之前尝试用过idea自带的AI助手和一些收费的工具，最终选择免费的通义灵码。它目前更新比较快，会经常被提示更新重启。总体而言比较适配国内的开发者。

灵魂拷问

你对上线是否有信心？这个灵魂拷问实际上是对前面所提到所有内容的一个综合自我测评。另外，编码时的精神状态，测试充分性都能体现在自我信心上，所以上线前一定要听听内心的声音。

对一个程序员来说，最宝贵的品质不是渴望成功，而是害怕失败。在此基础之上，当然最好有自己的想法。比如我的想法是不要去替代谁，而是创造更多。所以我选择用户增长的领域，因为在这个时代想要获取一份工作的同时，不让另外一个人丢掉饭碗，就是要发挥自身的创造性，不断开拓。但不管怎样，第一步是要把代码写好，获得信任，才有资格去承担更多。