实战乃王道C-C++开发常见bug解析.doc

[技术门诊第132期] 实战乃王道：C/C++开发常见bug解析 程序员是个很辛苦的职业，通常面临无穷无尽的加班，但经过分析发现，大多数加班并不是因为项目时间不够，而是前期开发没有设计好，后期出现了无法跟踪，甚至无法解决的bug，导致研发时间不可控，这就是通常所说的“bug是加班之源”。因此，我们如果能在设计阶段，预防、暴露很多bug，将大大减轻程序员的压力，使开发工作变得很愉快！ 技术门诊是51CTO社区品牌栏目，每周邀请一位客座专家，为广大技术网友解答疑问。从热门技术到前沿知识，从技术答疑到职业规划。每期一个主题，站在最新最热的技术前沿为你引航！ 本期技术门诊我们邀请到软件研发和管理领域专家、IT图书作者肖舸专家与大家讨论C/C++开发中的常见bug的解决方法。 本期专家：肖舸 擅长领域：C/C++，商用数据传输 专家简介：普罗通信（西安）有限公司研发主任，MCSE，商用程序员。拥有多年的软件研发和研发管理经验。精通C/C++，TCP/IP，擅长分布式数据库、服务器集群以及并行计算领域的研发。曾担任西南交大客座讲师，讲授《C/C++语言无错化程序设计》课程。曾在多家企业担任项目经理，负责过的项目有《http tunnel防火墙隧道穿越系统》、《freepp V1.5 服务器集群》、《电子白板子系统》等。 著有《0 Bug ---- C/C++商用工程之道》。 查看本期门诊精彩实录：/develop-144.html 参与最新技术门诊：/ 精选本期网友提问与专家解答，以供网友学习参考。 Q： A： Q： A： 英语发展到今天，其实已经不完全是英国人的英文了，其实世界各地的人们在使用英文过程中，其实都在按照自己本民族，本文化的习惯在修改英文。比如“颜色”这个词，colour，但是美国人嫌麻烦，就是不想写那个u，因此，慢慢地，这个词被修改为“color”了，最后英文本身也不得不认可这种修改。这中间例子还很多，比如“PK”，比如“VS”，都是人们在使用过程中，对英文的修订。这说明了语言一个很重要的特性，没有权威，用得人多了，自然就成了权威。 因此，学习英文要注意“方言”，前段时间说中国人将会为英文贡献一些中国式英语，我觉得不难理解，也无可厚非，反正大多数人都这么用的话，就是对的。 你说的问题，可以理解为程序员的一种方言，程序员是很喜欢用缩写的，并且不是很讲究自然语法，开发英文更是不会去管时态等修饰变化，这些都是程序员特点，如果大家约定俗成，这么写也是无所谓，反正写的人和看得人都明白就好了。 不过，我个人还是喜欢使用create。呵呵。 Q： A：sorry，你这个问题问得没头没尾的，我无法回答。 请问你在为什么系统写插件？PhotoShop，FireFox等很多软件，都有各自的插件体系，我不清楚你在写什么插件。简单说一点，插件就是软件的原始开发者自己定义一套api规约，允许后来的程序员使用这个api规约，开发属于自己的软件模块，原系统可以根据这个api规约予以调用，实现系统的扩容。因此，这首先是一个私有协议系统，不懂的人，水平再高也不会开发，因为它的定义都很随意，是原始程序员拍脑门的结果，另外呢，有一定规范性，必须按照人家约定的api规约来，不能有一点错误，否则就失败。建议你好好看看原始文档，体会需要提供的每一个api接口的特性，这样才能开发出正确的插件。 Q： A：我的理解，只要是软件企业，bug管理是必须的。bug管理抽象出来，是一个管理流程，和程序其实没有多大关系，而是公司里面有这么一套管理“人”的机制，以便对bug实行跟踪，落实到人头去解决。一般说来，公司内网应该安装一套bug管理系统，我们公司用的是Mantis，这是一个开源产品，很好用，根据权限，QA检查出bug，即提交到这个系统上，PM根据情况，指派给某个RD解决，解决后，RD回复已解决，并修改状态，QA做回归验证，最终实现一个闭环。我的理解，一般的测试人员，找到bug并不难，难的是如何精确描述bug，通常，QA对于bug的产生情况描述越精确，RD越能快速定位，快速解决。但这需要经验，不是每个人都能做到的。因此，我通常建议，bug的管理和解决，应该RD和QA共同努力，而不仅仅是测试部门的问题。我在开发中强调白盒测试，即RD写完每个模块，交稿时都要附有该模块的测试工程，这些测试代码不会最终release出去，但是，可以帮助PM和QA做初步的分模块验证，其实只要有这个验证过程，很多bug可以在RD提交代码之前解决的。 我的新书《0 Bug ---- C/C++商用工程之道》，其实主要就是一本RD写给RD的书籍，帮助RD养成良好的开发习惯，理解很多开发中细节的差异性，以便写出bug尽可能少的程序。这本身，就是试图从源头解决bug问题