综上，我认为可以得到下面这么几个结论：

1、边际成本为零（或近似为零）的产品，一定会进入免费市场  

2、在免费市场中，产品一定要走精品路线

3、纯软件是边际成本为零的比特商品，

评论: 16　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 邵晓锋调任阿里集团秘书长 协调子公司资源(2010-03-19 22:08)
· Notifo推iPhone应用：弥补邮件推送缺陷(2010-03-19 21:04)
· 分析：微软IE9现身 网络视频标准争议依旧未解(2010-03-19 20:57)
· 连线朱骏：陈晓薇离开九城与魔兽无关(2010-03-19 20:52)
· 九城总裁陈晓薇5月期满离任 朱骏将代理总裁(2010-03-19 20:48)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

为了使文章读起来比较有趣，假设屏幕前的你现在中了彩票头奖，奖金5亿RMB。于是你彻底解放不用再写代码啦，天天开辆法拉利到处玩，来给你介绍对象的媒人踏破家门。经过初赛、复赛、泳装、晚装、才艺展示之后，仍然有三位佳丽胜出。她们各有所长，但又无法量化比较，让你无法取舍。如下表

	如花	如月	如云
相貌身材	身材娇小,苗条	身材高挑	身材性感
	五官有点像刘亦菲	声音比较甜	五官有点像林志玲
学识智慧	硕士, 绘画专业	本科, 舞蹈专业	本科, 表演专业
	目前职业是时装设计师	目前职业是舞蹈演员	目前职业是平面模特
	平时爱呆在家里看闲书,或画画涂鸦	钢琴和声乐上受过专门训练,有一定水准	爱好到世界各地旅游
气质	清纯、阳光	优雅	高贵、性感

但可惜你不是泰国人或阿拉伯人，只能按照中国的法律一夫一妻，所以你不得不做出选择。这时候我们的AHP（The analytic hierarchy process）层次分析法就华丽丽地登场了！

一、AHP方法适合这样的场合：
1、有决策目标、有几种可选方案，并且能在方案之间提炼出比较要素
2、各方案在比较要素上只有定性的描述，无法定量衡量
3、你只能凭直觉或经验，对某两方案的某两要素进行两两比较
3、需要对所有方案排出座次。

二、AHP方法的理论基础和数学模型

数学模型比较复杂，详见MBALIB的 层次分析法 词条，对高数还念念不忘的同学可以进去怀旧一下。我们现在的目的是挑老婆，不是做矩阵运算，因此计算的事就找个软件代劳。AHP的计算软件有很多，下文我用了YAAHP这个软件，可以点这里直接下载。虽然你已经是亿万富翁，但是咱们不能忘了程序员的良好习惯，坚持使用盗版或免费软件，这个YAAHP就是免费的，符合勤俭朴素的你。

首先声明我不是托来宣传这个免费软件的，而是因为传授我AHP方法的老师向我推荐了这套软件。

三、建立层次结构模型

最上面粉色的是目标层，中间黄色的是要素层，最下面蓝色的是方案层。具体使用方法见YAAHP的flash演示动画，下载安装后也有。这个FLASH动画里演示了买车的决策分析，而且要素层里面再细分为两层。不过你已经买完法拉力了，现在要选老婆。我们把模型建得简单点，要素只有一层，如下图。

四、填写判断矩阵

如上面所述的选老婆场景，判断矩阵一共有有4个。分别是：

（1）你对三个比较要素的侧重程度。也就是说，你更看重相貌身材，还是更看中学识智慧或气质，这三者在后面比较中的权重各占多少

（2）三个美女在“相貌身材”上的两两比较矩阵
（3）三个美女在“学识智慧”上的两两比较矩阵
（4）三个美女在“气质”上的两两比较矩阵
由于都是两两比较，所以每个3*3矩阵里只用填入一半不到的格子就行了。如下图，在右上方黄色柱子里拉动那个蓝色方块就行了。

注意这里有个“一致性”，定义和公式见这里。判断矩阵的一致性如果超过0.1, 则上面那行蓝字会提示“不一致”，然后这个软件就鄙视你拒绝为你计算结果。可以调节矩阵里的数值避免这种情况。

五、计算结果

某个邪恶的男人把四个判断矩阵填写完后（后面三个矩阵的数值保密，免得我老婆看到了扁我），YAAHP软件就自动帮你算出结果了：

注意，这是AHP层次分析法计算出来的结果，而不是程序软件计算的结果. 抛开软件，我们直接在纸张上画格子填判断矩阵, 最后也能手算出同样的结果来. 根据每个人凭主观判断而填入矩阵的数值不同，最后也会呈现不同的结果.

所以，按照某个邪恶男人的审美标准，如月胜出当正房，其次是如云做二奶，如花出局。

这个计算结果会由你对每个要素的倾向而不同，最后把主观的东西变为量化的结果，很神奇吧。

六、群体决策

假设这时候作为亿万富翁的老爸老妈对你的层次分析法结果表示异议，也希望加入决策，那么你可以在AHP中加入群体决策，如这个视频所演示的，你还可以为各个参与者设定权重。

七、回到现实

这样挑老婆当然很爽，可惜你还没中那5亿RMB，所以只好老老实实做产品策划、功能取舍。

