01大道至简阅读笔记之一

前言

---

做了许多年的开发，其实很多的人并不知道“自己在做什么”。

注：我自己在做什么呢，业务没多少长进，对行业测试工具行业、软件行业都没有什么了解；技术也没多大进步，整天都是在架构、多线程、C++语言上纠缠。以后再去找工作的时候，我能有什么定位，有什么亮点呢？

---

所以你需要认识“为什么做”。

这其实并不困难。例如我在工程中经常问的问题是“可不可以不做”--哈哈，看起来我很偷懒似的。其实不然，因为接下来我就会从不同的人那里得到“非做不可”的种种理由。

注：“可不可以不做”这个问题我倒经常在问自己，看起来我也很懒。我还是比较赞同这个观点的，在做什么事之前都问问这件事是不是我必须得做，如果不必我何必浪费精力呢？！！！

现在的项目（SIP+RTP）,我就做了不少可以不做的东西，心里很不爽，要是我是组长肯定不会做，这些细节根本没有什么价值，还花那么多时间去搞，吃饱了撑着！

今天在SourceForge上查看sipp资料时，发现别人什么东西都有了：图形化流程封装、从抓包到场景，图形化界面等，我们现在做的，能比别人的好吗，做出来能有什么前途吗，上半年绩效沟通的时候，向项目经理提出我们的东西和sipp相比有什么优势，他的意思也就是让我忽悠，我们能一直忽悠下去吗？！不做，那么可能就没事可做，做，又做不好，此时问“可不可以不做”，该怎么决策呢？

答：在后面有答案，即不管什么时候，特别是你无法控制的时候，首先必须心态积极，虽然项目没成，但是得到上司的认可也不错！

第一章 编程的精义

第一节 编程的精义

---

在愚公的论述中，我们看到了编程的根本：顺序、分支和循环。庞大若“愚公移山”这样的工程，都是可以通过这样简单的编程来实现的。这，就是编程的精义了。

第二节 能不能学会写程序的问题

---

所以除了先天智障或后天懒惰者，都是可以学会写程序的。

第三节 程序 = 算法 + 结构

---

编程作为一种行为时，我们只需要知道其逻辑方法就行可以了。所谓编程实际上就是把一件事情交给计算机去做，你认为这件事该如何做，就用“程序语言”的形式描述给计算机。如果你原本就不明白如何去做，那么你也不要期望计算机去理解你想要做什么。

在SIP+RTP中实现mark拖动时，我对这句话深有体会，在编码以前，一定要先用自然语言描述好逻辑流程，否则到后面自己都搞不清楚哪儿有问题，到处都是缺陷！

所以编程的第一要务是先把事情分析清楚，把事件的先后逻辑关系和依赖关系搞清楚，然后再去写代码实现。一接到任务就开始Coding的程序员，通常就是加班最多的程序员。

记住：积极工作和勤于思考都要占时间。

第四节 语言

---

任何一门语言，你都可以在两周内掌握并开始熟练编程。因为任何一门语言，它们的底层函数库都是那样地相似，它们的API都是那样地依赖于操作系统。

---

成天讨论这门语言好，或者那门语言坏的人，甚至是可悲的。

第五节 在没有工程的时代

在没有工程的时代，上面所说的就是一个程序员的全部。他们掌握了一门语言，懂得了一些生活中最常见的逻辑，他们用程序的方式思考和学习了一些算法，并根据前人的经验，把这些算法运行在一些数据结构之上。最后，我们就看到了他们写的程序。

注：难道我目前就处于这个阶段？呜呜

第二章 是懒人早就了方法

第一节 是懒人早就了方法

第二节 一百万行代码是可以写在一个文件里的

---

勤快的愚公创造不了方法。这我已经说过了。对于要把“一百万行代码写到一个文件里”，并且查找一个函数要在编辑器里按5000次PageUp/PageDown键的勤快人来说，是不能指望他们创造出“单元文件（Unit）”这样的开发方法来的。

注：要是我够懒的话，我能把性能测试自动化起来吗？感觉要是做出来了的话，一定很爽，对于以后的测试很有借鉴意义，可以思考一下。

第三节 你桌上的书是乱的吗

---

我当时便反问他：“你既然知道如何把书分类、规整得整整齐齐地放在书桌上，那怎么没想到如何把所学的知识分类一下，归纳一下，整整齐齐地放到脑子里呢？”
我是不是也应该将学的知识分一下类呢？我目前也是不知道自己会些什么

