2006.11-2008.5

 

 

 

 

当我决定开始写下这些文字的时候，我也30岁了。但我不是苏鲁之（另一个译法“查拉图斯特拉”大家也许更熟悉一点），我只是个程序员，一个CMM2.5级程序员。之所以称自己为CMM2.5级程序员，是因为我曾经在具有“真正的”（而非我们惯常知道的那种冒牌的）CMM2级资质的软件公司工作过，并且经历了试图CMM3级认证但失败的过程，因此可以算CMM2.5级。

我知道有人会认为我是在将我的文字与尼采的伟大著作相提并论并因此强烈鄙视我，然而这完全是不公正的，我用这个引语作为开篇的原因仅仅是因为年龄的巧合。当然，我也非常喜欢这部作品，尽管九年来我从未真正把它读完过，羞愧啊。

“浮躁”。这是我脑子里出现的第一个词。

为什么我们总是那么浮躁？中国人的劣根吗？我甚至没有把《苏鲁之语录》读完！是否正是因此我没有办法做出一个足以令人自豪的软件？

工作了八年，经历了三个公司，从半国企到纯粹台资私企，又回到另一个半国企。经历过蒙人的ISO9001认证，也体验过真正的CMM2-3。经历过一些成功和失败以后，总有一些闲话想说……

我做软件的经历从大学毕业设计开始。毕业设计是为单片机编写程序，这一般算作硬件开发的一部分，作为物理学系应用物理专业的学生，以这样的题目作为毕业论文是很常见的。程序的代码量接近4千条，应该算是相当复杂的了。因为做的是产品，后续要留给其他人维护，所以写代码时非常注意可读性，所有调用点（相当于高级语言的函数）都有严格的说明，复杂一点的算法都有详细的解释，系统调度流程也有详细的流程图。我觉得当时的态度非常好，编写注释、文档的目的完全是为了让人看懂（让后续者以及我自己，因为汇编太原始了，过不了多久自己也会忘），绝对没有一点敷衍或浮夸的东西。这个产品当时卖得不错，后来几年还可以在学校的网站的物理实验仪器那里看到。工作了8年之后回头想想，那大概是我做过的最成功的东西了，真是一个讽刺。

工作以后很快转入VC开发，这就算是一个真正的程序员了。很幸运，刚开始业务不是很多，有比较多的时间学习。软件开发团队是新成立的，可想而知，当时的开发方式完全是自发的原始的，也就是我们通常所说的“作坊式开发”，一个熟练一点的师傅带上几个不太熟练的徒弟，问一下客户要做什么，然后闷头写代码，没有设计、没有测试、没有配置管理，等一下，“配置管理”？蔑意思呀？（广东话，啥叫配置管理？）

2000年公司（为了区别称之为X，后面还有T和P）准备过ISO9001质量体系认证，在经过短暂培训之后开始疯狂编写三层文件，然后伪造文档。软件开发依据的主要就是98版的国家软件开发规范。当时给了我一个任务，就是编写一个软件，以此作为认证的项目。由于项目是如此简单，以至于如何区分概要设计、详细设计、模块开发卷宗都成了问题，但最后还是把14个文件对付上了（根据开发规范，一个项目大致需要14种不同的文件）。说起来这个ISO9000认证现在早已如星火燎原一般燃遍大江南北，是人不是人的脖子上都挂一个“已通过ISO900X认证”的牌子。

       公司X选择的认证机构是资历比较深的。认证机构提供的培训师老太太课讲得不错，她跟我们讲他们当初去美国受训的时候，美国鬼子轻松地说“9000认证很简单嘛，把管理制度拿出来整理整理，看哪里不足完善一下就行了”，Oh！仁慈的上帝，请不要责怪他！他们美国小孩玩过家家的时候都会用流水线生产早餐，他们怎么会理解我们这些昨天才拖着泥腿子从田里上来的农民啊，那14个破文件差点把我折磨死了！