用好AHP层次分析可以让你的团队对目标更加明确，做出正确的取舍，赚它个5亿10亿的也不是不可能，到时候就可以如上文那样用AHP方法挑老婆了^_^

评论: 20　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 邵晓锋调任阿里集团秘书长 协调子公司资源(2010-03-19 22:08)
· Notifo推iPhone应用：弥补邮件推送缺陷(2010-03-19 21:04)
· 分析：微软IE9现身 网络视频标准争议依旧未解(2010-03-19 20:57)
· 连线朱骏：陈晓薇离开九城与魔兽无关(2010-03-19 20:52)
· 九城总裁陈晓薇5月期满离任 朱骏将代理总裁(2010-03-19 20:48)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

我有一种强烈的预感，将来所有边际成本为零、或趋近于零的产品，最后都应该、也都会成为免费的。比如各种软件、MP3歌曲、音视频节目、电视剧拷贝，等等。毛主席说，一切反动派都是纸老虎。因此，现在那些叫嚣版权的、封杀盗版的都是纸老虎。这些组织和团体无法顺应潮流，而是占住已有利益不放，试图去挽救一种即将被淘汰的商业模式，估计最后只能成为历史的笑柄。

在《长尾理论》的作者Chris Anderson的新书《免费：商业的未来》中，为目前市面上流行的免费模式建立了四种模型，为广大奋战在软件开发第一线的战士们送来了理论武装。

（以下四种模式的名字及图片转载自此书，但案例和分析是我个人原创）

模式一：直接交叉补贴

什么免费：吸引你掏腰包买其他的商品
谁享受免费：以某种方式最后掏腰包的人

直接交叉补贴可以参考以下例子：
1、充话费送手机。手机是免费的，但你事先得充足够的话费。
2、微软新出的PIM服务“MyPhone”是免费的。但是消费者用MyPhone之前，已经为Windows Mobile手机付过费了
3、你到演唱会里听歌是要付钱的，但是到酒吧里听歌则是免费的，因为你已经为买酒付钱了，这部分钱会补贴给歌手的演唱收入。
3、市政府提供免费的公园给市民休息游玩，因为你已经付过税了
4、厦门广电的免费送机顶盒。机顶盒是免费的，但广电预计消费者多少会买些付费频道，用这块钱来补贴机顶盒。// 可惜他们打错了算盘，很少人愿意买付费频道，这块收入不理想，所以最后机顶盒要收钱，闹出了很大矛盾，公众并不鸟你什么交叉补贴模式。

模式二：三方市场

什么免费：内容、服务、软件等
谁享受免费：任何人

这几乎是目前使用最普遍的一种免费方式。比如：
1、免费看CCTV的电视剧，因为它有巨额的广告收入
2、免费用PPStream, youtobe, YouKu看电影，广告主为视频开始前的广告买单。// 所以其实某菊封杀视频网站，我觉得不是因为盗版或政治原因，而是蚕食到自己的利益了。所以我们做产品设计赢利点的时候要尽量避开垄断集团利益，QQ尚且被飞信给强X了，何况咱们这些草民。
3、免费用百度的搜索，广告主到竞价排名系统中买单。
4、免费看新浪和网易的新闻，广告主买单

模式三：免费加收费模式

什么免费：和付费版本相匹配的任何商品
谁享受免费：基本用户

我们所谓的“增值服务”都属于这类。其应用场景如：
1、免费的网络游戏，付费的道具。据说最早是韩国人发明的，被史玉柱发扬广大。目前大陆按时间收费的道具已经非常少了，基本都是道具付费模式。
2、Skype，PC之间可以免费语音通话，而PC和手机、手机和手机之间通话就需要付费了。// 注意在大陆手机上用互联网络做语音通讯这是个禁区，建议不要去碰。
3、网易邮箱，大量的免费用户，少数的VIP用户的付费。

模式四：非货币市场

什么免费： 人们选择免费赠送的、没有寄希望别人付钱的任何东西
谁享受免费：任何人

这种模式简而言之就是“赔本赚吆喝”。应用场景如：
1、360安全卫士目前是完全免费的，纯粹是为了破坏原有的杀毒软件商业模式，吸引装机量并扩大整个杀毒软件的市场规模。就目前阶段而言，就属于这种模式。以后很可能演变为广告主付费的模式二，或者企业用户付费的模式三，或者两种模式兼而有之。

2、以前我在大学时成立了一个钢琴社，每个季度都有免费的演出，很多人苦练几个月就为上台演奏一首曲子，不求任何金钱回报，也是这个性质。
3、这种免费模式里很典型的就是写博客，以及CSDN上的专家分。知识提供者并不需要什么货币收入，只是喜欢一种观点被关注和认可的感觉，或者纯粹就是分享知识的快乐而已。

------

目前做嵌入式软件主流的赢利模式有四种：
1、由设备厂商为软件付费（不管是内部的还是外部的），软件和硬件捆绑在一起卖给消费者。大陆用户虽然没有为软件付费的习惯，但是买硬件还是得付费的。
2、行业定制。为政府部门和企事业单位开发定制设备。由于总能帮客户单位提高了生产率或降低了成本，企业付钱是比较愿意的。缺点是比较难形成规模效应（相对于第1条），因此很累人很辛苦。
3、把移动应用软件放到APP STORE上面去卖。这个模式在大陆刚开始，国内的环境和国外大不一样，大陆消费者是否愿意为软件版权买单还很难说，本人观望中。
4、考虑上述的免费模式。