答：

（1）会c++,java
（2）会用STL
（3）稍微了解一点Windows操作系统
（4）稍微了解一点Linux，还未在Linux开发过项目
（5）了解C语言
（6）会调试自己写的程序
（7）了解一点架构知识
（8）了解一点面向对象设计知识，但都没有形成经验
（9）了解一点软件工程的知识，比如CMM等
（10）了解一点数据库知识
（11）了解一点电信知识
（12）基本没有和同事，客户，下属，领导之间进行沟通的技巧

---

如果一个人学了一年的编程，他的脑袋里还是晕乎乎的，不知道从哪里开始，也知道如何做程序。那想来只有一个原因：他学了，也把知识学进去了，就是不知道这些知识是干什么的。或者，他不知道各种知识都可以用来做什么。

第四节 我的第一次思考：程序 = 算法 + 数据结构 + 方法

---

我第一次提到我对程序的理解是“程序 = 算法 + 数据结构 + 方法”，就是在这一次与Soul的交谈之中。

---

而与“面向对象”是否出现完全无关的一个东西，却因为“过程”和“单元”的出现而出现了。这就是“工程（Engineering）”。

第三章 团队缺乏的不只是管理

第一节 三个人的团队

---

做管理起码要能承担责任，这是最基本的素质。

谁都害怕承担责任，我也是！我能否习惯敢于承担责任呢？能否习惯敢于承诺呢？比如将sipp用C++改写，我为什么就是不敢承诺我一定能在1个月内完成呢，要是能这样，估计能在经理面前博得一个好的印象！承诺后我估计还有可能完成，不承诺，基本上没有完成的可能性。

---

同样的道理，你的项目经理职位又没有让给别人做，你拿的经理级工资又没有分给别人，那项目失败了，你为什么要把责任推到别人头上呢？

三人团队中的那个领导，不是要程咬金一样的牛人，而是要李离一样的死士。项目完成不了，切脑袋的事倒不必做，递交辞呈的那点勇气总是要有的。

第二节 做项目 = 死亡游戏

---

从管理的角度看，项目失败与否与项目经理的经验直接相关。我曾经听过一个澳大利亚的讲师说软件工程。她说项目的成功是由两个方面来评估的：

项目完成质量；

项目完成时间。

由于项目的完成时间是在项目前期对项目工期的设定，因此我问这个讲师：什么方法能保证预期的工期是正确的，或者说是可以完成的。

讲师的回答很有意思：经验丰富的工程师能尽可能接近地预估工期，但没有办法保障（预估的）工期是绝对合理的。

---

项目经理的需要时间来成熟的。他需要机会来承受错误，而不是一开始就享受成功。

这稍稍对我的sip失败找到了一点逃避责任的借口，呵呵！

第三节 做ISO质量体系的教训

---

皮之不存，毛将焉附。没有确定的组织机构，又如何能指望做出来的管理制度“合用”呢？

第四节 谁动摇了你的制度

---

我们先来看看，如果员工在工作中出了纰漏，那么：
没有制度，你没有办法和依据来惩戒员工，因此是管理者的过失；
有了制度而没有惩戒他，是执行者和监督者的过失；
一而再、再而三地犯错，又一而再、再而三地被惩戒，那就是教而不改，就真正是员工的品性和素质的问题了。

---

所以，在更加普遍的情况中，动摇了制度的人往往不是犯错的员工，而是管理者自己。如果在制度面前，既做得到“人性化”，又做得到“公平性”，那么当管理者的便可以多做几次黑脸的包龙图，而脖子上的脑袋便可以比李离顶得长久一些。

如果是在sip项目中，具体应该怎么操作才好呢？

第五节 “那我们就开始开发吧”

---

现在，有了会“比较快速地”编程的愚公，而且有了公司，我们完成了组织机构建设，我们还找到一名（或好多名）项目经理，他们一不怕死，二不怕苦，更为可喜的是我们还有了开发部：对内，我们订了一套规章制度；对外，我们还拿到了单子。

“那我们就开始开发吧”--你就这样跟我说。

很久以前，很久很久以前，人们都是这样做的。

第六节 组织的学问：角色

---