公司认证的时候来的认证师是个老头，当我们把我们的三层文件恭恭敬敬地呈上，老头把这一摞文件往旁边一推，说我们看这个就行了——拿出一本《国家软件工程开发规范》。老头还很有道理：你们企业的文件不管怎么定，都不应该违反开发规范。得，几个月的辛苦白费了。然后老头开始审问我，我这个人实诚又胆小，怎敢欺骗政府呀，大多数问题我都老老实实回答einei jodea（知道这是什么意思吗？“我不知道”，回答正确！加十分！它的意思就是“我不知道”，恭喜你，你的希伯来文水平不错，去以色列旅游不用带翻译了），于是这个可敬的老头就开始了伟大的软件工程普及工作。看我比较虚心，又能够领悟，老头很满意，给我们打了合格（我知道你们想说什么：这其实是旅游、吃饭和现金的功劳，跟我屁关系没有，大声地说出来吧，我不介意，嘿嘿）。这就是我这个半路出家的程序员的软件工程启蒙。

以后的日子项目就多了起来，尽管业务发展得不错但实践软件工程的企图总是以失败告终（不是我一个人，其他一些同级的小干部们也在做着努力，我想，那时候我们都怀抱理想……）。我们多次提出要求建立专门的测试组，然而这样的要求也不能被满足，领导完全不能理解为什么程序员自己不做测试而要把责任推给别人！现在看来，建立专门的测试组这样的要求在内地软件业中已经是很奢侈的要求了，大多数软件公司都没有像样的测试（因此只能提供勉强可以接受的产品质量），在我写此文的此刻建立一个独立测试组正是我即将谋求的目标（在公司P的一个大项目里）。

应用版本控制的企图在开始时不是很强烈，因为项目规模都不是很大，参与的人比较少。后来有了一个比较大的项目，十几个人在一起干活，以PB为主，部分需要用其他开发工具，我终于有机会把测试定为一项专门的工作，只不过测试人员同时也要做非PB的开发工作。有了专人测试代码中的更多BUG被发现了，同时也很快发现了版本控制的迫切需求——有些人经常提交错误的模块版本（害怕改坏了东西，于是在本机上保存有多个拷贝，这是很常见的做法。于是有时搞不清楚到底哪个是正确的拷贝）。

在这种情况下我开始考虑使用VSS进行版本控制，但由于两个原因最终没有使用VSS，一方面VSS是英文版而版本控制又是初次接触，掌握起来并不容易，另一方面，另一个方面是由于一个相当愚蠢的原因——公司网络里病毒很多，有些家伙拒绝安装杀毒软件，理由是会影响打游戏的速度！而VSS要求完全共享目录，没法在这样不安全的网络中运行。

最后采用了一个手工模拟的方法：源代码由我统一管理，我共享一个只读目录发布最新源代码，其他人先拷贝最新源代码到本机，改完后用BQQ（企业QQ，腾讯的杰作，我所遇到的的中国人写出的最好的软件之一，后来改名叫RTX）发送改过的代码给我，我会对代码作出检查，然后放入发布目录，当然我也会对每个版本做备份。

这个管理方法是卓有成效的，现在来看完全符合基本的版本控制原理，而且由于项目负责人（也就是我）的直接介入大大加强了管理的有效性——这里不是在自我吹嘘，我要表达的是我对管理的一个认识（实际上，对于公司T那样有严格过程管理的公司来说，这里采用的办法不过是一个小聪明而已）：没有人的介入，一切自动化管理方式都是徒劳的。比如上班打卡，如果没有行政人员据此扣你的薪水或迟到报表不会上报给老总的话，没有人会去理睬那个丑陋的小盒子。当采用了这种方式以后，效果非常明显，编码效率和代码质量都大幅提高了。

 

我在公司X的软件工程经历仅止于此，此时我仍然没有弄明白什么是“配置管理”。很不幸，2003年由于政治原因公司X发生了巨变，我指的是国企改革引发的事情，懒得提起了，总之结局是我们都离开了，这绝对不是一个愉快的结局。恰逢台资公司T正在大幅扩张，于是我们都去了公司T，当时的过程是有几个人先后去，最后我才过去，绝对不是集体跳槽，过去以后我们还是一个组，小组里面还有几个不是来自公司X的人。

公司T的老板是台湾最有脸面的几个企业家之一，50岁以后开始专注于社会事业了，这个公司就是他出资办的兼顾经济和社会效益的企业，也出过书，经济发展方面的。我猜他应该算是深蓝台商吧，党中央是很欢迎的，他还上过CCTV的专访，可惜我去的当年就英年早逝，可惜啊！

