点击上面↑「爱开发」关注我们
张工是一名java程序员，有次，客户反馈了一个紧急问题，张工一接到任务立马开始排查bug，费了九牛二虎之力终于定位到问题所在，最后张工修改了5行代码，bug解决了。
张工伸了一下懒腰，这时候财务妹子过来找张工确认上次报销的事情，见张工懒洋洋的。
“不是吧，你今天又只改几行代码，你们做的软件时不时出现这样那样的问题，工资还那么高。你看看我，我今天都做了两张报表，连去趟茶水间倒杯开水都得一路小跑，真羡慕你们。”
张工一时竟无言以对。
bug对于开发者来说并不陌生。改5行代码，表面看似轻松，背后一直在超负荷运转，所隐含的艰辛没有经历过是难以体会的。
作为一名软件开发人员，在开发软件时，虽然我们一直小心翼翼地编写代码，可做出来的软件还是会出现这样那样的问题，为什么会这样的，首先我们来看看什么是bug。
什么是Bug
有人对bug作了这样形象的比喻：你家里的窗可以从外面打开，那叫漏洞。你家里的窗打不开，那叫bug。
但不得不承认，bug是必然存在的，好比人为什么会感冒。
我们来看bug是一般如何出现的。
开发人员和产品经理讨论需求时，双方需求沟通不到位
沟通本身是一个有损耗的过程，即使在沟通的过程中，产品经理针对需求讲了很多，可到了实际开发的时候开发人员还是需要查看需求原型、需求文档，重新梳理需求。这时候要是出现需求模糊的又没有经过确认的，可能做出来的软件会导致更多的业务逻辑问题和更多的bug。
这只是产生bug的其中一种，可以说，每一位开发人员背后都是踩着无数的bug一路走过来的。编码是一个主观的，完全由人主观掌控的事情。可能你会说，不是有软件测试人员吗？测试的工作不就是通过逆向思维来给程序员查缺补漏吗？确实是的，但测试人员的介入只是降低了软件出现问题的错误率，并不能彻底消除bug。其实每个每个系统都有bug，只是有些bug没有被执行到而已。
既然bug无法避免，那么对于bug，我们是不是就束手无策，拿它没有办法呢？办法还是有的。
首先我们最容易想到的一点是，增加软件测试人员。多一人多一份力量，确实，但也因此增加了企业用人成本。
其次就是招聘一些经验丰富的开发人员，这样也可以避免产生一些低级bug，代码逻辑严谨，系统稳定性强。这样确实可以减少一些明显bug，但bug还是无法避免。
最重要的是如何让解决bug的这个过程更加快速。
解决bug主要做两件事情：
定位bug的产生原因
修复bug
作为一名软件开发人员应该接触不少bug，找bug是最耗时间的，特别是一些难以重现的bug。那么有没有一些方法帮助我们定位bug呢，答案是肯定的。我们可以尝试从下面几点入手。
日志管理
系统日志记录着我们认为容易出现问题的地方所产生的信息。但系统无时无刻都在运行着，必然会产生大量的日志信息，如何从这些信息中快速的找到关键信息，就是需要考虑的问题。我们可以给日志做一下归类，定义不同的日志级别，在记录的时候带上前缀。譬如【info】、【warning】、【error】之类，对于error级别的信息自然是我们重视的，由于将其他级别的信息剔除掉，使得数据量减少，缩小排查的范围，更加便于排查问题。
日志规范
团队中，要是每个人都用自己喜欢的记录日志的方式，没有统一规范，那么从日志中找你需要的信息就变得很头疼。所以，要做好打日志这个事情，统一一个规范很有必要，比如日志有时间，当前上下文的参数等。
注重编码规范
类似这样的经历或许你也有过：
回头看看自己一年前编写的代码，惊讶地发现，哇哈，如此不规范的代码，是谁编写的？确定是我写的吗？我能写出这样惨目忍睹的代码？分分钟钟怀疑人生。
代码规范的重要性我们都知道，但要真正做好，还需要我们在实践中慢慢的累积，不断修炼。那些看似无用的东西要经过我们慢慢地累积由量变达到质变的时候，相信你能体会到其价值所在。
养成良好的代码规范不是为了别人，也不是为了公司，而是为了提高自己的编程修养，提高自己认识事物的能力。让自己编写的代码可维护性更好、可重用性和可扩展性更强。
规范的代码可以帮助快速调试程序，快速检查找到问题所在，节省时间。养成一种好习惯，添加注释。
有网友倜傥：程序员喜欢两件事：
喜欢说别人程序不写注释；
喜欢自己在程序中不加注释。
注释的目的不是为了解释代码做什么——可以读取代码!注释目的是为了解释当你写代码的时候是如何思考的。
在编写完代码两三个月后，可能我们已经不记得上述任何问题的答案，所以，写下来很有必要的，能为我们后面解决bug提供了重要的线索。
重视沟通
职场里，有的开发人员在任务进展过程中不重视沟通，认为我只要最后把任务完成了就好了，结果往往需要项目负责人或上级主管问起来时才想起来汇报进展；更糟糕的情况是在开发过程中遇到了问题，没有主动沟通，而是等到别人问起来了才说出来目前遇到的困难。
这样会给别人造成极大的困扰和担心：如果我没有问，那么这个问题是不是就卡在这里？项目进度是不是就延期了。
职场上，对你的职场形象造成负面影响的其实并不是事情没有按期达成，因为有时候确实有一些因素会导致事情无法正常完成，而危害最大的是你没有及时沟通问题，造成问题的搁浅和发酵，最终造成的结果与预期不符；这会给团队带来不必要的麻烦：出现问题为什么不及早反馈沟通？
你遇到的问题，或者团队中已经有人解决了。因此，我们需要意识到定期沟通的机制对于跟进效果是一个重要的指标；那么如何搭建一个好的沟通机制呢？在这里给大家推荐一个SMART模型。
S代表的是Specific:沟通内容要具体
M代表的是Measurable：衡量指标要量化
A代表的是Achievable：目标制定要实际
R代表的是Relevant：个人的目标要与团队目标一致；团队的目标要与公司战略一致。
T代表的是Time：完成工作需要的时间，预计达成结果的时间
编码只是开发人员工作的一部分，团队之间的沟通也不容忽视，沟通清楚了，需求理清了，避免一些业务逻辑因为没有理解需求而产生bug。
【END】
往期精选推荐
更关注精彩内容，请长按识别关注
点下面[在看]就是最好的支持
