【51CTO独家特稿】一个合格的程序员，应该重视Bug，并在实际项目开发过程中，有效地规避这些Bug，当然也要分情况。有些Bug，在有些情况下建议不要做太严格的规避，否则的话，可能会对整个项目的开发进程产生严重的阻碍。个人的开发实践证明，很多项目不是设计死的，而是被测试人员测死的，如果您也有同样的感触，那么，我相信下面的一些观念，会对您的代码生涯产生一定的影响……
什么是Bug？通俗地讲就是程序项目开发过程中出现的一些影响项目正常运转的那些部分。比如：错误的逻辑关系处理，不正常的参数获取方式，数据库查询不合理导致您变成一个职业的数据库杀手，以及用户体验不太好等等。这些Bug，有主次轻重之分，在实际项目开发过程中，有些必须规避，有些可以在前期适当放宽要求。当然也要看具体的项目用途，本文中主要以PHP项目开发来举例。
一、界面类
如果是Web站点，作为商业用途，那么界面不达标，即不能达到大器具有足够的商业气息，不能在一定程度上体现这个站点的商业特点的界面，公司的项目负责人根本就不应该审 批通过。不要认为界面还可以再加工再改版，一个好的界面，应该在用户脑海中停留足够的时间，而不应该三两个月就动一次大手术。
界面是Web站点吸引眼球的第一要求，虽然我们通常说Web站点内容为王，但是一个好的界面能使用户留下好的印象，为什么我们不做的更好呢？对于界面，我的理念一直是：“我们不渴求完美，但是我们要尽量追求完美”。 同时要兼顾项目进度，项目负责人要把项目用途及特点充分地讲解给设计师，并提供足够的资料供其使用和参考，之后不加干涉，让其用心发挥。一般有经验的设计师，只要能充分地理解这个项目，设计出来的界面都不会太差。
二、功能类
功能是一个项目的核心。因此，功能逻辑我们一般来讲是不允许有便差的。尤其是核心逻辑，比如设计到资金运转的，务必不能出现差错。还要建立足够的备份机制。程序设计上我们建议，独立的功能务必合理封装，以便于将来维护。同时，写清楚注释，否则，当封装的内容多了，三两天之后，可能你自己都看不懂自己写的是什么。这已经被无数次地验证。因此对于复杂的功能，我们必须添加注释。不加注释严重来讲不能算Bug，但实际上它在项目维护的时候，比有些Bug更要你的命。
关于功能类的Bug，我们还要特别注意，不要使用未经安全验证的插件。比如，封装不好的数据库操作类，后台使用的存在可攻击漏洞的多功能编辑器，以及封装不好的或完全未封装的上传类等等。有些插件本身有Bug，如果你用了，就等于你写的程序一样有Bug，而且还很要命，尤其是用了一些开源的插件，如果它的Bug未修复，你的程序可能在一夜之间全部变成废品。因此，我们要慎用开源插件。
三、数据处理类
数据处理类最常见的是数据有效性检测不合理，这个问题在初学编程的程序员身上最为突出。比如POST或GET方式接收的参数，不经过滤就接收使用。这有可能对数据库造成致命伤害，进而影响到服务器的安全。 说白了就是出现SQL注入的漏洞。如果您是初学者，不清楚SQL注入，建议您赶紧搜索点资料研究一下。否则您写的代码可能一直都站在悬崖边上，随时有粉身碎骨的可能。第二种情况是虽然过滤了，但是不判断，程序员往往在写 程序的时候，都会自己简单测试。但是这种测试是站在一个正常思维的角度去测试的。
比如，你要发表一篇文章，你肯定会填写一些内容然后再点提交，但是我们就 是有用户，他不填内容就点击提交。如果你不判断提交的内容是否为空就直接向数据库中插入一行记录，那不仅仅是浪费数据库资源，更重要的是读出来显示给用户 看的时候，你可能还纳闷，为什么不显示内容，还以为自己的显示处理代码有Bug，因此，很多程序是相互依赖的，如果你能在重要的地方处理好，就可以在另外一个地方少些判断少些处理。反而可以提高程序性能。虽然某些性能看起来微乎其微，但是我们顺手牵羊，提高一点总比没有好。
四、提示信息
关于提示，我们这里主要说两点：
其一、很多程序员喜欢复制粘贴自己前面写的提示信息的代码（因为提示信息一般是封装好的一个方法），特别是类似的功能提示。 这样一来，经常造成一些不合理的提示出现。比如你在在删除失败的时候，复制了一份删除成功的提示，那么巧了，如果你删除的时候，传的参数处理存在Bug，可能你每次点删除按扭的时候，系统都提示你删除成功，其实这时是不成功的。有时候你写代码可能就是把脑代给写昏了，说不定你反复点来点去，一直认为是程序有数据处理的Bug，而实际上仅仅是一个提示错误而已。白白浪费你太多时间。
其二、建议Web程序多留些旁注，简单明了地告诉用户当前位置的操作方法。不加旁注，不是一种Bug， 但是它可以有效地规避由于用户操作不合理而给公司或者你个人带来极大的维护成本。如果你在写程序的时候，在每一个用户的关键操作点，都有旁注，相信你平时的麻烦事应该很少。喜欢加旁注的人，曾经一定有类似的伤心史。所以他长教训了：“我让你还不断地问！我哪有那么多精力解答你！”
五、性能类
谈到性能类，建议不同的项目区别对待，小项目有小项目的做法，大项目有大项目的做法，不同的项目在不同的阶段，针对性能设计也要区别对待，不建议一视同仁。如果是个小项目，日访问量不足百十来个IP，你也去做什么静态化处理，启用海量数据处理方案，搞复杂的服务器组织结构，那真是：“自作孽，不可活”呀。我曾经经手过一个Web站，本来访问量每天几百个不得了，有时候不足几十个，结果想了一大堆方案，预想着网站马上会有一堆流量。结果，流量没上来，项目搞了半年还说不合理，承受不了大的访问量，天天又纠结一些几乎不会出现既便是出现了也不会对站点造成什么影响的Bug。最后商机慢慢也没了，烧了几百万，换了几张空页面。股东吓的纷纷撤股。真可谓，有钱没地方使。
另外补充一点，给项目负责人看：项目的不同时期要把握好项目的进度，对测试人员也要有不同的要求，不要为了一味的排除所谓的Bug，而把项目做死了。再补充一点，给开发人员看，闲的时候，多找些程序优化的知识看看，多总结一些常见的Bug解决方法。在实际的项目开发过程中，自己知道的Bug处理方法尽量全部用上，至少在个人知识层面上不要出现Bug，这不仅是一种工作的态度，最重要的是对整个项目负责。经验多了，Bug会越来越少，重点就可以集中在逻辑功能的处理上，才可以使你的代码质量越来越高。
最后一条，老生常谈：我们做程序，要把用户当傻瓜，虽然不中听，但是确实是一条人间正道！
【51CTO独家特稿，转载请标明出处及作者！】
【编辑推荐】
