张工是一名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。
责任编辑:Rex_08