如果非要精简到两个角色的团队模式，那么在这种情况下，通常是开发经理兼任项目经理。因此这位开发经理一定要能清楚地区分这种双重角色的身份：在任何时候，明确自己是在进行“团队内协作”，还是“团队管理（和组织）”，还是在与“团队外交流”。

如果这个开发经理总是混淆自己的角色，那么，我建议，换人吧。

第七节 跟随蚂蚁，但不要栽进蚂蚁洞里

---

秉性难移，要改变一个人都难，何况是改变一个团队的既定习惯。

如果有一群开发人员像蚂蚁一样辛勤的工作着，那么，请先不要打扰他们。你应该跟随他们，看看他们是如何做的。发现规律，分析这个规律的价值，最后再尝试改变他们（的一些负面价值的规律）。

所以你要紧紧地跟随他们--除了一个地方。那么地方是你去不得的，那就是蚂蚁洞。

显然，你不是开发者，你是管理人员。所以尽管你也是团队中的角色，但千万记得离蚂蚁洞远点。你在洞外张望，可以发现问题；你在洞内，就只有做“循规蹈矩”的蚂蚁。

管理者是那个可以在洞外放木棍的人。

这段话是啥意思呢？

第八节 “什么是增值税发票？”

---

现在你已经足够地观察了你的团队，你知道这个团队存在问题，你也知道这必须被改变。当然，你也知道这种改变并不是放一根木棍那么简单。

.......。所以，作为项目经理，你需要先分工。

被优先考虑的是弹性分工。

蚂蚁的分工模式之一就是弹性分工。一只蚂蚁搬着食物往会走时，碰到下一只蚂蚁，会把食物交给它，自己再回头；碰到上游的蚂蚁时，将食物接过来，再交给下一只蚂蚁。

确定被“弹性分工”的员工需要可以快速地转换新的角色。但首先要考察的并不是他是否“有能力”胜任这个角色：能力可以通过学习来增强，而角色的转换，则首先是思想的转变。

1997年，......

尽管弹性分工非常有效，然而真正做弹性分工却并非易事。蚂蚁的角色转换是本能的，而P&J却不得不花两天时间来说服我。因而更应当留意团队成员“自激”式的角色转换，知道他是不是真的想（而不是需要）转变一下角色，这样起码可以省去你两天的功夫。

更好的选择是明确分工，而不是弹性分工。你应该明白，重要角色的更替通常极具风险的，例如项目经理或开发经理；频繁的开发人员的调度也会直接影响到工程的质量和进度。

如果所有人都在思考“什么是增值税发票”，那么你的组织结构将立刻溃散。

因此，明确分工是你的管理职责。做管理不等于做伯乐。

第四章 流于形式的沟通

第一节 客户不会用C，难道就会用UML吗

我们总是要先接触客户的。

因此在前面提到的R模型中，开发人员最好不要直接面对客户。项目经理有这样的一种优势：他可以不用了解C语言，也可以用一种非C的语言来与客户交流。

或者你更愿意开发人员尽早地进入状态，那么，你可以让开发人员以需求调研的身份出现在客户面前。但是，请注意这个人员的角色将变成“需求调研”，如果他不能适应这种转变，那就别让他去--那会是灾难的开始。

......

到现在为止，你应该看到，咨询公司除了把问题搞得更加复杂之外，他们仍然需要面对最直接的问题：如何与客户交流？

他们的解决之道是建模语言。

有什么差别吗？

程序员不能要求客户会C，难道需求分析师们就能要求客户会UML吗？！

第二节 项目文档真的可以用甲骨文来写

---

UML图在一些客户眼里无异于盲人的世界，如果需要向他们做需求调研，你只能使用一种这些客户能够理解和接受的方式，例如表格、流程图以及......更深入的交谈。

你要确认你的沟通方式是否有效，而不是去追求这种方式是不是UML，以及你用UML是否正确。客户是因为他认为你理解了他们的需求，而在“需求确认书”上签字，而不是因为你的UML图画的是否精确。

现在来思考：为什么非要让客户看UML图呢？如果有能够满足“极限编程”所要求的“现场客户”，那当然可以不用画用例图；相反，如果客户雇佣了一些专家组来评审需求，那么你就老老实实地画用例图好了。

第三节 沟通的三层障碍

---

所以沟通的第一层障碍，并不在于你要表达的内容，而在于你如何表达。换个说法：就是“不知所云”。这种情况下，你需要“组织语言、学会说话”。

