写一个新博客

Author: SamPeng87

Diff for: _posts/2012-04-08-every-day-must-attention-quality.md

@@ -0,0 +1,53 @@
+---
+layout: post
+title: "不能只是315这一天才关注质量"
+description: ""
+category: 思想
+tags: [质量控制]
+---
+{% include JB/setup %}
+
+ 315过去了，今天大家都还在津津乐道的讨论昨天央视爆出来的那些质量问题。其实，软件产品也需要质量晚会。
+
+我们的产品质量现在也有很大的改进空间，一定要通过大家的努力在产品的研发内部解决质量问题。借着大家都还在关注质量问题的东风，我来浅析产品质量如何保证，保证质量的工作要做在平时，并不是只有3.15这一天才关注。
+
+## 缺少流程是产生bug的重要原因
+
+我和几个朋友聊天，大家都是开发者。他们也和我抱怨，为什么开发时一点问题没有。但是一上线就是一堆bug？还有一些朋友的公司，就算引入了测试人员做测试用例。照样上线是一堆bug。窃以为，这是缺乏流程的表现。大家的开发流程无非是本地开发，大家测试没问题后就直接提交到测试服务器了。
+
+其实这是缺少系统化的流程，产品的研发是一个系统化的工程，需要引入CMMI这样的工程管理流程来保证产品的质量。通过前期的需求评审、概要评审、详细设计评审等关键节点的把控来提高产品的质量。
+
+## 通过集体Review来消灭Bug
+
+通过开发者自身的主动性来保证质量？这就是人治了，人治永远要保证人本身不出问题。否则谈什么都是空谈。而人治本身就是不靠谱的。每个人都有惰性，每个人都有妥协，甚至每个领导都会有灰度领域。做不到零容忍，就自然无法完全避免质量问题。
+
+要消灭掉一些低级bug，首先要引入的就是代码review。通过我们的实际运用来看，效果非常不错。可以很明显的消除一些人为的低级错误，什么变量名写错了，对客户端数据没有过滤，没有统一使用同一个接口进行数据操作而产生不一致的结果等等等等。群体意识是要高于个体意识的。测试用例只能测到表面级别的bug，实际上每个程序员都给自己留了一些问题，并不是开发的过程中不注意。而是“反正不可能测到这点，反正没人检查，反正问题也不大，到时候在改”一类的自我安慰，产生了bug遗留。
+
+可能一两个小问题是不怎么重要的，无关痛痒。然而如果系统庞大后，就是一个滚雪球效应，给人一种改不完的感觉。这样不只降低了产品的质量，而且降低了程序员的幸福感。
+
+## 设计中引入完善的异常列表
+
+简单的review可以消灭比较低级的bug，但是有些逻辑bug怎么办呢？不是整个团队都能够意识到所有的逻辑bug的。需求的不同，对bug的定义也不同。
+
+要解决这个问题就需要在开发之前引入一道防火墙：异常列表
+
+这其实是很多软件工程书籍里面的一个方法，也是一个标准流程。但实际上因为大多数团队都采取“人治”的缘故，这个过程是抛弃不用的。原因无非是：很多异常太简单了，一目了然，没有意义。异常太多，写起来浪费时间。这个东西实施起来没什么意义。
+
+真的是这样吗？如果有异常列表，测试用例可以轻松覆盖掉最低级的bug。如果有异常列表，代码review其他人就可以检查出不应该存在的逻辑bug，如果有异常列表。在编码之初就能够明白代码的健壮性如何？有些异常是可以容忍的。但要记录。有写异常是不能容忍的，但要给好的提示。等等等，在客户验收时碰到的边界性问题都可以通过这个异常列表的方式给解决掉。
+
+## 单元测试真不是浪费时间
+
+说单元测试浪费时间的都是没真正用过的。无数的统计数据表明，修改bug的时间有时候是写代码的时间的几个数量级。最经典的例子：因为变量名写错，死活存储配置失败。而找这个变量名真要大海捞针啊。
+
+修改bug的时间和系统的大小完全成正比，程序员都是喜欢偷懒的人。重复的一些调试工作就被一些思考着抽象出来了。那就是单元测试。
+
+在我们使用单元测试的过程中能解决以下几个问题：
+
+1. 变量名写错是不可能了。因为函数是最小力度的。单元测试只要覆盖这个函数，就能告诉我这个函数是否正确响应
+2. 判断失败。很多bug是因为对一些标示符的判断失败而造成的。而这种bug本身又隐藏很深，光凭调试的话，需要开发者大量的经验和精力
+3. 参数没过滤。不是所有的参数都叫有效参数的。。
+4. 写的代码和自己设想不同。明明在一个函数定义返回1或0。结果给了我array。明明认为$_SERVER中有某个属性，但偏偏在某些服务器中的时候就是没返回这个属性值。（IIS和apache会影响$_SERVER的值）
+
+这些都是低级bug，影响了我们的产品质量，影响了我们开发者的幸福度。但是，我们不会惧怕，我们在积极的改进。我们要通过开发流程的规范化、集体的代码Review、在设计中加强异常的处理设计、同时加强单元测试。从而坚决将低级bug消灭在襁褓之中。
+
+**不能只是315这一天我们才关注质量**。对于我们程序员而言，每天都要关注手上做出东西的质量。这不仅仅是对客户负责。也是对我们自己负责。

Diff for: index.md

@@ -13,7 +13,7 @@ header: 无底洞
 
 最近[markdown][1]很火，我也详细的使用了一下。好用多了额。写博客写起来很顺手，不用关心布局，只要写就是了。
 
-于是有了这个博客空间，搭建在[github][2]上的博客.这应该会是我最后集中的博客空间了。正在迁移所有其他博客空间的日志过来。
+于是有了这个博客空间，搭建在[github][2]上的博客.这应该会是我最后集中的博客空间了。其他系统的都迁移过来了。其实并不多
 
 [如何在github上写blog][12]