公司T给我的最初的强烈印象是法律上的严谨（法律的严谨当然是行政制度严谨的一个表现）。

到公司T上班的第一天早上先签合同。我们都知道内地大多数企业都不喜欢签合同，干好几年没有一纸合同是很正常的，我们也知道法律上规定试用期结束就应该签合同——错了！实际上，法律上规定的是合同应该在第一天上班就签署，当然试用期内可以随时终止合同而不需要赔偿。

然后我发现在对待职工的保险的问题上他们是积极的，作为对比，我们知道多数企业对于职工保险支出是能拖则拖、能少则少，不签合同也与此有关。

公司T企业缴纳的养老保险的比例高得吓人，可以这么说，这个公司一年为我缴纳的养老保险的钱比公司X几年为我缴纳的都多（实际上头两年根本是没有的）。

由于当时尚未允许台资企业参与医疗保险（注：公司T名义上是外资而非台资，在逃税天堂注册的），公司就根据工资的一定的比例计算出医疗保险费用直接计入工资，等政策允许后就办理医疗保险，而半国企公司X并没有为我们办理医疗保险，而只是每月定额发放医疗补助。

公司T也提供失业保险，而半国企拒绝为我们缴纳失业保险的理由是“你们都是高学历不用担心失业嘛”。失业有快感，嘿嘿嘿嘿。

我们知道国企有很多的难处，国企要承担要承担很多的社会责任，更准确地说是要承担很多社会负担。我能够理解国企的难处，但我更希望理解外企为什么就不难。

公司T的行政人员看起来很辛苦，他们加班的时间一点也不比开发人员少。我并不完全清楚行政人员每天都要做些什么，但我至少知道他们为我做了什么。在我第一天上班之前他们已经为我准备好了工牌、工号、座位牌，指纹已经采样（考勤用的是指纹机，第一天就要考勤），第一天上班除了签合同、公司历史、部门结构、业务等的培训就是安装电脑，电脑安装好以后所有的办公系统帐号已经开通，邮件已经开通，并且收到了若干邮件包括全公司的迟到报表，而我的名字赫然在列——我迟到了！仔细一看，不对呀，怎么把我列入了天津办事处，原来行政人员搞错了，把我放在了天津办事处，而天津办事处比其它办事处要早半个小时上班。经过邮件申诉，更正后的迟到报表很快就发了出来，没有我的名字了。以后每天早上十点钟左右就会收到当天的迟到报表，由于交通问题，迟到总是难免的。迟到的坏处是向福委会（福利委员会）上缴拾元钱，现金，而好处是有望获得年底的福委会特别贡献奖（当年该奖由一位迟到次数最多、也就是上缴罚款最多的同仁获得）。

 

好的制度并不减少错误的发生，但提供了好的发现错误和纠正错误的机会。ISO90001质量保证体系并不担保生产出合格的产品，但在发生不合格产品的时候能够发现错误发生在哪里。CMM（软件能力成熟度模型）担保你有能力做出好的软件，但不担保你做出好的软件。

公司T的组织结构很独特，有三个主要办事处，分布在相距数千公里的三个城市，另外还有一个次要办事处，也在一个不同的地方，而公司的部门设置与地域无关，每个部门的员工都会分散在几个不同的办事处，因此非常依赖网络通信，包括视讯会议系统、电子邮件系统、网络办公系统，小规模的两地视讯会议直接通过net meeting进行（所用的功能也就是视频聊天和应用程序共享），大规模的视讯会议比如总裁例会、部门例会、项目的评审会议等则要到会议室使用专门的视讯会议系统进行。

 

公司非常依赖电子邮件系统，多数工作联系都需要通过电子邮件进行。电子邮件的抄送规定是同级抄送、向上抄送三级，这意味着一个最低层发起的邮件必须抄送给同组所有人并向上抄送到部长（也就是我们所说的部门经理），而部长发起的邮件则要抄送到总裁办。邮件答复的时候还要选使用“全部答复”，不能只给一个人答复。这样的规则看起来真是太过分了，完全没有隐私了，然而实际的执行比制度更过分，反正是要抄送的，于是为了省事直接选择一个大到能够包容全部需要抄送的人员的组发出去，比如整个办事处。SQA（软件质量保证部）的MM们最爱干这种事，她们的工作总是涉及到不同的部门，从不同的部门选择接收对象是一个比较令人厌倦的过程。每个人每天能收到的邮件也许会达到几十封吧，如果一早晨都没有邮件，我们就可以大喊：网络故障啦！

 