---

仔细理解这两句话，前者在说的是“我们没有”，因而责任在我；后者在说的是“您想要的”，因而责任在您。看起来这两句话是在表述同一件事，但因为语言组织得不同，前一句的语气是在“致歉”，后一句则是在“推诿”。

---

由此看来，从叙述中揣度结果，那么他们都一定会像分析这两句话的差异一样，无比细致地去分析对方的描述。因此，（注意！）他们事实上都会关注对方的措词、语气、句法，或者分析表达的前后逻辑与关联。而这样做，通常有两个目的：

找到对方表达的潜在含义与目的；

找到对方叙述中的逻辑错误。

第一个是支持者的心态，第二个则是反对者的心态。然而你应该知道，这两种心态就是一个会议的全部内容。

所以你会发现，重要的人很少说话，而重要会议所需要的发言也很少。这样的角色，或者这样的场合下的言论都是经过充分组织的。--只有这样表达，才会更加有效。

我的老朋友Soul有一句名言：“对于两个聪明的人来说，正确的结论通常只有一个。因此如果出现了争执，那么讨论的一定不是同一问题。”

---

所以沟通的第二层障碍出现在跟聪明人的讨论中，让人觉得“不知所为”。这种情况下，你应当预设前提，并尽早阐述结论。

---

用尽可能少的人、在尽可能短的时间内做出决策，这是降低沟通成本的关键。正是因为有了人和时间这些成本因素的约束，所以“我们讨论清楚”再做这个设定可能就会很荒谬。所以第三层障碍的主要表现是：不知缓急。解决之道，则是不要把沟通目标设定为“让对方认同”。

在我们的确没有办法把一件讨论“讨论清楚”的时候，就是“旁观的人最重要”了。--作为管理者，应当去观察、理解和发现问题（或者由专人向你汇报）。你要尽量去听、去思考。因为作为这个角色，你总是有机会纠正问题的。

但是，不要急于去纠正--在一个会议上即使某种想法有问题，也决不是在你发言的三分钟里就能纠正的，而是在最后你做出的决策里去纠正的。这种决策通常有两种：

给出明确答案；

存而不论。

看起来，让你“给出明确的答案”是职责所在。反过来说，“存而不论”就似乎是在推卸责任了。但是可能在某些情况下，“存而不论”才是最好的决策。

项目经理不是理论家，所以并不是“一定”要把一件事情理论清楚才能实作。“论理”是要以沟通成本（人力和时间为代价的），也可能以牺牲“事件”本体来做代价。因此作为管理者，你应该“适时终止讨论”。

沟通不过是手段、是工具之一种，管理者的目标是项目本身。因此讨论不清楚就暂不清楚，让需要讨论的人“而不是整个团队”继续去讨论。于你而言、于项目而言、于整体而言，“有的‘异’无关宏旨，无碍大局，可以存而不论”。

第四节 最简沟通

---

在大多数项目中，这样的问题都是存在的。真正能满足极限编程所提出的“现场客户”的情形并不经常出现。即使能将程序员送到客户现场中去，沟通问题仍然是不可避免的。

因此在D项目中我提出了“最简沟通”。

我们开始在网络上查看相关的软件系统的特征，以抽取客户所关注的内容；了解该客户的公司、经营理念、组织结构形式以及工作模式；了解同类公司的成功经验和优秀的管理模式，以及客户的竞争对手再做什么和在关心什么......

其实我们了解sipp，abcus就是走的这一步。

---

我们开始设计提问，每一个提问涵盖尽可能多的信息点，尽可能多的具有发散性以便形成更多的推论和假设。

应该清楚的是，保障每一次沟通的有效性都是最重要的事。沟通不是打电话或者请客户吃饭那么简单的事。你得到的每一次沟通机会，都是向客户了解更深层次的需求的机会，因此最好在见到客户之前，你就已经设计了所有的问题和提问方式。

第五节 为不存在的角色留下沟通的渠道

---

项目的中断和中止，与历史产生断层的内因是一致的。--我发现很多的项目（尤其是产品计划）在负责人员离开后，就自然而然地死掉了。我把这一切的原因归咎于“没有History”。
我们做项目的时候，如果也不留下历史记录（History），那么以后别人来看这个项目，也会是两眼一抹黑,.....
维护项目比做新项目更难，许多人深有同感。然而这些“有同感”的人又何曾想过，自己再做“新项目”的时候，要为“项目维护”这种还不存在的角色，留下一个沟通、对话的渠道呢？

