时间：2021-07-01 10:21:17 帮助过：5人阅读
在写程序的时候总有思考不周全的时候,
所以程序就充斥这各种各样的bug
有些特别显而易见
有些隐藏的特别深
所以就想问一下各位同仁
怎么样才能减少自己的bug率
或者说需要怎么锻炼呢?
有这方面的兄弟们请提供帮助
可以是文章,视频,书籍!
小弟谢谢各位了!
通读《重构》和《代码简洁之道》
在我加入贝尔实验室一年多后，我开始和 Ken Thompson 一起在开发一个针对由 Gerard Holzmann 设计的很小的图形化交换语言的即时编译器上做结对编程。我打字比较快，所以我坐在电脑前，Ken 站在我身后看我编程。我们开发的很快，但经常会遇到问题，而且可以看出来出错了 —— 毕竟这是一个图形化的编程语言。当程序出错时，我本能的一头扎进问题，检查报错跟踪信息，添加调试打印语句，启动调试器，等等，但 Ken 只是站在那思考，完全不理会我也不查看我们写的出问题的代码。一段时间后我发现一个规律，Ken 经常会比我先找到问题出在什么地方，而且会突然的喊一嗓子，“我知道什么地方的问题了。”每次他的判断都很准确。我认识到，Ken 已经在脑海里构建了代码的模型，当有问题出现时，那是他脑子里的模型出了问题。在思考为什么会发生这些错误时，他能凭直觉找到模型中什么地方不对或发现写的代码跟这个模式什么地方有出入。Ken 教会了我一个极其重要的习惯：纠错前先思考。如果你一头扎进问题中，你可能只解决了当前出现问题的代码，但如果你先思考这个错误，这个 bug 是怎么引入的？你通常发现和纠正一个更高层次的问题，进而改进了系统设计，防止了更多 bug 的出现。我认识到这种编程思考模式非常的重要。有些人痴迷于一行行的、使用各种工具来调试所有的东西。但我现在相信，思考 —— 不看代码的思考 —— 是最好的调试途径，因为它能让你开发出更好的软件。
降低自己工作的复杂度
比如合理划分代码结构, 不写巨大函数和类
引入帮助发现错误的措施
比如加断言, 写单元测试
提倡复用代码, 少写点然后多次使用 (不是code golf那种少写)
测试，测试，测试
在下手写代码实现功能之前，先考虑下测试用例。实现功能以后完成测试用例。
尊重你的QA同事，他们是质量保证。
最后一点，bug始终伴随着程序员，只不过从低级bug 到高级bug的区别。
一个前辈提醒过我的一句话：“永远不要相信你修改的BUG是最后一个BUG”...
宁可多写几行代码，也要逻辑清晰代码易读，不到迫不得已不要做牺牲逻辑和易读的性能优化。
重构和测试很重要
运行前再看一遍
技术到位了就少了
多写单元测试
养成写单元测试的习惯 可以看看测试方面的书
一般是多测试才能发现问题，不管是单元测试还是完整的黑盒测试。
BUG是在所难免的，没有哪个APP没有BUG，只是有些BUG隐藏得比较深而已，有BUG咱改就是，debug工具推荐云手机。。。
思考的时间多一些，写代码的时间少一些。
测试，最好养成代码review的习惯
理清需求，先想后做。
尽量不造轮子。
增量重构。
设计模式。
单元测试。
比较复杂的逻辑一般我都会先写注释，理思路，理清楚了再开始敲代码，敲完代码再测试。
少点
重构，重构，再重构。。一步一步修改优化。。别无他法。
不要在正式项目中造轮子，造轮子，造轮子。
不要过早的深入细节。
先写伪代码，伪代码逻辑没问题了再写代码