也许很多人认为这是另一个极端：过多的邮件会干扰工作，《人件》也这么说。我想好处总该比坏处多，毕竟你可以自己控制什么时候去看邮件，关掉邮件客户端也可以。

公司的网络办公系统是自己开发的，公司有专门的小组负责维护，只要能上网就能使用。比如请一个两小时的特准假（不需要扣钱的），只需要登录OA系统，填一个请假单就行了，上级自然会看到，然后会批准或驳回。别的事情也是如此，一切都很简单，不用拿个单子到处跑（还经常跑空腿找不到人）。因为某人出差或休假而耽误事的情形是甚少或者不会发生的，因为每个人出差或请假他的职责都会有代理人替他履行。我们曾经申请一台用作服务器的电脑（个人用的电脑上班第一天一定会领到，否则就是资产部门的失职），半上午填了单子，半下午我们就已经在安装系统了。我们知道买电脑这样的事情是很重大的，需要逐层审批直到老总，还涉及到资产和财务，而且还要上街去买，这样的速度毫无疑问是无可指责的——恰当的形容词也许是“难以想象”。

像OA这样的东西那几年是个风潮，公司X也做过，给自己做也给客户做。从技术角度讲，公司T的OA所用的技术和实现的功能并没有什么特别的地方（作为量身定做的系统，它完全符合公司T的制度，或者说它就是制度的一部分），作为一个旁观的技术人员很容易找到它的缺点，比如整合性不足、部分功能的操作很繁琐，考察过源代码以后，代码设计、编码水平也很一般。为什么公司T的OA是一个有效的系统而公司X（以及它的客户）的OA不是？显然技术因素与这个问题基本没什么关系。

 

公司X为自己搞OA的时候下了很大的力气，用了好几个人到各部门作了调研，然后开发了一年，做出了很多功能模块，然后在全公司安装培训，然后得到很多抱怨不好用、不能用、不合乎公司要求等等，很快不了了之。我注意到了一些促成这个结果的因素，比如开发者更关注软件本身而非用户需求（这里的用户就是其它部门），认为只要软件是“可以用”的用户就应该愿意使用，于是将问题归结于用户不愿意使用，实际上，需求分析普遍存在着只关注功能而不关注用户操作的现象，导致软件产品的确实现了功能却无法使用（在公司T，我知道了界面设计是需求分析阶段的工作）。作为一个运转良好的公司（那个时候简直可以说是蒸蒸日上），缺乏变革的动力，既然现在的方式已经很有效，又何必费神去使用一个新的系统呢？（当然并非完全没有现实的需求，可惜的是业务部门提出的希望解决的问题过于专业、过于复杂，实现不了。）公司的态度，或者说更准确地说是老总的态度，并未把新系统当作公司管理方式的一部分，没有强制必须使用新系统（显然这是要老总带头执行的），谁会去主动使用一个没有足够优势的新东西呢，这样，新系统就被边缘化了。

做出一个好的软件需要出多少个版本？据说是3个。很多软件都是3.0才成功的，比如DOS3.0、Windows3.0。WindowsXP的版本号是5.1，Oracle出了10g，Norton AntiVirus 甚至到了11（即2005），也许你还知道一些更大的版本号。我从没做过3.0版的软件。在缺乏经验的情况下，第一个版本不如意是很正常的。我们已经知道，对多数应用软件来说，技术从来都不是障碍，最关键的是需求。我们总在需求严重不足的情况下开始设计，然后四处推销一个很不好用的东西。我们曾被用户抱怨需求调研如“蜻蜓点水”。在系统已经成型的情况下，没有人肯推翻旧的设计重新来过，重构需要太多勇气。我们还不肯认错，不肯承认设计失败，于是我们要把错误坚持下去。我曾经经常这样调侃我们的项目：如果你做了一个茶杯下面有个洞，没有人会承认那是茶杯，因为它明明是个花盆——但是软件可以，慢慢补嘛！

 