（欢迎补充）

而免费模式中：
模式四不适合长时间地做，只能短期烧钱玩一把，把领域里地主老财们的命革掉，打土豪分田地，自己建立新秩序（如360安全卫士）。适合有钱人玩。
模式三需要花一大笔投资去吸引广告主，适合做中长线。（其实手机上的屏幕太小，做文字/图片等空间属性的广告效果可能不好，我怀疑最终形式是时间属性的广告，如音频广告）
模式一和模式二，我认为这种方式可以使投资在短时间内有收益，值得重点考虑。

评论: 23　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 邵晓锋调任阿里集团秘书长 协调子公司资源(2010-03-19 22:08)
· Notifo推iPhone应用：弥补邮件推送缺陷(2010-03-19 21:04)
· 分析：微软IE9现身 网络视频标准争议依旧未解(2010-03-19 20:57)
· 连线朱骏：陈晓薇离开九城与魔兽无关(2010-03-19 20:52)
· 九城总裁陈晓薇5月期满离任 朱骏将代理总裁(2010-03-19 20:48)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

突然翻出一篇自己比较早时候写的， 遗留在MSN SPACE里面, 转过来。
有点小意思，古人谈论事情貌似就需要这样生拉硬扯，开头必先圣人云如何如何，再把自己的观点附会上去说圣人也是这么说的。

------------------------------------------------------

早上看一篇项目管理文章中提到的这个比喻. 作者是台湾的高焕堂.

孔子在提到的"五至"是
物之所至, 志亦至焉.
志之所至, 礼亦至焉.
礼之所至, 乐亦至焉.
乐之所至, 哀亦至焉.
哀乐相生, 君子以正.

被高焕堂解释为：
物 —— 就是软件系统及其架构
志 —— 就是客户的需求
礼 —— 就是流程管理制度，如CMMI，或agility
乐 —— 就是需求获得满足
哀 —— 就是需求无法满足

以下是我个人的解读，高焕堂在后面的解释都比较牵强，下文就不采用了。

物之所至, 志亦至焉.
        ——系统的软硬件条件（物），决定了在其基础上哪些是合理的需求，两者必须和谐不冲突。
志之所至, 礼亦至焉.
        ——在和谐、可实现的需求上，就能制订项目执行计划（礼）。
礼之所至, 乐亦至焉.
        ——根据计划（礼）开发出合乎需求的产品，满足了客户的需求（乐）
乐之所至, 哀亦至焉.
        ——时间在变，产品的竞争局面在变，客户/用户的需求也随之改变了。对需求的满足只是一时的。产品无法完全满足客户/用户的新需求时，抱怨（哀）就产生了。
哀乐相生, 君子以正.
        ——所以我们得及时调整项目计划，做出适当的需求变更，做出有合适的竞争力的产品。如此哀乐相生循环不已，有智者以此为常态。

孔子的"五至"实际上指导了我们以下几点：
1、需求必须在系统软硬件基础上合理提出，不能不切实际地凭空想象。（比如在100MHz的CPU上模仿iPhone界面的动画效果）
2、而开发计划是根据需求和系统软硬件条件而定的。
3、五至篇的重点在于“乐之所至, 哀亦至焉”的转折，和“哀乐相生, 君子以正”的总结。实际上就是从哲学层面上强调了
（1）对需求的满足感不会是长久的恒定的，必然是哀由乐生。用户/客户在对需求的一时满意之后，必然会有新的需求提出来。需求是无止境的。
（2）对于需求的变更和增加，有智者应该理解为一种常态。实际上这也是整个产业能够发展的根本动力所在。
4、第3点谈到的需求变更，又等于回头到第1点上，需求变更同样必须在“物”的基础上合理提出。如果当前的系统软硬件条件无法满足新的需求，那就得升级我们的“物”了。这时候一个新的平台或新的项目就又开始了。

Walzer @ 2008-10-7

评论: 0　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 邵晓锋调任阿里集团秘书长 协调子公司资源(2010-03-19 22:08)
· Notifo推iPhone应用：弥补邮件推送缺陷(2010-03-19 21:04)
· 分析：微软IE9现身 网络视频标准争议依旧未解(2010-03-19 20:57)
· 连线朱骏：陈晓薇离开九城与魔兽无关(2010-03-19 20:52)
· 九城总裁陈晓薇5月期满离任 朱骏将代理总裁(2010-03-19 20:48)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

这个是比较早, 09年4月份的事情了。整理文档翻出来，觉得还有点意思.

当时CLIENT-SERVER的通讯封包格式有两种方案

a. 以7E为开头和结尾, PAYLOAD中所有7E的字节, 都在其后扩展一个BYTE, 写为7E, 7D, (称为转义). 封包中不带CHECKSUM, CRC等校验用的字段

b. 以7E为开头和结尾, 带一个CHECKSUM字段, PAYLOAD中不进行7E->7E 7D的转义.

几个同事就这个通信封包格式, 采用方案一或方案二, 开会激烈讨论了个把小时。
我原先反对转义方案的出发点比较模糊, 只是觉得原先转义的方案"不优雅"; 后来才想清楚了不优雅的"本质"在哪里.

