如何降低BUG率

又是一个1024，照例写一篇博客，不同之处是，今年已经完全步入社会了。

工作半年多了，在一家互联网外企，英文文档环境和中文交流环境，写Golang代码。虽然是一家不太卷的互联网公司，但是依然感受到互联网的累，工作比较饱和，基本上一天到晚都在跟进不同的事情，没什么时间关注微信消息和新闻八卦，不忙的时候七点多下班，约约会什么的，忙的时候也是晚上十点多下班，回到家洗漱完就得迎接新的一天的挑战了。

程序员税后到手工资大概只有工资的2/3，工作半年多没什么时间跑步健身打球游泳，明显感觉到自己体质下降了，社交圈子也在收敛，从刚毕业一个月和同学们聚餐，到现在一个多月不和同学发微信，我还算比较幸运的，有些同学遭遇了裁员。外行只看到程序员较高的薪资，看不到程序员只是农民工的这一事实，这是这类农民工，需要更高的学历，更多的知识储备，更快的知识搜集能力，更快的学习能力和更好的适应性。

图一：令人气抖冷的知乎问题

图二：令人扎心的官方报告

图三：好有道理哦，码农要自信，你是软件工程师

玩归玩闹归闹，BUG来了逃不掉，轮到自己了就得24小时 on call.

没工作前，总以为厉害的程序员是能把微服务、分布式系统架构讲的清楚明白的人
刚工作后，认为厉害的程序员是能够在写好需求之余，能够做好一些中间件和技术分享的人
工作半年后，才发现能写出规范的代码，不出bug，后人维护和迭代容易，就已经是厉害的程序员了，顺带能够做好技术方案，画好架构图、画好各种UML图，讲清楚自己的方案，就是有真功夫

梦想还是要有的，要是梦都不敢做，还能成得了什么大事！ （院士语录）
仰望星空脚踏实地，既要敢想敢做，在自己擅长的领域变得更强，又要写好每一行代码，希望下一个1024的自己能看到过去一年自己走过的路和自己的成长。

关于如何降低BUG率：
虽然感到成长不多，但是多少还是有一些经验的：

1. 如果写出的代码不好写单元测试，那一定是代码没组织好
2. 没经过充分自测的代码，一定会被测试人员测出BUG，所以要有足够多的时间自测
3. 自己多Review一下自己的代码，还是很容易及早发现问题和不合理之处的
4. 做技术方案时要有主见，不然最后发现在大佬们的来回battle之后，你改来改去的方案，最终版本和你最初的没啥不一样
5. 写好文档和写好代码一样重要，前者是当下，后者是之前和未来
6. Git代码分支管理，要多拉中间分支来隔离代码，避免不同分支的代码相互污染
7. merge request 是很好的Code Review时机，多多利用，多拉上大佬一起看看代码
8. 沟通要主动积极，事前多沟通，事后少背锅，如果对方觉得你打扰了他，那多半是他的耐心问题
9. Goland 里的 Linter用起来，把命名不规范、拼写错误、过于复杂的函数扼杀在摇篮里
10. 多总结多复盘，要相信自己有无限可能