如果你热爱软件，你一定会关注软件质量；如果你关注质量，你最终会发现，架构是重中之重

很多才出校门的人，都说非常喜欢软件编程。

喜欢是一回事，愿意付出一生，哪怕是10年，20年的努力去作好一件事件，又是一回事。

非常羡慕现在的年轻人，有了这么好的环境：成熟的软件技术，网上无数的开源代码，很多常见的问题都有答案，回到1993年DOS年代，编写32位程序要付出多大努力？我但是可用的C++编译器是Watcom，环境是DMPI；只有很少的C++书籍，根本还没有出现目前这些成熟的模式(GoF)，当然微软也没有料到有Internet今天这么流行，还会有Java:)

Windows从NT开始才有线程，而且实时性但是还不能令人满意。我们可选的实时OS没有什么余地，只能是采用DOS。DOS与windows98的通信，通过Windows NT服务程序作为中心转发，协议只能采用Netbios的原始接口。我们在Java流行之前，开发了自己的脚本，自己的编译器和字节码规则，还有自己的虚拟机，一个可以解释运行电信语音信息处理业务的专用解释器。除了运行环境，还有资源管理系统、监控系统和业务逻辑管理（实现）服务器。为了产品研发，还要熟悉各种协议、信令的处理，语音的处理。4到5年的辛苦开发磨练，加上从一些优秀同事身上学到的知识，渐渐在软件领域开始了入门。可感觉自己的知识结构不系统、有欠缺，在业务时间还是坚持看一些书，效果却不是太好。这是一个矛盾：学习时没有实际项目操作；有项目时紧急到没有时间学习研究。

回顾10多年的历程，中途有些掉队，曾为某些原因离开软件开发的主流，涉足过售前顾问以及项目管理，然而最终发现，软件开发以及编程工作仍然是不舍得放弃。我不知道这样好还是不好，但我的技术经验对我的目前的管理工作帮助很大。我会把商业的需求和技术的处理流程结合，而面对的人性问题要比机器问题更负责，需要的沟通工作占去了最大比重的时间。

看着公司的产品质量屡屡发现问题，对客户造成不良影响，我的非常着急。开发人员很无辜，产品代码在几任程序员的手上传递下来，新的年轻人，短时间（某些接手产品也有1年了）无法读懂全部代码，这样发现Bug是很困难的。何况，以我的角度看来，产品的原始架构设计也存在严重问题，甚至还谈不上架构。要根治问题一定要从根本上重构。通过测试只能过滤一些低级问题，而无法发现结构性问题。

成功的理由都是相似的，失败的原因各不相同。

以我看来，质量管理上成了中国软件业发展的一个瓶颈。普遍的程序员都是重视代码的实现，没有质量管理的概念。目前越来越多的人开始学习架构设计，但重视实现、扩展和性能的人居多，而重视易理解、易维护的相对较少。其实，软件质量首先应该从制度上保障；其次要注重需求分析，在架构系统时，保证满足需求外，要考虑到一定的弹性、易于理解、易于实现、易于测试、易于部署，性能上最好要能够水平扩展。有条件情况下，程序员要接受软件质量的培训，配备必要的测试工程师，采用每日构建等技术，保证质量的反馈和改进。

质量问题，最后还是落实到人的问题。“最缺的还是人才！”

有感于一个有经验的测试工程师非常难得，希望各位朋友们能够推荐，谢谢各位！