ISO9000质量保证体系是一系列标准的总称，9001、9002、9003所涵盖的过程不同，9001涵盖了设计开发到生产全过程（也许还包括销售？），是最全面的，但并不意味着9001比9002严格，它们都是同样严格的。具体采用哪一个标准取决于一个企业的实际需要，对于一个从不设计新产品的专业代工工厂就没必要采用9001标准。（声明：本段文字纯属瞎掰）

“说你所做的，做你所说的”，其实质量管理的精髓就这么简单、就这么朴素。或者换一个说法，就是一切都是有据可查的。我们经常以为质量保证就是要不出次品、百分之百合格，其实质量保证并不保证不出次品，质量保证保证能够发现是哪个环节产生了次品。

我们经常以为机械化带来了高质量，但这完全是错觉。最精密的零件是机器打磨的还是还是手工打磨的？大多数人都会回答错误的。机器永远不如人手精密。使用机器的价值在于机器可以快速、稳定地生产较好的零件——仅仅是较好的，最好的仍然是手工产品，比如一辆宾利或劳斯莱斯。

手工产品可以达到无限高的品质，就像一个艺术家突然迸发出巨大的灵感，很短的时间内一幅惊世骇俗的作品就产生了。然而每个月的大多数时间这个艺术家在做什么？蓬头垢面，像个乞丐一般四处游荡、无所事事。你知道他有灵感，但你别指望控制他在什么时候有灵感。

编程是艺术还是苦力？

我经常用编程的方式享受艺术创作般的快感。

在思考很多天甚至一两个月以后，在数天之内以绝对的专注完成一个精彩的功能，或者完成一次复杂的重构，带来系统品质的提升，这种快感是艺术性的。由于这种艺术性，这些工作通常都没有（也是无法）被列入工作计划，只有在完成以后才被列入工作报告。

我也经常做苦力。解决复杂度不高但各不相同的需求，处理各种故障，一遍一遍地修订文档。

我思考这两种工作的价值。艺术灵感提升了产品的品质，苦力生产和维护产品。一个绝佳的艺术灵感可以极大地改变产品的面貌，然而大多数工作仍然是苦力。

我是否有勇气把我的重构设想（重构是一项需要相当的勇气的工作）列入工作计划？有时候一个想法在思考数周以后最终放弃了，有时候则在不可思议的时间内就漂亮地完成了。麻烦的是，我会在什么时候开始做完全取决于——心情。所以这完全没有计划性，如果强迫做计划，恐怕只有放弃了。

是艺术还是苦力？过度严谨的工作计划消磨了艺术创作灵感，无法产生令人惊叹的作品，但可以稳定地生产出一般产品。例如公司T的过程管理就是如此。在每天的工作日报中如何体现思考的价值？我的方式是开始时根本不记入日报，只在有产出的时候（比如一份技术方案）才酌情记入日报，这样的日报是不真实的。

有多少程序员是艺术家？有多少程序员是建筑工人？很遗憾，我看到的“艺术家”的比例绝对不比现实的艺术家的比例高，一群建筑工人打着艺术的牌子为自己的散漫寻找借口而已。

我们知道数据库设计有五个范式，一般设计到第三范式就很了不起了，而为了性能考虑做到第三范式以后还要反规范化，破坏范式来达到性能提升。在这个过程里正确的步骤是先做到第三范式，然后反规范化得到二点五范式，而不是一开始就以二点五范式为目标。在艺术还是苦力这个问题上，我想道理与此类似，我们首先要保证苦力们能够规规矩矩干活，然后给艺术家们一点点宽容、一点点自由发挥的空间，而不能让苦力们搞资产阶级自由化。

公司T当时的计划是做软件外包，因此必须通过CMM3评估。我去的时候已经通过了CMM2评估，CMM3所需的制度已经基本制定好，因此我们的项目是完全按照CMM3的要求进行的。

我所在组负责开发，QC负责测试，SQA负责跟踪项目过程。QC的测试计划从一开始就与开发同步进行，测试点与需求规格说明书一一对应。

