工作日志之三－－代码很烂，谁的责任？
刚来的时候就发现程序中涉及一些比较重要的模块有很大的漏洞，按理说这种漏洞是不应该由我这个新员工来发现的。原因是：一、这种漏洞个人认为是属于比较严重的，早就应该有人发现了；二、系统运行了这么久了，早也应该发现了。其实最无法忍受的倒不是这些bug本身，而是bug提交后人们的态度。没有人对此表示惊讶，“哦，这个有问题，改一下把”，基本上都是这种解决问题解的方式，轻松的很。这种氛围下自己经常觉得有些格格不入，有时候真的怀疑是不是自己小题大做了，不就是个bug吗？
有点怀念asia的工作氛围了，在那里，质量控制已经融入到大家的血液里去了，高层、开发跟qa一样重视质量问题，这样干起活来，至少你的敬业能获得承认。
代码很烂，看起来是开发的责任，实质是qa（不是qc）没有到位，根源是整个公司（包括高层）根本没有质量控制的意识，这种意识是要融入血液的，而不是靠一堆没有生命的文档来体现。
个人认为这种现状可能都是由于国内大部分公司的项目太小引起的，不像电信级的项目，用户多，有错误总能被用户发现，数据量大，你需要速度和健壮性，小的错误也无法容忍。asia也是从割接的失败中开始思考质量问题，最终建立了业界的最高标准CMMI5，但是有些人在失败中能获得巨大的提升，而有些人就在失败中沉沦了。
[ 本帖最后由 lscwd 于 2007-11-15 11:43 编辑 ] 说的不错，基本上这就是目前行业的现状了。技术或许不是很重要的，但思想意识非常重要。 在家没事做,翻帖子.
这种情况也遇到过,我想也普遍存在,我不是QA,但是真正能做到规范代码的QA又有几个呢?这需要很高的水平啊
大多数的就是文档形式的了...
最关键的还是看开发人员的理解和编码能力了... 一切都是形式 确实如楼主所说的那样，文档、流程写的再好，执行力度不够，等于一堆废纸。再者现在小公司的老总对质量根本不重视，只顾怎样才能赚更多的钱，而且有的项目太小，根本没发按流程走，有写文档的时间，10个这样的项目都做好了。所以我也很困惑现在 小公司的现状态，多数都 如此，管理混乱也不稀罕 质量控制融入到血液是需要成本的 哈哈，你能去改变什么吗？能的话，那就去做吧。
页:
[1]
