面对Bug,程序员何去何从?

发表于:2011-6-22 10:53

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:抚琴煮酒    来源:51Testing软件测试网采编

  一个合格的程序员,应该重视Bug,并在实际项目开发过程中,有效地规避这些Bug,当然也要分情况。有些Bug,在有些情况下建议不要做太严格的规避,否则的话,可能会对整个项目的开发进程产生严重的阻碍。个人的开发实践证明,很多项目不是设计死的,而是被测试人员测死的,如果您也有同样的感触,那么,我相信下面的一些观念,会对您的代码生涯产生一定的影响……

  什么是Bug?通俗地讲就是程序项目开发过程中出现的一些影响项目正常运转的那些部分。比如:错误的逻辑关系处理,不正常的参数获取方式,数据库查询不合理导致您变成一个职业的数据库杀手,以及用户体验不太好等等。这些Bug,有主次轻重之分,在实际项目开发过程中,有些必须规避,有些可以在前期适当放宽要求。当然也要看具体的项目用途,本文中主要以PHP项目开发来举例。

  一、界面类

  如果是Web站点,作为商业用途,那么界面不达标,即不能达到大器具有足够的商业气息,不能在一定程度上体现这个站点的商业特点的界面,公司的项目负责人根本就不应该审 批通过。不要认为界面还可以再加工再改版,一个好的界面,应该在用户脑海中停留足够的时间,而不应该三两个月就动一次大手术。

  界面是Web站点吸引眼球的第一要求,虽然我们通常说Web站点内容为王,但是一个好的界面能使用户留下好的印象,为什么我们不做的更好呢?对于界面,我的理念一直是:“我们不渴求完美,但是我们要尽量追求完美”。 同时要兼顾项目进度,项目负责人要把项目用途及特点充分地讲解给设计师,并提供足够的资料供其使用和参考,之后不加干涉,让其用心发挥。一般有经验的设计师,只要能充分地理解这个项目,设计出来的界面都不会太差。

  二、功能类

  功能是一个项目的核心。因此,功能逻辑我们一般来讲是不允许有便差的。尤其是核心逻辑,比如设计到资金运转的,务必不能出现差错。还要建立足够的备份机制。程序设计上我们建议,独立的功能务必合理封装,以便于将来维护。同时,写清楚注释,否则,当封装的内容多了,三两天之后,可能你自己都看不懂自己写的是什么。这已经被无数次地验证。因此对于复杂的功能,我们必须添加注释。不加注释严重来讲不能算Bug,但实际上它在项目维护的时候,比有些Bug更要你的命。

  关于功能类的Bug,我们还要特别注意,不要使用未经安全验证的插件。比如,封装不好的数据库操作类,后台使用的存在可攻击漏洞的多功能编辑器,以及封装不好的或完全未封装的上传类等等。有些插件本身有Bug,如果你用了,就等于你写的程序一样有Bug,而且还很要命,尤其是用了一些开源的插件,如果它的Bug未修复,你的程序可能在一夜之间全部变成废品。因此,我们要慎用开源插件。

  三、数据处理类

  数据处理类最常见的是数据有效性检测不合理,这个问题在初学编程的程序员身上最为突出。比如POST或GET方式接收的参数,不经过滤就接收使用。这有可能对数据库造成致命伤害,进而影响到服务器的安全。说白了就是出现SQL注入的漏洞。如果您是初学者,不清楚SQL注入,建议您赶紧搜索点资料研究一下。否则您写的代码可能一直都站在悬崖边上,随时有粉身碎骨的可能。第二种情况是虽然过滤了,但是不判断,程序员往往在写 程序的时候,都会自己简单测试。但是这种测试是站在一个正常思维的角度去测试的。

  比如,你要发表一篇文章,你肯定会填写一些内容然后再点提交,但是我们就 是有用户,他不填内容就点击提交。如果你不判断提交的内容是否为空就直接向数据库中插入一行记录,那不仅仅是浪费数据库资源,更重要的是读出来显示给用户 看的时候,你可能还纳闷,为什么不显示内容,还以为自己的显示处理代码有Bug,因此,很多程序是相互依赖的,如果你能在重要的地方处理好,就可以在另外一个地方少些判断少些处理。反而可以提高程序性能。虽然某些性能看起来微乎其微,但是我们顺手牵羊,提高一点总比没有好。

21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号