#代码规范

在编码实现一个功能时，发现有一个逻辑如果按照全面去考虑的话需要改动很多地方，甚至可能要推翻当前已经写过的部分代码，但是呢现在实际场景并没那么多，当前的实现已经能满足。算了，先这样吧，后续业务怎么发展还不知道呢，到时候再说。

不知道在看这篇文章的程序员伙计们平时是如何写代码的？有参照什么原则吗？还是说写到哪算哪？

我相信每一位程序员最怕遇到代码质量堪忧的项目，毕竟增加一个同样的功能，在一个代码整洁、清晰的项目里与在一个代码混乱不堪的项目里，效率和质量上的差距达到一个数量级一点也不奇怪。

在大家都认为越来越内卷的当下，注重和提升代码质量我认为是每个程序员的必修课。说的严重一些，它影响了你在团队中的价值，说的表面一些，它是你在团队中的“面子”。

所以，很多人没有把单元测试当作一个“工具”，而把它看作是一种“负担”。 在这种心态下，就算要写单元测试，也是为了写而写。更可怕的是，通过mock工具，还真能给任意代码写单元测试。

应该有不少程序员受过这样的困扰，特别是做后端的。项目一直在持续不断的迭代，但是呢老版本的代码还不能直接删掉，因为不一定所有的调用端都能在同一时间点完成升级。你是怎么处理这种情况的呢？

你写的系统错误提示形同虚设？试试这4个方法。

一、背景 随着公司的业务发展，项目越来越多，越来越大，复杂性也越来越高。查找一个BUG变得越发抓狂；新人熟 […]