所有的代码, 可以在抽象意义上分作两大块, 两者的着重点是不同的.

(1) 正常运行的代码. 首要追求高效性,
    这个"高效性"如果从逻辑的角度来解释, 那么一方面是"高效"地对正确的数据执行正确的算法(方法/策略), 另一方面是"高效"地找出异常, 然后丢给异常处理代码去处理.

(2) 处理异常的代码. 首要追求健壮性. 
    就是程序必须能从异常中自我恢复. 由于代码多数时间跑的是"正常"逻辑, 少数情况下才不得不处理"异常", 所以"异常"处理的代码中, 首要任务是健壮, 跑不死, 而高效性则是次要的.

那么回到转义的策略上来看，原先的7E -> 7E 7D, 使得装包和拆包的时候, 时间上都必须挨字节扫描过去, 空间上必须另开一块内存, 这些"不优雅"的工作是为了应对网络传输时包数据丢失. 包数据丢失是一个异常情况，而转义策略本质上就是不论好包坏包，一棍子打死, 统统要经过转义算法. 用上面的观点解释, 即"为了异常情况下的健壮性，牺牲了正常情况下的高效性".

而用Header + Length + CheckSum + Payload + Tailer的做法, 逻辑上是这样的

这是在上面"正常->高效性 & 异常->健壮性"指导思想下的做法. 那么现在就剩最后一个问题, 计算checksum和转义的工作相比, 哪一个更快? 如果转义处理的效率, 比checksum更高，那么上面的假设就不成立了.

所以我做了个实验, 代码如下

代码

BYTE* pBuf1 = new BYTE[1024];
BYTE* pBuf2 = new BYTE[1024*2];
UINT8 sum = 0;
DWORD tStart = 0, tEnd = 0;

// CODE 1, 转义处理
tStart = GetTickCount();  // WM上的毫秒级时间