我负责编写需求规格说明书，我就是此时才知道界面设计不是设计阶段的产出而是需求阶段的产出，需求LIST才是以前理解的需求。规格说明书要详细定义产品的外观和行为。这样的好处是需求规格不管交给谁最后的产品的外观（界面、操作方法）都是一样的。这里的规格（spec）就是工业意义上的规格。据说日本人的规格说明书一个界面就是一寸厚的文档，每个文字的字体、大小、色彩都会严格定义，听起来相当的恐怖。后来我在公司P也曾尝试过向编码人员提交过这样需求规格，结果被认为太过分、完全禁止了开发人员的创造性（我有什么感想？看上一节的观点）。

之前的文字大多数写于2006年11月，最后修改日期是2007年6月3日，到今天（2008年5月4日）差一个月就一年了，这也说明我的确缺乏耐心。我决定继续写下去，看看这一次能写多少。

05年写的VSS指南被转载的很多，也算一点成果吧。不过很多都删去了作者以及致谢和结语，大家都是这样了，没办法。

公司X苟延残喘了几年，好人坏人都各寻出路，据说已经挺了过来，似有起色了。与我无关。

公司T放弃了做软件工厂的目标以后只保留了很小的摊子，但一直在继续。这是一个与众不同的公司，它的理念不只是赚钱，还有关怀和梦想。

公司P并入了公司Y，国企就是能折腾。

在公司X的时候我曾经参加过一个CMM培训，记得老师说CMM不是一个认证，只是一个评估，评估结果是不会公开的，也没有什么证书可发。此事待考。

CMM3的会就是多，几乎天天开。说实在的，大多数会议都很无聊，与会者因为缺乏知识或经验而不能提出问题，或者陷入无益的争吵。作为一个用来认证的项目，项目本身并不复杂，主要是练习过程。参与者是否具备所需的能力是项目启动时必须要考察的，所有的参与者都必须具备或通过培训就可以具备所需的才能项目建议书才能通过。

大多数会议都是评审会议，因为大多数文档都需要评审通过才能生效。因为开发周期和人员素质的问题，部分评审只是走了过场。尽管如此，评审仍然起到了相当大的作用。

最最起码的，改变了你的态度，当你知道你的东西要被充满敌意的竞争部门QC审核和提问的时候，你无法拿一个自己都不知所云的东西出来蒙混。

QC从立项开始就参与进来，然后从需求开始编写测试用例，研发的每一步都有对应的一套测试用例，他们也要参与绝大多数的评审。研发每步的产出既是研发下一步开发的依据，同时又是QC测试的依据，所以QC参与评审的必要性是显而易见的。

当然，只有公司T把测试搞得这么复杂，在公司X和P，根本没有测试这个环节的，in fact，我们根本不区分环节。

QC部门的测试人员都是刚毕业的，没有软件开发经历，甚至并非软件相关专业。这是一个坏处。他们会提出技术上不可行的要求、或者在一些技术问题上纠缠不清，沟通起来障碍很多。

但是这实际上是一个好处，因为他们更接近真实的用户。开发人员经常以为自己很专业，认为自己比用户更知道用户需要什么，实际上我们太自以为是了。

非专业的测试人员提供了最接近用户的测试。因为他们不专业，他们就只能关注用户看得到的东西，他们只从业务角度来看，不会为了实现方便而扭曲业务，他们不会想到你为这个按钮写了多少代码，他们只会注意到点击以后为什么长时间没有反应，他们不会理所当然地认为一定要按照1、2、3的顺序去做，他们不会照顾你的心情，不行的就是不行，决不会妥协，因为他们的工作成果就是用BUG数量来衡量的，而放过BUG就是他们的失职。

我经常惊讶于他们发现BUG的能力，他们发现了很多我认为我们自己一万年也不可能发现的问题（尽管他们也发现了很多在我看来属于吹毛求疵和故意刁难的问题）。我自己做过很多测试工作。在公司X负责项目的时候我亲自管理版本和测试，我实在无法信任别人，只有我亲自来做才能放心，可是一遍一遍地运行相同的东西的确是极度令人厌倦的工作。

