软件质量控制

1. 从代码源头控制好质量，
   团队中有一人负责整个产品的质量和代码审核，对于狗屎代码要给予严厉的批评。不定期的经常举行内部培训，发布后bug汇总总结分析，不断提高开发团队技术 水平。发布后出现bug和开发者挂钩，除了不能解决的，严重Bug必须在2个工作日内解决，对于不能解决的bug要给出原因：是先期设计导致的？别人的配 合代码导致的？还是其他原因。这样做目的：出了问题，找出原因，避免不再重犯。
2. 软件测试
   软件测试是控制质量的关键。开发者不能完全依靠测试人员（如果存在的话），老一辈的程序员已经证明了这点。对于开发和测试之间，测试围绕开发，而不是以测试为主。如果可能，尽可能的做低成本的自动化测试。
3. 辅助工具
   这点有点宽泛，这里讲的是自动化构建、自动化测试、健壮的公用库及内部辅助工具等等。如果你是个注重短期利益的，这些对你是没用的，这些并不能给你带来直 接经济效益，而是带来长期效应的基础。自古以来，将复杂事情变简单的法子都回归到模块化和层次化，比如C++语言的发明、ISO标准的制订等等，模块化解 决了同层间的抽象，层次化解决了不同层间的抽象（废话），一个横向的抽象，一个纵向的抽象。每次看到别人封装的复杂无比易出错的C++库就想骂街，如果 C++让整个事情变得更复杂了，何必多次一举去玩封装呢？好的自动化构建工具从项目的层次对整个源码树进行抽象，把整个复杂的软件构建流程规范清晰起来， 降低构建对特殊的某个人的依赖，降低因为构建而导致的低级错误（比如不好意思这个模块我忘记更新，不好意思我给你的是debug版本的，不好意思我忘记提 交了，不好意思我的编译参数不对）。 健壮的公用库也是非常有必要的，比如枚举目录及子目录下的文件、zip文件的操作、ADO的操作、XML文件操作等等，当然很多都有开源版本，完全依赖开 源自己不去吃透是不靠谱的，代码最新和最好是两回事。

 好了，昨天改了一天bug终于修复了一个蓝屏，累的9点不自觉的睡着，然后早上5点不自觉的醒来，然后就有个这篇blog。

 

http://www.xuyibo.org/blog/522.htm