for(int j = 0; j < 100000; j++)
{
    for(int i1 = 0, i2 = 0; i1 < 1024; i1++, i2++)
    {
        if (pBuf1[i1] == 0x7E && pBuf1[i1+1] == 0x7D)
        {
            pBuf2[i2] = pBuf1[i1];
            i1++;            
        } 
        else
        {
            pBuf2[i2] = pBuf1[i1];
        }
    }

tEnd = GetTickCount();
        
printf("copy 1024 bytes * 100K times, use %d ms\n", tEnd - tStart);

// CODE 2, CHECK SUM
tStart = GetTickCount();

for(int j = 0; j< 100000; j++)
{
    for(int i = 0; i < 1024; i++)
    {
        sum += pBuf1[i];
    }
}

tEnd = GetTickCount();

printf("check sum 1024 bytes *100K times,  use %d ms\n", tEnd - tStart);

上面这段代码，在SAMSUNG 2442 400MHz的CPU, WM 6.1系统上运行结果是

copy 1024 bytes * 100K times, use 11677 ms
check sum 1024 bytes *100K times,  use 7504 ms

所以, 一个正确的数据包, 经过CHECKSUM计算的时间, 比其经过转义计算的时间要快得多, 仅为其64%.  这是手机上的情况, 服务器上的百分比不太清楚是什么样，但至少有一点是肯定的，就是用CHECKSUM的方案比用转义的方案，在正常逻辑情况下速度更快、内存开销更少。当服务器同时处理十万数量级网络数据包的时候, 性能提升还是比较可观的。

这篇文章的重点不在于哪个方案更严谨，或者上面的逻辑对不对，而是在于这么一个思想：

(1) 正常运行的代码. 首要追求高效性,

(2) 处理异常的代码. 首要追求健壮性. 

评论: 0　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 邵晓锋调任阿里集团秘书长 协调子公司资源(2010-03-19 22:08)
· Notifo推iPhone应用：弥补邮件推送缺陷(2010-03-19 21:04)
· 分析：微软IE9现身 网络视频标准争议依旧未解(2010-03-19 20:57)
· 连线朱骏：陈晓薇离开九城与魔兽无关(2010-03-19 20:52)
· 九城总裁陈晓薇5月期满离任 朱骏将代理总裁(2010-03-19 20:48)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

一、质量的相对概念

1、多数比较上进的程序员，都希望自己的代码作品是优雅的、高质量的、别人看到能赞赏不已的。但事实上，紧迫的进度压力使程序员没有太多时间思考，匆忙赶出功能后，赶快测试发布赶快交付给客户。因此有人提出需要重构，有人提出各种测试方法，计算“每千行代码缺陷率”，以追求“零缺陷”为目标。总之多数技术人员认为“质量越高越好”。这里有个典型例子《养成重构的习惯有多重要》，原文和后面的回帖都很有代表性。

2、现在我们假设一种场景，筷子的质量。
首先你到了五星级酒店，它的筷子必须是如象牙般优雅，笔直而对称，没有任何瑕疵斑点，有合适的重量手感，等等，也就是说五星级酒店对筷子的质量要求是很高的，否则客户会发飚。
然后你到了一家路边的快餐店，顺手拿过来一双“一次性筷子”，拆开后发现毛刺很多容易扎手，甚至筷子有点弯曲，但你还是凑合着用了，或者实在无法忍受就扔掉再拿一把，因为这是在路边快餐店，用户对筷子的要求是低的。
如果你把快餐店的筷子卖到酒店里会发生什么情况？质量太低客人无法接受。如果五星级酒店的筷子卖到快餐店会发生什么情况？用户不需要那么好，也不愿意付那么多钱。所以同样做一个筷子，却对质量有不同要求。
所以说：质量是相对的。

3、基于第2点，所以一味追求“高质量代码”，把“高质量目标”凌驾于“企业赢利目标”之上，是多数技术人员所犯的错误。

二、对质量目标进行逐级分解和控制

多数成熟度不高的软件公司会有一定的质量控制方法，但将其用于所有的项目和所有的软件层面。我认为这是一种资源浪费。适度降低对外围层次、用户需求弱相关、使用频度低模块的质量控制，会给项目带来进度和成本上的收益。
比如下面这个案例。这是一个比较成功的网游公司中，项目代码分层控制情况

	层次功能	质量要求	开发者	编程语言	代码开放度
5	任务脚本、战斗剧情、数值设定等外围脚本	逻辑正常，跑起来不会导致程序崩溃就行。手工测试	项目策划组的非编程专业人员，简单培训后即可编写	自定义的、类似python的低难度脚本	所有人可见
4	项目外围代码	详细设计由主程评审，代码未评审。手工测试	项目程序组的非主力人员，多数是普通大学本科毕业生	某种业内标准的脚本语言（商业原因不便透露）	所有人可见
3	跨项目使用的游戏主要逻辑，核心代码。如好友系统、聊天系统、帮派系统等	详细设计由技术总监亲自评审，部份模块有做单元测试.	项目程序组的主力人员，主要由重点大学本科生构成	同上，业内标准的脚本语言	所有人可见
2	跨项目使用的开源游戏引擎，研究/优化/集成/针对特殊需求进行二次开发	技术总监亲自带队，测试方法未知	研究部成员。基本都是211大学硕士或海归，计算机或数学专业	C/C++	研究部成员及工程项目的经理、程序经理、测试经理可见。其余人员不可见
1	上面3/4层所用的脚本解释器、服务器分布式框架等	技术总监亲自开发和测试。测试方法未知	技术总监和几个创业元老，清一色海归	C/C++	仅技术总监和公司股东/创业元老，及几个项目经理可见

 

大家特别注意每个层次的质量要求，从“不使程序崩溃、逻辑正确不使程序崩溃即可”，到“技术总监亲自开发测试，不许别人碰里面代码”分级管理，越是核心部分对代码质量要求越高，从开发人员的级别/背景/资历/审核人员级别/测试方法上可以体现出来。而4和5两层比较外围的代码, 只要实现功能就可以了, 我阅读了这些代码并在其中开发过一小段时间，里面到处充斥着“坏味道”的代码，程序员都是边改边骂，但这并不影响这个游戏有60万的活跃用户和300万以上的注册用户，给公司带来强劲的现金流。而这套对质量进行分级控制的方法，则是技术总监传授讲解给我的。

（表格中代码开放度仅供参考，小公司是输不起的，看看pudn.com上那些把老东家代码拿出来开源的人渣就知道了）

大家知道项目的时间-质量-成本铁三角, 如果把上面5层代码的铁三角列个表格出来，大致如此(我们假设在每个软件层面投入的成本是一致的)

层次	质量	进度	成本
5	5	1	3
4	4	2	3
3	3	3	3
2	2	4	3
1	1	5	3
平均	3	3	3

越是核心层（1层）, 其需要修改的代码越少，但是对代码执行的时间和空间开销越小, 稳定性要求越高. 越外围的代码（5层）, 针对需求而开发和改动的代码量越大. 选取上表中的1层、5层、平均画图来表示是这样的：

因此，精益求精、重构只适用于靠近核心的代码层；而对于外围代码层, 由于赶工而导致代码质量低、放松测试条件，则是完全合理的。 

三、结论
所以，在做软件工程的质量控制时，应该把握软件的关键层面，抓住质量控制的瓶颈。横向而言，就是开发框架、引擎、核心功能之类的层级；纵向而言，就是用户使用频率最高的模块、和竞争对手做差异化竞争的功能等。对于外围代码和次要模块代码，前者一般不容易出错得太离谱（被开发框架限制住），后者使用频度低，则可以适当牺牲质量以求开发速度。

因此，处于外围代码开发的兄弟们就不要成天抱怨、不要提出各种重构要求了。我也曾经在“坏味道”的代码，确切地说是“粪坑”中扑腾，深知其中感受。但就像魔兽世界里组队打某些副本BOSS，有的人职责是拉住BOSS的仇恨（拉住客户），有的人职责是砍BOSS（解决核心模块），有的人则需要群杀不断刷出来的小怪（快速开发外围逻辑）。如果不是这样的配合，那就会团灭；如果不是这样的配合，下个月的工资可能就发不出来，不是吗？

评论: 12　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 邵晓锋调任阿里集团秘书长 协调子公司资源(2010-03-19 22:08)
· Notifo推iPhone应用：弥补邮件推送缺陷(2010-03-19 21:04)
· 分析：微软IE9现身 网络视频标准争议依旧未解(2010-03-19 20:57)
· 连线朱骏：陈晓薇离开九城与魔兽无关(2010-03-19 20:52)
· 九城总裁陈晓薇5月期满离任 朱骏将代理总裁(2010-03-19 20:48)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

轻量级开发方法和重量级开发方法的本质区别，在于开发过程中的中间产物（如文档、图纸、工作日报/周报）数量多少。中间产物数量越多，则开发方法越重，开发者需要花更多时间去做那些无法体现在最终交付结果之内的工作。比如花了30%的时间在写详细设计文档，5%的时间在写工作日报和周报等等。用图表示如下：

可以看到，过程中有很多“中间产物”，如需求文档、概要设计文档、详细设计文档、测试文档、测试结果报告、工作日报/周报/月报等。按照网上流行的说法，重量级方法呈现的是一种“防御型”的姿态。在应用“重量级方法”的软件组织中，由于项目管理者不参与或者很少参与程序设计，无法从细节上把握项目进度，因而会对项目产生“恐惧感”，不得不要求程序员不断撰写很多“软件开发文档”及“工作日报/周报/月报”。

而轻量级方法则呈现“进攻型”的姿态，如下图：

轻量级方法强调所有工作都与交付结果强相关，尽量减少无关的工作，使得开发速度更快。当然XP方法里有个重要前提，就是团队中的程序员必须都是高水平的、可信任的。这种方法比较激进，每个过程拉得更长，而审核时若无法通过，则需要返工的工作量比重型方法中的多，结果可能导致“欲速则不达”的结果。

具体哪个方法好，这个还在争论。觉得凡事无绝对，适合自己团队的方法，就是好方法

评论: 0　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 邵晓锋调任阿里集团秘书长 协调子公司资源(2010-03-19 22:08)
· Notifo推iPhone应用：弥补邮件推送缺陷(2010-03-19 21:04)
· 分析：微软IE9现身 网络视频标准争议依旧未解(2010-03-19 20:57)
· 连线朱骏：陈晓薇离开九城与魔兽无关(2010-03-19 20:52)
· 九城总裁陈晓薇5月期满离任 朱骏将代理总裁(2010-03-19 20:48)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

一、三个组织的故事
先讲故事。以我呆过的三个研发组织为例：

组织A：从公司老板到基层程序员，都保持了很高的继续学习受教育的意识，大老板带头读了MBA，中层和基层成员根据个人的爱好和职业规划，有的读了MBA，有的读了项目管理在职硕，有的读了软件工程或集成电路在职硕。另外大家在业余时间也会读一些书、看一些开源项目的代码，然后在吃饭时谈论这些东西，书籍会相互推荐相互赠送。组织内鼓励知识共享，鼓励成员把工作经验写成技术总结发在内部BLOG上，以相互交流经验。一方面写技术总结是作为业绩的硬性考核指标，对程序员要求每个月一篇，对组长要求每月两篇并要求全组提交的要有一定数量和质量，年终和中秋聚餐时会表彰在知识共享上贡献突出的成员。这是一种难能可贵的学习型组织，但是在这个组织由于公司规模太大，因此规范流程等相对稳定，在管理层面没有比较强的“自我优化”能力，只在编程等业务小范围内会“自我优化”。因此我认为这是一个学习型组织，但不是自我优化型组织.

组织B：一个疯狂的创业型组织，大概一半的人以工作为事业而疯狂，另一半人则被环境和氛围所迫，每人每周工作60小时以上，骨干成员每周工作甚至能达到70小时。有的核心成员非常典型：一个项目经理因为工作太忙而申请MBA休学并且很可能干脆退学、一个主程因为长时间工作过度劳累导致脑溢血回家躺了一年，一个主策划因为连续工作时间太长太亢奋太疯狂而直接在加班时昏倒被同事送医院。在这种组织里，虽然公司图书馆里提供了很多书籍和期刊，但实际上已经没有给成员留出业余自我学习提高的时间了。不过这组织另外有一个很强的能力，那就是“自我优化”。大家都能主动发现规则、流程、设计和开发、甚至企业经营中的存在问题，在内部WIK上提出来讨论，讨论也很热烈甚至演变为争论，最后再收拢成为更新后的制度流程。整个组织始终是朝着更健康更高效的方向发展。因此我认为这是一个自我优化型组织，但不是一个学习型组织。

组织C：一个现金流雄厚稳定的大公司下面一个试图开拓新业务的组织。很遗憾这个组织继承了稳定成熟期大公司的特点，稳定有余而进取不足。他们的绝大多数成员不会在业余时间自己去寻找进修机会，也很少阅读书籍后拿出来谈论，在开发流程和代码设计中存在各种显而易见的陋习和弊病，却没有人提出来改进。所以这既不是一个学习型组织，也不是一个自我优化型组织。另外，我注意到了很有趣的一点, 该公司的第一个程序员，也就是创业元老, 在创业成功后既不想继续提高技术做个CTO, 也不想往管理方向发展做个经理管个部门，而是选择了工会主席这样的闲职, 拿分红日子过得逍遥。这是否导致了后面入职的技术人员就有样学样、进取不足，那就不得而知了。

二、学习型组织和自我优化型组织的关系

其实学习型和自我优化型，两者之间表面上关联性并不大。但我仍然觉得可以扯到一起。我认为，自我优化是基础，一个组织不可能在各方面是完美的，需要各级成员在自己工作岗位上，对所负责的事务发现问题、提出优化方案，整个组织才能在管理、设计、编码各层面上新陈代谢日益健康。而学习型是对前者的增强，如果自我优化只是基于自己直觉和经验的优化，那么步伐是比较小的；而如果学习后能基于管理学、经济学等理论，以及敏捷、CMM、GOF设计模式等正确的方法论进行优化，那么进步的步伐就会更大。

打个比喻，把一个组织比成游戏里的角色的攻击力，那么建立自我优化型组织是增加攻击力的上限点数，优化一次从攻击力100点提升到110点，再优化一次就从110点提高到120点；而建立学习型组织则是给予攻击力百分比加成，比如一次优化能提高10点攻击力，有了百分10%的加成后，每次优化就能提高11点攻击力。

评论: 1　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 邵晓锋调任阿里集团秘书长 协调子公司资源(2010-03-19 22:08)
· Notifo推iPhone应用：弥补邮件推送缺陷(2010-03-19 21:04)
· 分析：微软IE9现身 网络视频标准争议依旧未解(2010-03-19 20:57)
· 连线朱骏：陈晓薇离开九城与魔兽无关(2010-03-19 20:52)
· 九城总裁陈晓薇5月期满离任 朱骏将代理总裁(2010-03-19 20:48)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

一、R&D概念的分拆
搞研发的掏出名片来一般会印上这么个部门：R&D。所谓R&D就是Research & Develop，研究与开发，所以简称研发。我曾经碰到个高人，强调把这两词拆开来单独理解。“研究”就是把一个团队知识之外的知识点弄懂，引入项目中使用；“开发”就是把已经明白的东西做出来。

二、为什么多数程序员更喜欢搞研究
一般来说，研究人员比较嚣张，不喜欢按规矩行事，理想状态是中国文化里那种特立独行的大侠，一人单挑各种技术难题、熬夜数周最后搞定，写个DEMO CODE解决了关键问题，最多再搞篇技术总结文档，就可以长嘘一口气，等待众同事膜拜；而开发人员相对比较孙子，胆敢做点不合规矩的事，那就是藐视流程藐视公司制度，要镇压的。所以在研发领域，绝大多数人比较向往研究岗位，待遇好地位高、可以单干、能够证明自己的智商，最重要的是能够不断做新的东西不用重复劳动；而开发人员是苦力，整天做些“体力活”，比较没有技术含量，也难有比较大的长进，工作本质和手机生产线上按图纸插元器件的小妹差不了多少。

我也遇到过某些比较特别的、喜欢做重复性劳动的、喜欢在已知领做工程开发的程序员，实际上这些程序员没有很好的职业素养，而且基本都缺乏上进心，朽木不可雕也。

三、重研究轻开发的中小型团队多数下场悲哀

但对于中小型团队，尤其是创业阶段的团队，如果只做开发而不做研究，运气好还能苟延残喘一阵子，养活团队估计还没问题；而侧重研究而没有开发，绝对是死路一条，结果就是工程师做完研究，砍完大BOSS获得经验值和等级的快速提升（我称为“镀金”）完毕后，已经把投资人的钱烧光了，留个废品给投资人，然后各自高飞。

比如一个创业阶段的小团队想做个很炫的UI框架能和iPhone媲美；或者想自己做个3D游戏引擎；或者想做一个矢量地图引擎。不仅多数程序员喜欢砍这种高经验值的大BOSS，投资人也很难挡住这种诱惑力。但如果不是在该领域已有很深厚的积累，而是在只掌握了一二成核心技术的情况下去做这种研究，试图把这种高风险项目做出来以获得高回报的话，那基本上等于找死。高度研究型项目对于中小型团队来说，就是投资人的高风险，程序员的高回报。

我就有过这方面的教训。本人天赋不咋地，04年底从零开始奉命研究播放器核心，死磕TCPMP代码，到07年自己写出一个播放器核心的时候，我这组人已经是换第三拨了，前两拨十几个兄弟都耐不住寂寞离职了。另一组人则有企业博士后带队，对MP3、REAL、H264的解码效率进行优化，研究也持续了两年多，换了两拨人马。最后这个播放器和优化了效率的解码器也没在手机电视市场爆发的时候为公司带来多少价值。还好是个大公司养着这两个“研究团队”，要是换小公司的话，两三年投入不出产品，早就死了。

四、研究和开发的资源布局
既然是R&D并提，说明两者基本上密不可分。做软件不可避免地、或多或少都会有研究的成分，而不纯粹是工程开发。所以出现下面两种资源布局：
（1）有的公司是把研究和开发任务混在一起，平均分给每个工程师；

（2）有的公司则把两者割裂开，有专门的精英团队做研究，有专门的工程团队做开发。

有些软件团队会有这样的追求：少数几个大牛搞定一个开发框架，然后用月薪两三千块钱大量招“代码工人”进来，快速开发出客户需求。这是一种“软件流水线化生产”的思路。当我们把这种软件公司的模式比作“中国制造”的时候，就发现这很有趣。这种模式在国内做企业开发（ERP、CRM、OA等）和网络游戏开发的公司中被广泛采用，实际上就是上面所说的第二种方式，建立两个团队分别做研究和开发。

补充: 网友评论中提到, 现在第二种方法是业界趋势，甚至工程团队中根本不用自己的人，向人力资源外包公司"租借"工程师来完成. 这使我想起华为、微软上海也是这么干的，而福州某家效益很好的软件公司能够用200名左右的项目经理和系统分析师, 管理2000多人的外包派遣工程师来做项目. 

这两种方式都有利有弊，前者会把核心人员浪费在体力活上，但有利于团队的“和谐稳定”以及从外围人员培养出新的核心成员；后者的组织效率会更高一些，但是由于阶级化明显，做工程开发的外围团队人员流失率会比较高，也不利于培养核心成员出来。

所以我认为，对于一个想获得成功的研发团队而言
（1）要想清楚研就和开发的投入比例。用虽然笨拙的已知方法替代对未知的、高效的、很酷的未知方法，在很多时候是必要的。项目风险必须处于可控范围内。我见过个数据，软件项目中的未知核心技术如果能占所需核心技术的20%以下，那么这个项目的成功率会大大提高。当然，这个也和行业领域的特点也有关系。
（2）要想清楚如何分配研究和开发任务。如上面所说，是分拆成两个团队单独做，还是把任务混合后平均地分配所有工程师。

评论: 14　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 邵晓锋调任阿里集团秘书长 协调子公司资源(2010-03-19 22:08)
· Notifo推iPhone应用：弥补邮件推送缺陷(2010-03-19 21:04)
· 分析：微软IE9现身 网络视频标准争议依旧未解(2010-03-19 20:57)
· 连线朱骏：陈晓薇离开九城与魔兽无关(2010-03-19 20:52)
· 九城总裁陈晓薇5月期满离任 朱骏将代理总裁(2010-03-19 20:48)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库

敏捷开发对于中小型项目还是非常适用的，不过我在实践过程中遇到两个问题:

1、重构 = 返工？

（1）需求和设计角度。

我对敏捷的理解，是允许需求人员在开发过程中不断地更新需求，而开发人员靠版本迭代来实现。迭代过程中，对于无法满足新需求的模块、以及前面迭代周期里性能不良的模块进行重构。从另个角度来讲，重构 = 返工，浪费了时间和人力。

如果有可能的话：

a. 还是要尽量让需求人员在项目初期就把需求定清楚，尽量减少在开发进行中进行重大调整的次数。不能因为敏捷了就放弃对需求制定的严格把关，想着反正迭代周期可以解决一切。

b. 设计中留下一定的可扩展性。这是个度，不同产品团队得自己把握。完全不留扩展性，在需求变更的时候往往不得不重构；而留下过度的扩展性，可能在前期浪费了大量时间而后面不一定用得着。

（2）项目后期、维护阶段的重构

我发现一个很有趣的事情，程序员一般不喜欢给维护别人的代码，给别人“擦屁股”。因此项目后期加入团队的程序员、和维护代码的程序员一般都会骂前任留下的代码如何垃圾，“需要重构”。实际上这是一个冠冕堂皇的陷阱。

一方面，重构后会出多少BUG还是未知数, 而且重新开发和测试并不能使客户掏出更多的钱为这些工作买单；

另一方面，重构后只是重构者自己后期做维护和开发轻松了，因为他在自己的代码基础上修改。对团队其他人来说，效率提升并不明显，因为他们需要重新熟悉新的接口甚至框架。

而最最严重的问题是，敢提出重构的程序员会认为自己的设计是最好的，前人留下的那是垃圾。因此即使他对代码重构过自己很满意了，一旦代码转手，这岗位上的下一任仍然会大骂垃圾并试图把这些代码再重构一遍, 然后只维护自己写的代码. 这会是项目进度控制和风险控制的无间地狱。
 

2、测试驱动开发

这里面有个很危险的陷阱。因为多数团队不可能把需求定得很细，需要在开发中让程序员和需求工程师边做边讨论细节，最后定下来，这种模式用图来表示是

需求 -> 测试

       -> 开发

传统的V字型结构，但这里的箭号方向表示了产品需求理解的传递路线和方向。而如果测试驱动开发的话，结果是这样的：

需求 -> 测试 -> 开发

也就是说，开发者并不直接去和需求打交道，其工作目的不是实现需求，而是让测试能跑通。这样就要求测试团队，尤其是测试经理要对需求有很强的理解力，并且在需求制定者和开发团队之间承担沟通的责任。而国内的普遍情况是，重开发轻测试。体现在测试人员的学历要求和薪水普遍比开发人员低，有些草班子甚至在项目计划中不给集成测试和DEBUG留时间。所以在这种现状下，试图用测试驱动开发的方法，隔离开了开发团队对需求细节的直接把握，让能力较弱的测试团队来做这事，基本上就是——找死。

评论: 3　查看评论　发表评论

找优秀程序员，就在博客园

最新新闻：
· 邵晓锋调任阿里集团秘书长 协调子公司资源(2010-03-19 22:08)
· Notifo推iPhone应用：弥补邮件推送缺陷(2010-03-19 21:04)
· 分析：微软IE9现身 网络视频标准争议依旧未解(2010-03-19 20:57)
· 连线朱骏：陈晓薇离开九城与魔兽无关(2010-03-19 20:52)
· 九城总裁陈晓薇5月期满离任 朱骏将代理总裁(2010-03-19 20:48)

编辑推荐：[视频]想做你的Code

网站导航：博客园首页  个人主页  新闻  闪存  小组  博问  社区  知识库