测试是如此枯燥的工作，是什么原因让他们如此敬业？我想是因为“BUG记录表”。当BUG数量成为衡量工作成果的标准以后，寻找BUG就不再那么令人厌倦，而是充满挑战和成就感的事业了。就好比任何一个掌上游戏，比如俄罗斯方块，如果没有分数和级别，还会有什么乐趣？俄罗斯方块还算复杂的，更早期的更弱智，比如一辆汽车左右闪躲（不是极品飞车啦），除了玩的人自己看的人是一点兴趣都没有的。在公司T这个项目里我也做内部测试（RD测试——开发部门自己的测试），在有了BUG记录表以后，我也开始感觉到测试的乐趣和成就感。对比其余的软件公司，通常对测试缺乏管理，没有明确的测试要求，因此测试效果不好（实际上，根本没人意识到需要独立的测试环节）。

没错。CMM1-5一共18个关键过程域（KPA），不包含测试。这是公司T为CMM3评估做的准备会议上QC的同仁提出的问题。

我的理解是，测试是如此的基本，就如同吃饭穿衣一样，不需要强调。这也是后来我认为我们大多数软件公司不是处于CMM1级（初始级，原始开发，没有过程控制，没有KPA）而是处于0级的原因。美国人就是有先见之明，预留了0级给我们用，哈哈。

我所学到的测试理论基本都用在了自己身上，好处不是那么显而易见的，因为很多人无法区分良好的睡眠和凌晨两点被电话中断的睡眠。

呵呵，其实测试部门QC是CMM唯一一个要求必须独立存在的的部门，你说测试重要不重要？

另一个重要部门软件质量保证SQA通常也是独立存在的。

SQA就是一群可爱小MM。

SQA——软件质量保证。怎么个保证法呢？就是检查你有没有按照规定步骤工作。

怎么才算是按照规定步骤工作呢？就是遵守《作业指导书》。

《作业指导书》是什么呢？就是完成一件事情的规定步骤。

哪些事情需要《作业指导书》呢？立项、开发、送测、成版、请假、借款、申请电脑、开会……太多了，大事小事都有作业指导书，我还是说说什么不需要作业指导书吧，这样应该容易很多……

我没有看到《如厕作业指导书》，但是据说总经理对本办事处的手纸使用量不太满意，不知道后来有没有出《如厕用纸作业指导书》……

（呵呵，幽默一下，但也许并不是个幽默，我对流水线并不是很了解）

言归正传。每个项目都配有一个SQA，负责监督我们是否遵循了所有的流程。她（绝大多数都是小MM）会列席我们所有的会议，监视会议通知是否按时发出、到会人员是否符合要求、会议过程是否完整、会议报告是否合格、各种文档是否齐全、是否经过评审等等，她会检查进度是否符合计划，还会抽查代码是否符合编码规范，她天天打小报告揭发我们的问题点。

管理就是给人找麻烦。我烦别人给我找麻烦却又找别人的麻烦。

我对SCM和VSS的很多感想写在了05年写的VSS指南中。SCM和VSS应该是软件开发管理的最初级的东西，也是我后来竭力推广的东西以及仅有的获得了一点成果的东西——在公司P，我把VSS推广到了项目的部分小组。

我开始以实际行动推广软件工程与某个人有关——哦，在这个系列文章里，只谈软件。

我初出茅庐的时候经常跟人争论中国的软件业到底缺技术还是缺管理。有人说缺技术，有人说缺管理。说缺管理的人多一些。

我个人看法开始认为缺管理，后来认为两个都缺。

这个事情不能纯粹看各种观点的支持率高低，要做心理分析。

为什么说缺管理的人多呢？因为技术论坛上都是做技术的，说缺技术不就等于说自己技术差吗？在纯粹管理者的论坛上恐怕会得出完全相反的结果。有些管理人员也会符合这种观点，因为他不懂技术，他需要技术人员来解决问题。

公司T就不怕技术人员，因为过程管理得好，都落实在文档上，又有评审，想成为不可或缺的人物？你就做梦吧，随便换个人就能把你代替了。唉，自己都觉得好伤人啊，大家都是程序员呢。

ISO9000早就泛滥成灾，CMM还好，还没变成萝卜白菜，不过情形也好不了多少。扪心自问，这些证书与企业管理有没有哪怕最小的一丁点关系？不都是请客送礼搞来的？连测试都不做，一个任务分给一个程序员，从需求做到维护（如果他能区分需求和维护的话），这也叫管理？