---

而History是为整个项目而记录的。一些参考的记录内容有：

需求阶段：与谁联系、联系方式、过程、结果以及由此引发的需求或变更；

设计阶段：如何进行设计、最初的设计、最初的架构、各个阶段的框架变化、因需求变更导致项目结构上的变化（有助于了解构架的可扩充性）；

开发阶段：每一种技术选型的过程、每一种开发技巧的细节和相关文档、摘引的每一段代码、算法、开发包、组件库的出处和评测；程序的单元测试框架；每一个设计和架构变更所导致的影响；

测试阶段：还记得测试用例和测试报告吗？那是最好的History之一。

其实我也比较有同感，但是这样是不是和敏捷开发有冲突？

第六节 流于形式的沟通

在很多的时候，我所听到的沟通，都是一种形式。例如与客户吃饭或这打回访电话。

---

流于形式的沟通，可能是使你的项目不断推翻和延迟的最直接原因。

沟通问题不仅仅存在于你跟客户交流中，还存在于项目的各个角色中间。.....

UML的确是解决沟通问题的最佳手段之一。然而如果项目一开始就不能用它，那么强求的结果必然是痛苦的--要让UML在一个没有经过相关培训的团队及其各个角色之间用起来，几乎是不可能的事。即使用得起来，也存在经验问题。千万不要指望仅仅一个项目，就能让你的组员深刻理解UML的思想。

---

使用与不使用UML，其根本的问题在于沟通方式的选择。只要是行之有效的、能在各个项目角色间通用的，就是好的沟通方式。

第五章 失败的过程也是过程

第一节 作过程不是做工程

---

换而言之，无论是用RAD模型还是RUP模型来做工程，即使是亦步亦趋，也做不好工程。

如果工程可以那样做成的话，只需要有瀑布模型就够了。因此“做过程”并不是做工程的精义。

也不是目的。

第二节 作过场

略

第三节 实现，才是目的

---

这样的结果是：我们做完了工程（的每一个过程），却没有完成项目（的每一个“实现目标”）。

为工程而工程的人，都迷失在项目中了。就像开发人员迷失在一个技术的细节上一样。专注于RUP或者RAD之间区别的人，可以把每一个过程的流程图都画出来，却也被这每一个流程给捆绑得死死的，再也没有力气挣扎一下的力气。

第四节 过程不是死模型

---

试着跳出大师们的身影，再仔细地看一下那些所谓的“经典”过程，不过是瀑布模型的一再变形。瀑布模型描述了开发的主要环节，于是一群人把这些环节扭来扭去或者反复迭加，就成了RAD、螺旋、RUP......

---

因此，我们应该去思考瀑布模型到V模型这种变化的真实意图。

V模型的每一个环节中都强调了测试（并提供了测试的依据），同时又在每一个环节都做到了对实现者和测试者的分离。由于测试者相对于实现者的关系，是监督、考察和评审，因此测试者相当于在不断地做回顾和确认。

---

更进一步想，如果瀑布模型可以变成V、W和M，为什么它不能更关注于其中某个具体的环节（例如实现和设计环节）？如果在这些环节引入RUP的思想，哈哈，你看看，是不是出现了勋章模型和烟斗模型。

第五节 “刻鹄类鹜”与“画虎类狗”

---

同样，以得失而论，在瀑布模型与RUP模型之间，学习前者而不成，可思过程的本质；学习后者而不成，可得文字的架子。--用不好RUP的人，总会说自己终归还有一堆文档模板可以抄，便是这个缘故。

过程理论中，如果懂得了所谓的模型原本都演化自那个简单的瀑布，那么文档是按XP写还是按RUP写，也就可以应时、应需、因地制宜、择善而从了。本质的东西若能理解得透，架子还不是随手搬来就可以用的吗？

越是简单的东西，往往越是接近于本质。

---

你到底是选择架子还是骨子？

第六节 工程不是做的，是组织的

---

所以我们当然不能“做”工程，而是要“组织”工程。项目经理的工作，就是要去组织这个工程中的各个角色，使得分工明确，步调一致，共同地完成这个项目。