至于技术，做C++的还好，关于C++编程理论的书籍很多，程序员难免会看到一些，会研究学习一番，所以我看到的C++程序员中还有一些具有一定甚至较高的技术水平，而那些使用快速开发工具的，绝大多数没有能够超越前三章的水平（I means，看过任何一本教程的前三章就可以达到的水平）。我对快速开发工具的研究主要在于了解其功能，动手则只需能够阅读代码、编译程序就可以了，你还不如我，这点水平，有资格谈论缺技术还是缺管理吗？

当我刚达到VC前三章的水平，就开始有人称我为“高手”，学了三个月VC就是高手？羞愧得很呢。后来当然越学越多了，经验也多了，现在有了问题在互联网上搜索不到答案的次数也越来越多了，有些觉得自己蛮高了。可是还是不断发现新东西需要学习，而且越来越难学，啥时候才是尽头呢？

恩啊，有点自夸了。我的技术成长之路前半截与某个网站是分不开的（后来去的少了），上面可以问问题，也可以回答别人的问题，是个非常好的场所，而且都是程序员。我从里面学了很多东西，很多人都很热情，热衷于帮助别人解决问题。然而有些人就不高兴了，觉得别人都很白痴，要求不准发白痴问题，要先搜索，能搜到的就不准问。

听起来蛮有理的，但是——白痴问题自然有白痴来回答，你高手不屑回答你别回答呗（大话西游：懒得理我就别理我呗，干嘛打我呢？）。如果能够找到答案就不可以问人，那还要老师做什么？图书馆里自有一切的答案。你那些所谓的高明的问题在整个互联网搜索一下也该有答案了吧？

更进一步的是，有人开始把这里当成他的私人会所，妄图规定所有人的行为规范，这个规范引发一场论战，造成很多人负气出走。Include me.

再说一遍：我最烦别人规定提问之前要先搜索，这种网站我一律不去！

我是98年上半年大四第二学期知道LINUX的，同学说他的实验室的师兄从美国带回来了原版LINUX，是整个学校的LINUX的来源，他跟我吹这个东西多么好，还可以免费使用源代码（那个时候的Windows确实稳定性很差，不过是老黄历了）。

后来毕业后98年底自由软件这个概念正式登陆媒体，出现在大众面前。99年开始中文LINUX如雨后春笋般涌出，第一个叫做XTeam，冲浪平台公司出版，他的安装界面（好像是1.2版）的某一步写着“请选择CD-ROM的型号”，下面的列表列出的却是各种网卡，蠢不可及的错误。其他的中文Linux还有蓝点、红旗等等一大堆。不过是重复了中文DOS的老路，在别人的东西上套个中文字体和输入法而已。具往矣，数风流人物，还看RedHat。

都说Linux稳定，但是我的RedHat 6.0的图形界面仍然有过死机的记录，硬件是HP品牌PC，结实着呢。

我必须承认，我那几年很热衷于研究Linux，自由的理念感染了我。

然而后来我终于认识到，这根本与政治如出一辙：

如果你能理解政治，你就能理解我的观点。如果你不能理解政治，你就不能理解我的观点。因为这等同于我的政治立场，所以我不说。

 

I have a dream …

(The End)

后记

写后面这一些的时候恰逢四川5.12大地震，举国哀痛。我想绝大多数人都做了自己认为应该做的事。略有一些感慨，记在下面：

 

依然是黑夜

是谁让孩子们在没有钢筋的教学楼里上课

5万条生命能不能换回某些人的良知

我看到人们在踊跃捐款、鲜血

我也看到某些人在仍然在做秀

我们慷慨解囊不是因为爱国、不是因为爱心

而是出于人性互助的本能

高唱爱国的人可以停止了

事实已经证明

爱国不需要宣传

我们诅咒

——谁贪救灾款天打五雷轰

可是

他们是无神论者

他们不相信因果报应

依然是黑夜

但我们不会放弃努力

我们不会熄灭手上的灯火

每一盏灯照亮一小片天空

让多几个人看到希望

路，一直都在那里

因为是黑夜

所以我们点亮灯火