《大道至简》读书笔记

大道至简--软件工程实践者的思想（周爱民 著）

注：作者那么轻视工具和语言，估计和他所处的角色有关，从标题“软件工程实践者的思想”可以看出，他讨论的核心是软件工程。

 

序二

......

因此我必须阅读大量的技术书籍，每天在Internet上不断地补充新知，以应付工作上的需要。长期的积累，虽然让我学习了许多技术，但是真正让我不断超越昨日自我的因素，并不是这些单点的技术，而是多参考业界大师级人物的思想，以及更实际地看看我们同X（单人旁加个齐）的思考，更重要的是，不时地停下来进行融合思考的结果。以前我非常享受在工作时与李匡正先生、苏国钧先生以及我的其他好友共同讨论的时光，盖因在这些好友的谈话和思考中，蕴藏了他们丰富的知识和智慧的精华，让我受益良多。

 

注：

大量的技术书籍，我估计没做到，我学的都是基础的，谈不上什么技术；

参考大师级人物的思想，好像也谈不上；

停下来进行融合思考，我思考过，但谈不上有什么感悟。现在我就停下来，不再看太多新的书，先复习以前的，思考思考！

 

前言

......

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

注：

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

 

......

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

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

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

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

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

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

 

第一章 编程的精义

第一节 编程的精义

......

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

 

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

......

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

 

第三节 程序 = 算法 + 结构

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

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

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

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

 

第四节 语言

......

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

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

 

第五节 在没有工程的时代

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

......

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

 

第二章 是懒人早就了方法

第一节 是懒人早就了方法

略

 

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

......

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

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

 

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

......

我当时便反问他：“你既然知道如何把书分类、规整得整整齐齐地放在书桌上，那怎么没想到如何把所学的知识分类一下，归纳一下，整整齐齐地放到脑子里呢？”

我是不是也应该将学的知识分一下类呢？我目前也是不知道自己会些什么

答：

（1）知道boost这个库，但没真正用过

（2）看过几本C++语法类书籍

（3）看过几本C++经验类书籍，比如Effective C++

（4）会用STL

（5）会用VC6.0，VS2005等集成开发环境

（6）会用MFC库、BCGControlBar做界面编程

（7）了解COM

（8）稍微了解一点Windows操作系统

（9）稍微了解一点Linux，还未在Linux开发过项目

（10）了解一些测试常识，接触过单元测试框架CPPUnit

（11）有创业的想法，但是没有一点经验

（12）了解C语言

（13）看过《Windows核心编程》，在MSDN中看过一些API的用法，会使用DLL，多线程等Windows程序设计知识

（14）会调试自己写的程序

（15）了解一点架构知识，连EA都不会用

（16）了解一点面向对象设计知识，但都没有形成经验

（17）了解一点开发方法，比如极限编程等

（18）了解一点设计模式

（19）了解一点软件工程的知识，比如CMM等

（20）了解一点数据库知识

（21）了解一点网络和协议知识，会用基本的socket编程

（22）不会汇编、Java、Python等

（23）了解一点管理，但基本没有管理经验

（24）了解正则表达式

（25）了解一些商用测试工具

（26）了解一点电信知识

（27）基本没有和同事，客户，下属，领导之间进行沟通的技巧

 

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

......

 

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

......

我第一次提到我对程序的理解是“程序 = 算法 + 数据结构 + 方法”，就是在这一次与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写，也就可以应时、应需、因地制宜、择善而从了。本质的东西若能理解得透，架子还不是随手搬来就可以用的吗？

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

......

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

 

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

......

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

 

 

第6章 谁是解结的人

第一节 是谁的问题

......

可见，在通常情况下，一个团队的特质是管理者在团队生活和行为过程中逐渐形成的。特质的形成，是管理者的问题。他或者是主观地培养，或者是在不经意间形成，或者这根本就是管理者个人特质扩散开来的一种群体特征，但无论如何，维护有益于团队整体的特质，是管理者的责任。

 

注：团队特质可以简单的理解为企业文化。

 

第二节 正视你的成功

......

虽然发掘、彰显和维护这种特质是管理者的责任，但是并不是一个管理者来到一个团队大喊一声“我有特质”，于是团队就有特质了。一般情形下，管理者有个体特质，是管理者的问题，不是团队的问题。因此我们也注意到，很多人反对“空降兵”式的管理者。因为（大多数情况下）这些从天上掉下来的人，一开始就拿着自己的特质或以前团队的特质来“主动地”影响新的团队。他们最经常说的话是“我通常习惯这样这样”，或者是“我们以前怎样怎样”，又或者是“我原来所在的部门如何如何”。

......

成功的经验往往最不可信，因为一方面，成功者沉醉于成功的喜悦，并急于与人分享快乐与荣誉，而不关注这些成功的前提与背景；另一方面，听取这些经验的人则因为那些“既有的成功”而丧失了应有的警惕。

经验，是源于对过去的思考，而不是对过去的复制。面对那些在你面前说“我们曾经这样成功做过”的空降者，不妨先把他们想象成一条条肺鱼。只有提得出质疑，才能换个角度看到那些成功经验所依赖的背景，也才能看到某些成功背后的偶然的或者关联的因素。

每个走上管理者角色的人都无可置疑地拥有非常多的辉煌。对于这些，无论你是空降还是地面进攻，也许在你还没抵达这个团队的时候，大家就都已经知道了。但你是来解决问题而不是来分享成功的。你的那些成功经验，未见得都是可以或应该与团队分享的。如果需要，对失败案例进行分析，并与团队中的成员分享可能要好得多。

千万不要把自己的经验直接拿到项目中来套。“我曾经做过”、“我这样想过”、“对这个问题我思考过了”，这些言论只能把问题的根苗填实在团队的缝隙里。

 

第三节 总得先做点儿什么吧

......

团队特质如此重要，但看起来，它无论如何都会是较长远的事。管理者既然不能一开始就照搬某种模式，也不能立即着手去建立一种未知的团队特质，那么我们总得先做点儿什么吧？

首先，你的团队无论如何都需要有一个远期的目标（然而我发现事实上很多管理者并不善于描述远景）。团队的远景与目标不一定非得是“特定项目的特定结果”，例如远景不见得是你现在正在做或准备完成的项目。举一个例子来说，远景可以是“打造公司的精英团队”，或者“挖掘某项目技术在某某行业中的应用”这样的描述。前者以精神形象约束团队，后者以技术方向引导团队。远景的具体设定，取决于团队的结构、项目的特性和管理者的个人素养。

远景更多地侧重于方向的描述，而阶段性目标的确也是必须的。这至少有三个原因：

明确阶段性目标以便于团队实施和检测；

细化的设定目标更加灵活，便于修正；

阶段性成功能充分激励团队的士气。

但是无论对大的远景，还是小的目标，在团队中并不需要每个人都予以密切关注。所以对目标进行阶段性设定与回顾，是使这些“并不时时关注方向的人”也能体会到方向感的最佳方法。阶段性的目标在微软的工程中被称为“里程碑”，可见这是一种卓有成效的、实践性很强的工程方法。而我在Y公司工作的七年时间里，最终、也是最失望地离开的首要原因，是在那样长的时间里，我都只知道为谁工作，而不知道工作的目标--更高层的管理者从来都没有告诉我“整个公司（或我所在的团队）在未来的方向是什么”。

无论一个人是何等的努力与敬业，七年（或更短）的时间都不知自己在为什么努力与敬业，他也必将失去激情。

......

如果每个人都必须不断地调校方向与留心脚底才能跑到“正南方10公里”，那么“企鹅队列”是必然的结局。所以第二限定应当被分解成这样：最前面的人去看看有没有墙，其他人则关注脚下有没有坑--方向与远景不妨让大家都知道，但“保障方向”这件事，应该只交给头羊。

现在我们有了一个“起码像个样子”的团队。基本上来说，这个团队有三点特性：

方向和目标明确；

团队并分工协作；

能意识风险并有规避策略。

 

第四节 你不是团队的腿

.....

无论他如何陈述理由，产生这个结果的内在因素只可能有两个：

他根本不再对10公里之外的风景抱以期望，甚至认为那不过是望梅止渴的幻想；

我现在就有点这种思想，老是认为我们的SIP不如sipp，做起来没意思,不抱希望！！！

他消耗了相当的体力，接近极限而无法再坚持。

.....

如果“头羊”是技术经理，或者是团队中的某个“精神领袖”，那么（作为项目经理的）你就是教官。你的工作主体是：协调、督促、激励、监督和凝聚。--当然你还可以做些别的事，例如去操场外给大家买些冰水。然而有一件事你绝对不能做：试图帮那个说“跑不动了”的人跑下去。

你不是团队的腿。

大凡是从技术出身的管理人员，总会有愚公那种本能的“实现欲望”。如果一件事自己能做而别人不能或者做得不够好，那么他总是恨不得自己去做。的确，对于一些技术细节来说，你“也许”能立即着手去解决。但是，一方面你根本不可能通过“亲力亲为”解决掉“团队行进”的问题；而在另一方面，你至少为团对带来了下面这四重危险。

首先，你应该让团队的每一个人清楚：“我”必须跑到终点，否则“团队”倒不了终点。这是每个个体的责任，没有人可以替代--这是培养责任心和树立价值观的事。假使你真能成为这个人的腿，“跑”到终点，那么这个团队的成员将会质疑自己的价值和能力，也会忘记自己的责任。一个人如果在团队中没有价值，也没有责任，那么他离辞职也就不远了。

接下来，培养一个最怕的是“教而不习”：你教他，他要么不学，要么不用。但是，事情的真相，不见得就是这个“懒”到不学习，而是你过于勤快，让他失去了“习”的机会。所谓学习，就是让他在过程中看到问题，并了解到解决问题的方法，最后解决之。例如“累得跑不动了”的问题，你应该告诉他，可能是因为：

呼吸没有调匀；

使用嘴而不是鼻呼吸，伤到了肺；

出汗过多，导致缺盐；

脚与地面的摩擦过多，无谓消耗；

.....

你现在应该注意到：如果你真的帮他跑到了终点，那么他将无法知道这些；或者他即使“学”过这些知识，也无法将现在的疲劳与它联系起来。正是因为你愚公式的勤奋，使团队成员失去了“习”的机会。另外一方面，事事亲历亲为虽然容易服众，却也容易滋长集体的惰性：团队成员如果只能把你、把项目、把公司当成学习观摩的场所，自然于项目无益，于团队无益。然而，你还愤愤不平：这些人怎么又懒又笨，什么事都要我动手。--如果团队在你面前只是愚公的集合，那么可能是你出了问题：不会教习，或过于自负。

在sip项目中我是否犯了这个错误？

今天看到鲁这儿管那儿问，我心里有点不舒服，好像这样显得自己在项目中重要性降低了似的，实际上，当初我也不是这样么，现在终于能理解当初小泉和刘海寅对我的那种微妙态度了，其实我必要这样嘛，找到自己的位置好好干就行，没必要在意是谁在那儿打杂！再说了，鲁在项目中的时间也比我长，也应当由他负责，机会均等嘛！

在接下来，于一个人而言，“成功”的激励远大于其他。一个人从来没有享受过登顶的乐趣，那么他一定不会喜欢登山的过程。而你帮他跑到终点，事实上也剥夺了他作为团队成员来分享成功的权利（虽然项目奖励可能不会少，然而这只是形式的，而非内心的所得）。让一个人总是去做“没有成就感”的工作，他必将渐而生厌，你也无异于自毁长城。

最后，你过于强调的个人能力，这会助长团队的惰性。团队管理是促进整体行进的过程，因此基本上来说，你的行为事实上是在暗示其他的团队成员“你们也可以不跑到终点”。这种暗示的结果，是管理层变成了执行层。由此，原来的执行层变得效率地下，而管理层疲于奔命。你忽略了管理自身的价值，以及你作为管理者的工作内容，因而为整个的管理过程种下了恶因。

对于团队来说，“解决掉一个技术问题”，远比“团队的整体行进”次要，因此你不要冲在前面披荆斩棘--把这件事交给技术经理去做，或者教而习之，由成员去做。你首先要明确自己的责任是“整个团队的目标”。

如果你真是好的教官，如果你关注于“整体的目标”，那你应该早早地发现这个团队或某个个体存在问题的“原因”（例如奔跑时的姿势不正确这种技术问题，或者某个成员垂头丧气这种情绪问题），而不是等到有人倒下，才去解决“跑不动了”这种问题的“结果”。大多数管理者并不是因为能力不够而做不到这一点（哪怕这看起来好像是“未卜先知”的神术），而正是因为你过度陷于实施，无法履行你的监督职责--因为你不可能监督自己。

应该记住管理者的责任也包括“监督，发现问题并防止扩散”。因而要主动给自己留下时间和空间来发现问题，在问题出现之前定位它、分析它，并组织人力去解决它，而不是：

等到问题出现之后再去冲到前面；

然后在还没有清楚地意识到问题的根源时就试图解决之；

最后刚解决了表面问题或者侧面问题，又发现更多的问题挡在前面；

最后之最后，你垮掉，团队也垮掉。

.....如果需要，你不妨去真的买几杯冰水。你也不妨从这杯冰水开始，思考管理一个团队的方法与技巧。

 

第五节 三鼓而竭

......

“三鼓”这样的傻事大家都经常在做。例如老板请吃饭，几次下来大家就都习以为常了；又如月奖、年奖、项目奖，到后来就都成形式了；......

这还是外力的“鼓”（激励），打不了是让人觉得厌烦或者无视而已。我们下面来说另一种情况。

我知道有很多管理者习惯否定别人的想法，而不是肯定之。这个问题的根源，一般是由于管理者从技术出身，因而总是主观地认为自己“有更加绝妙的想法”。但是，不管你的想法是否真的“绝妙”，从管理的角度来说，这种“否定别人”的做法，其实是一个非常愚笨的主意。

这源起于不同角色“做事”的态度：管理者做事是不怕不做，怕一步错，步步错；而开发者做事，则不怕做多，不怕做错，最怕不做。这种差异，形象地说，就是“管理这是绵羊，开发者是愣头青”。然而，如果老绵羊又正好是摔了一头包的愣头青，或者自认为比别的愣头青更有思想的愣头青，那么他通常就会站在别人面前，说：“你这样不行”。

然而这样的管理者无形中忽略了两个问题：

如愤青一样，愣头青之所以“楞”，多是因为激情之故。然而少了激情，再正确的决策也难以有效实施；

“行不通”只是你对事情的评估，而不是实施过程中的观察。因此“行不通”三个字难以说服于人，也未必真就如此。

这两个问题，一个是说“情当如此”，另一是说“理当如此”。为什么这么说呢，我们先来看看这个愣头青在做这件事时的情绪因素：

首先，他与你讨论，就证明他积极地关注这件事，这比漠不关心，人浮于事要好；

其次，他能够“有想法”，这证明他已经主动地在事件过程中发现问题，比视而不见的人要敏锐；

接下来，他敢于向你“提出”想法，这证明他能够打破管理边界，向上层管理层主动沟通，这是团队中的良好品质；

再下来，他能够“主动”寻求解决问题的手段，这证明他能独立思考，并且比别人更有主见。

一个人如果具有“积极、主动、敏锐、主见”这些良好品质而不被认可，那么无疑是令人沮丧的。久而久之：

他会自我否定，并学会放弃，再也没有勇气提出任何东西，变得人浮于事；

你将继续听到更多的意见，他勉力抗争直到你改变或者他离开。

第一种情况：你牺牲了一名优秀员工，而成就了你的自负。第二种情况，鱼死网破。

根本上说，“怎么做一件事”是一个人的态度问题、性格问题、品性问题。团队成员能有点想法，本身就是值得提倡的：想法成熟，则对工程进展有推动（如改进工程技术、方法）；想法不成熟，善以用之，则可以对团队建设有推动（如进行团队教育、激励）。因此，万不可拒“意见（或想法）”于千里，把团队“自下而上”沟通的道理给堵死了。--你在牺牲团队成员的同时，是失去了建设团队特质的机会，二者之任意，都是你作为管理者的失职。

现在开始，你不妨把这个愣头青看作愿意“贡献集体智慧”的表率，从他开始，为团队内部的积极沟通带个好头。至于接下来如何讨论：认同他、引导他，或者说服他，那才是“理”问题。

态度可以认可，至于“想法好不好”是技术问题。你不宜急于表态，因为团队中还有头羊，还有“精神领袖”，实在不行，还有“聚师而谋曰”。

即使所有的讨论都倾向于对这名员工的否定，你仍然可以给出一个机会来让这名员工去自我证明。这种机会可能只是几个小时或者一两天的技术探索。这种情况下，如果他能够证明他的正确，那么他会感激这次机会；如果结论是他错了，那么你无形间树立了自己的威信--这件事，只是说“不”，是做不到的。

 

第六节 先人后己

......

让一个管理者向别人说“忙”，是一件很惬意的事。“有得忙”才证明重要，成天无事可做的人，存在的价值（起码看起来）也就小得多。所以多数管理者试图从一早到公司，就让自己显得“很忙”。然而，先不论这种状态背后的心理因素，管理者一定不要忘记在开始“忙”之前做一件事情：驱动你的团队。这就是我所谓的“先人后己”。

......

如果他先人后己，在开始自己的工作之前就来招呼大家了：安排每个人的工作，或者解决某些人的问题，那么这会是美好的一天。然而，如果他总是等到发现很多人无所事事时，再来找大家的茬儿，那么这个项目经理离离职也就不远了--当然，也有可能团队会面临解体，他的项目经理自然也做不成。

这个“让影响到别人的事先做”的思想，与“团队高于个人”的观念是一致的。然而有很多人、很多时候不能分辨一个问题是自己的问题，还是团队的问题，因此也不能正确地决策其先后。这种情况下，我只建议你装得很闲，或者希望忙里偷闲，问问自己：“如果这件事不做，会如何？那件事不做，又会如何？”找到影响面最大的一件，交给别的人（或者）大家去做，而自己做“不是太重要”的那件事就可以了。

更退一步说，即使你什么也不做，也比整队人马停下来要强得多。

即便如此，也还有一种“先人后己”是你容易忽略的：奖励，也要先人后己。

......

Soul随后谈了他认为“不错的”原因。他说：我们的工作量未见得多于程序员，而薪水可能比人家高，并且重要的是，我们站在管理的前端，能得到的机会自然就比别人要多。团队成员其实比我们付出得更多，而得到的更少。因此，我们应该把荣誉真实地反馈给团队，而不是贪为己有。

......

做事时固然要“先人后己”，面对成功与荣誉时也要“先人后己”。前者得以完成团队建设的重任，后者则表达你对团队价值的认可。

对于像外包这种情况，我如何“先人后己”呢？交给他我不太放心，毕竟他的责任心可能没有我的强。

答：看了第七节就可以找到办法了，因为它不是个问题。你想做一个优秀的管理者，连一个外包都利用不好，谈什么管理呢，好机会呀！

 

第七节 自相矛盾

看看我们都说了些什么？我们在说你有了一个团队，然后从团队的特征开始，我们谈到了组织、沟通、激励和执行。是的，这些都很重要。但我们还漏掉了一个重要的环节，那就是“问题”。如果团队中没有“问题”，那么看起来就不需要管理者了--你大多数时候是被找来解决问题的，不是吗？

......

乔丹认为这是一种主观与消极情绪的区别。而我看来，这就是问题的定义。伟大球员和普通球员的差别，就在于伟大的球员总说：这不是个问题。

......

所以温伯格是对的：“你认为这是个问题，它就是个问题”。

......

我不知道我所呆过的那么多团队，为什么总是存在这样那样的矛盾。例如，员工与员工的、员工与老板的、进度与质量的、技术与市场的.....你会发现，你总是在利益、正误等这样的问题之间权衡，这些选择带来了你的痛苦：也就是我们所说的矛盾。

换而言之，你的“认识”决定了问题，你的“选择”导致了矛盾。

之所以“矛盾”看起来也是一种“问题”，是因为矛盾通常是你无法取舍、无从选择的感觉--这种感觉来自于“你期望选得更正确，但你感觉你无法做到”。

是的，我正要说：温伯格又对了，这是你的预期与体验的差异。温伯格接着说：“要想解决问题，要么改变期望，要么改变体验。”是的，你现在就可以“放下”，改变你的体验（的需求），从“不要认为这个矛盾是问题”开始，重新设定条件。例如：不要用矛来击盾，而是用矛、盾以击敌。如此，岂不是可以尺长寸短，尽可用之。

所以学会否定矛盾、消化矛盾，看到矛盾产生的内因外因，转而借之用之，才是解脱的方法。

比如我现在碰到的问题--我们自己做sip根本没有sipp好，所以我有消极情绪，认为是决策者调研的败笔（你认为这是个问题，它就是个问题）。照作者的意思，是不是该这样，首先我不要认为这个矛盾是问题，这仅仅说明我们还有相当一段路要走，心态要积极（从“不要认为这个矛盾是问题”开始）。现在我们可以把我们做的sip当作盾，sipp当做矛，我不要用sipp来击我们的sip。而是分析sipp的优势、劣势，以及sip和它的差距、优势等等方面（看到矛盾产生的内因外因），把这些东西考虑到我们的sip中，即转而借之用之（不要用矛来击盾，而是用矛、盾以击敌；转而借之用之）。这才是解脱的方法吗？

还有最近遇到的让我改周的问题单，我对他的方案不认可，写得那么复杂还让我改，我认为其是个问题。但是，为什么我一定要认为它是个问题呢，我干嘛不当做是了解别人思想，练习看复杂代码的好机会呢？确实，你认为这是个问题，它就是个问题，你认为它不是个问题，它就不是。

 

第七章 从编程到工程

第一节 语言只是工具

......然而，这是我自1997年接触到管理，以及1998年接触到工程以来，第一次正视“软件工程”这四个字。我第一次看清楚代码、方法、过程、工程与组织的关系！

对于一个程序员，或者以程序员自命的人来说，看清楚这一切的第一步，竟是一句“语言只是工具”。

......

 

第二节 关注点

......

从这个模型中可以看到，在“程序”与“方法”层面，是关注于“（具体的）实现”的；而在“过程”和“工程”层面，更首要考虑的是团队问题。从角色的角度上来说：开发经理思考项目的实施方案和管理具体的开发行为；而项目经理则保障团队的稳定性和一致性。

以前我当的小组长算是什么角色呢？我看可能还是偏重与开发经理一点，毕竟是负责具体的开发行为。

 

第三节 程序

EHM模型图中，在最内层的环里，是“程序=算法+结构”。这是编程的本源定义，也是原始的状态。与代码相关的任何工作，最终仍旧会落足于这样的一条规则。

......

 

第四节 方法

......

你看不到你做事的行为，也就不能理解“模式”作为一种方法的价值。所以大师们众口一词：模式需要一定的编程经验才能理解。

同理，理解过程也需要编程经验，理解对象也需要编程经验，理解MDA（模型驱动架构）与SOA（面向服务的体系架构）还是需要编程经验。

--这可能就发生在你去回顾你的上一行代码编写的经过，或者上一个项目失败经历的那一瞬间。经验来源于回顾、理解与分析，而不是你将要写的下一行代码。

 

注：方法指面向过程，OOP，MDA等

 

第五节 过程

过程伴生工程而出现。过程解决的是工程中角色间的关系问题。

.....

因此过程中的问题，就是角色、沟通和环节的问题。

哪些环节重要，取决于具体的编程行为，也就是具体的项目。

......

分不清玩家与客户的区别，对项目经理来说，是可怕的。这将意味着他不能清楚地知道哪个环节更加重要。

角色的确定，以及角色间的沟通问题，在项目过程中也同样重要。工程组织是否合理，相互的协作是否紧密，是这个项目能否成功的保障。

......

 

注：过程指RUP,XP,模型与模型语言等

 

第六节 工程

......

过程伴随工程而出现，解决的是工程中“步调一致”的协作问题。那么工程是因为什么而出现的呢？

很显然，软件规模的不断增大是根本的原因。.......

 

注：工程指需求管理，过程管理，配置管理，文档化等

 

第七节 组织

......

所以回顾每一个项目，或者项目中的每一个阶段，以及与每一个团队成员交流的细节，是你的日常工作。

 

注：组织指管理，计划等

 

第八节 BOSS

很多人以为BOSS是给自己发钱的那个人，这其实是错误的。发钱的决策通常是由以下三个角色来做出的：

部门/团队经理：你的直接上司，他是雇佣你的人，是他用薪金的多少来衡量你的价值，或者反之。

绩效经理：如果你的公司有这个角色的话，那么他总是盯着你的错误以决定你薪水的扣除比例。

财务经理：有钱？没钱？没钱？有钱？

是不是应该在日常工作中有意识地在直接上司面前表现表现？比如主动承担工作，而不是被动地等着上司安排！我对外包也是希望别人主动，那么我的上司肯定也希望我主动，这段时间看起来鲁比我表现得好一些，他主动替标哥分担问题单，我看来得找点措施弥补一下，比如功能测试计划。

......

BOSS在公司中解决的是“经营”问题。这其实是在比“组织”更靠外侧的一层--在前面的图例中并没有给出，这也意味着“经营者”与“工程”基本上没有关系。

......

 

第九节 上帝之手

......

软件工程的体系中，“实现”作为软件开发的本质需求和基本动因，如同上帝之手在推动这几十年来的软件工程理论体系的形成。

 

 

第八章 你看得到工具的本质吗

第一节 利器何以为先

......

由此可见，使用工具的方法，比工具本身更关键。所以“欲善其事，先利其器”这样的言论，未见得是全对的。

 

第二节 神乎其技又有什么用呢

......

秦无剑技而一统天下，宋有康肃而痛失半壁！不知用法，不知用处，如同那习得屠龙之术者一般，神乎其技又有什么用呢？

 

第三节 工具的本质

......

如同工程与编程，单以编程而论，讲究技法之精妙，追求细节与枝节是可以的；单对于工程来说，能让团队理解、统一执行、迅速有效的实战技法，才是真实所需的。就像战争一样，团队化的工程中，技法的优劣并不是关键。关键在于某种技法是否能为团队带来整体的成效，而不在于某个人是否喜欢，或者深谙于此。如同陈康肃公，有当世无二之技，不能用于“群战”，也是无益。

......

工具之于工程，本质在于关注并发挥得益于工程全局的那些特性。一人一技，一器一物，又岂能是工程的要义？因此，我们最终看到拥有利器巧技的六国都不在了，最后只剩下一个强秦统一了天下。

 

我对作者本章的观点严重不敢苟同，照作者的意思，好像是因为六国有了利器巧技才导致其被秦所灭的，六国就什么都不干，就专注于造剑了？我拥有利器巧技有什么错，只是无善用者而已。六国被灭，主要是和人相关，和它拥有利器没有任何的关系。二战时的德国，最先拥有潜艇等先进武器，为什么战败了呢，是因为它拥有先进的武器吗，不是。在抗战中，为什么新四军那么喜欢三八大盖，那么喜欢重机枪，在《人间正道是沧桑》中，为什么杨立青要造那么多大炮？所以啊，这个地方是作者为了迎合写书而硬是牵强地贬低工具。

我认为“欲善其事，先利其器”是没有一点问题的，你不能因为工程的重要性就贬低工具的作用！

 

第四节 唯手熟尔

很多的高手，对于工具的本质并不是了解的。他写程序快，只是记忆中读过的、写过的代码多于别人；他思考问题比别人细致，只是因为他有过比别人更多的错误；他能带领项目团队，只是因为他经历过足够多的项目团队。

这样的人可以算是能人：有能力的人。但未必真有识见，真有才略。

......

“尔安敢轻吾射！”当我在论及RUP（Rational统一过程）、UML（统一建模语言）这些具体的工具只是“工程之末”的时候，很多人愤而所言，与当时陈尧咨说过的话，又是何其相近？

 

我还是不敢苟同作者，手熟，不就是我们平常所需要的经验么？！没有经验，看你哪来的真知灼见！！

 

第五节 鲁班带了坏头

......

鲁班这种典型的“工匠思想”，总结下来有三个问题：

以良匠之名为目标，而不是以做工程为目标；

以工具之利为恃仗，却不关注工具用在哪里；

以技法之巧为较量，却不知技法应为团队所用。

现在来看，这不都是大多数软件开发人员（和技术人员）的问题吗？

 

不敢苟同。鲁班就想成为良匠，这有什么错吗，他的角色就是这样。比如造大炮的人一定要去关注大炮在哪儿用吗，如果人人都去想大事，想管理去了，谁来做这些基本的工作！！简直是瞎扯淡嘛！

 

 

第六节 工匠思想

软件开发圈子中，持有这种“工匠思想”的鲁班门生历来不缺（很遗憾，其中也包括我）。

只不过大多数人把这种“工匠思想”的来源看成“八九十年代的个人英雄主义”。他们认为这种思想是一种现象的延伸，而不认为是一种“开发人员的本质特性”。

鲁班的虚名，给工匠们设定了用以安身立命的目标：成为良匠。我尽管要说，这是一个坏的表率；但也要说，这的确是好的品质。

为什么呢？

我曾经在给CSDN的一篇文章中写过：

“如今业界天天都在讲的，除了模型分析就是架构设计，再远一点的就是管理的艺术与实践。诚然，这些都是好东西，都该逐一细论。然而如果连程序员都去思考模型、架构与管理艺术了，那么个体终将是个体，每个人都是分析师、设计师与项目经理，则项目自然做不成了。”

所以在我看来，不同的工程角色的确应当有他自己的关注点。这个角色能考虑到别人想不到的问题，固然不错；但如果他格尽职守，只关注自己的那一部分，也是本分。

我们在EHM图中说，工程体系的第一个关注点是“实现”。也就是说，你可以是“关注于自己能否成为良匠”的工匠，但是作为工程角色，你起码应该关注“如何实现”。放在项目中，具体的要求其实就是：一项技术是以完成工程需求为目标的，而不是彰显个人技术为目标的。

对于管理者来说，重要的并不是“让大家都关注工程的每一个方面”（这事实上也做不到）。工程管理者应当认识到开发人员的“工匠思想”的本质，并善用之。如同我们前面说的，你认为工匠思想“是个问题”，它才是问题。

我在Y公司和N公司都遇到过这样的例子。某些开发人员是编程高手、技术尖子，因此一些管理者想“发挥他们更大的作用”。于是将他们提上高位，许以“经理”、“副总”这样的职位和职责。但这些人要么工作不得力，要么工作不开心。最终工作没有做好，员工也没有得到激励，反倒破坏了组织结构。

在很多公司看来，“当官”可能是对员工的最大激励。然而身处官场的人又如何能理解技术人员的思想呢？其实很多的开发人员，无非是追求更宽松的工作环境、更好的学术研究氛围。换而言之，他们根底上就是关注于工具与技法的。

如果公司不能利用这些“本质特性”，非要设定他们的“仕途”。那与以矛击盾有什么区别呢？--我们说过，大多数矛盾都是自找的。

公司应当给出员工“在技术方向上的发展路线”。很多大公司在这一点上其实做得不错。他们把技术职级与管理职级分开，使得技术人员可能通过技术提升来得到与管理者相近的薪酬。但事实上，管理者整体的薪酬总是高于技术群体的，因此薪酬的激励终归有限。对于开发人员来说，吸引他的是无限的发展空间。例如当初微软打算用三百万年薪和数万股票从Borland挖走AndersHejlsberg，未果。后来，盖茨提出给他一个小组和极多的资源，“让Anders尽情地发挥”。Anders这才动心，从此就有了VS.NET。

Anders显然是无可争议的、最优秀的程序员，

 

 

第七节 化而用之，融通与融同

......

“融通”与“融同”的区别在于：前者以一通十，有运用变化的能力；后者则知工具之大同，信手而得，随心而用。

--无所谓是什么，只在乎它能不能用。

......

于某时某事，适用的就是最好的。前提是你要看明白这些工具实质的能力。只要能够分辨出所需部分、适度地用在你的工程中，就可以了，......

明白这些工具实质的能力也是要花时间的，白痴！

 

第八节 南橘北枳

......

然而对于确定的项目来讲，只有对这个项目有用的那些“功能”，才是这个工具的价值所在。所以，识见到工具“设计”所满足的那些“确定的需求”进而明确工具与项目的关系，才是解脱之法。

......

 

第九章 现实中的软件工程

第一节 大公司手中的算盘

......

大公司在标准、理论、语言上的争来争去，未必全然出于“软件实现”的考虑。对统一理论、统一工具、统一过程的企

图，其最终目的是在整个软件工程体系中的全面胜出。

在整个软件工程体系中的全面胜出能获得什么益处？

 

第二节 思考项目成本的经理

......

愚公如果停下来，思考的问题可能是碎石的“方法”。而项目经理从细节中跳出来，思考的问题就应当是完成工程的“方法”。评价这个方法的好坏的标准只有一个：节约成本。

......

--思考成本，这是D先生给我的教训：

不计成本的项目计划不会得到经营者的支持；

毫无目的地消耗成本是项目中的慢性毒药；

最致命的风险是成本的枯竭。

 

我经常注意到的成员因素包括时间、人力、资金和客户成本。而大多数情况下，人们不会把客户的数量及耐心当作（客户）成本来计算。而在我的项目规划中，这是成本。

 

第三节 审视AOP

......

AOP不是语言。AOP首先是方法论，这就像OOP是“面向对象的编程方法”这种方法论一样。......

.......

所以接下来AOP的三个概念我们就明白了。

指示/拦截器：考察这些对象以“达到什么样的目的”（即需求）；

引导：在目标上实现这些需求时，目标所需要表现出来的公共特性，引导特性可能需要配合编译器来实现；

元数据：如果需要，为即有对象实体再补充一些参考数据。

......

 

第四节 审视MDA/MDD

MDA（Model Driven Architecture）也是一个方法论层面上的名词。它讨论的是“创建出机器可读和高度抽象的模型”的方法。受MDA影响的开发活动被称为MDD（ModelDriven Development）。

TDD

FDD

BDD

R-TDD

CDD

RDD

......

我不厌其烦地罗列这些名词，只想告诉读者一个事实：什么都可以“驱动开发”。

......

回到软件工程的过程环节来吧，你会看到“以什么驱动开发”只是一个“以哪个环节为中心（或导引）”的问题。

......

抛开实现的技术细节不论，在工程中，“以什么驱动开发”其实是一个过程问题。而你应该明白，过程的选择（或制定）取决于你的工程需要，以及它在相关领域的适用性、过程工具的充备性和这个过程理论的完善程度，而不是大公司们的鼓吹。

......

也就是说，MDA架构作为一个新的软件开发方法的架构，即使在技术研究、底层协议和软件实现方面经过了持续地完善地而渐直成熟，然而如果没有同样成熟的软件过程理论支持，那么它在工程中的实用价值一就有限。

仔细审视一下这个MDA，如果你现在就决定将下一个项目建立在这个架构的基础上，或者用MDD的方式来开发BIOS,那么你离精神病院就不远了。

 

第五节 审视AP和XP

......

因此，AP以及它的核心思想“敏捷软件开发宣言”，是以实现、实施、实践为主要手段，以体现人本为主要内涵的行为

准则。主要表达在：

一个人本化的、共有的团队特性与气质；

一个契约式的团队组织结构和领导风格；

一些以“解决问题”为中心的思想方法。

XP实质上是使团队遵循这些“行为准则”的一些“形式化的方法”。当然，XP在对一些工程要素的权衡上，也给出了建议和实践结果。但这并不是具体的过程方法，也就没有逾越或颠覆瀑布模型。

“敏捷”，其根本的思想就是用最快捷、有效的方法完成工程。因此，你可以把在“包含瀑布模型在内的”任何过程模型上，基于上述表达进行的开发实践都叫做“敏捷工程”。

......

AP是啥玩意？

 

第十章 是思考还是思想

第一节 软件工程三个要素的价值

“牛粪图”中描述的工具、方法与过程也被称为软件工程的三个要素。在本书中他们被分解开来思考，并不是要孤立这三个层面--他们实际上是相互作用的。

例如“过程”问题，就既有实施过程的工具，也有相关的过程方法理论。......

......

你能把每一个“管见”拼合起来，你得到的才能是“豹”，而不是“斑”。所以尽管本书割裂了软件过程的各个要素，并从每个孤立的层面来审视。然而实质上，你应该回归到软件工程的本体上来思考问题，而不是仅关注于每一个局部的要素。

工程的整体问题仍旧是“实现”。

 

第二节 其实RUP是一个杂物箱

我或许总是在批评RUP，但是我不得不承认它是对前人在软件过程思想方面的高度包容。

请注意我用“包容”这个词，而不是按照语言习惯那样用“概括”。因为如果是“高度概括”，那你应该把目光投向瀑布模型，而RUP其实就像是一个杂物箱一样“包容”了全部的已知理论。

......

RUP能不能被用起来，将取决于你刚才那个挑挑拣拣的行为，以及现在你在拿到钓竿后的辨别能力与组织能力。

啥意思？

 

第三节 UML与甲骨文之间的异同

在你真的打算用甲骨文来写项目文档之前，请先明确UML与甲骨文之间的异同。

在这本书里，他们都被作为沟通的工具。因此目标是沟通，而不是“选用工具”这件事本身。更进一步的推论是：即使你因为个人喜好而选择了甲骨文，也不要试图在结绳子记事的原始人面前去用它。

......

所以在工程中使用UML图，应该有相应的文字来描述它。而且这种描述与图之间的对应关系要持续地维护下去。如果这种关系松散了、断裂了，那么下一个阅读UML图的人所面对的，将是无异于甲骨文出土时的困境。

 

第四节 经营者离开发人员很远，反之亦然

......EHM真实地反映了“老板不懂技术”的合理性，同样也真实地反映“开发者转型为老板”的道路将是相当漫长与艰难。

于是，项目经理这个中间角色就有了一种使命：协调经营者与开发者之间的沟通。

......

你要理解这种根源：角色的关注层面完全不同。

 

第五节 矛盾：实现目标与保证质量

......

需求人员会把所有的责任归咎到开发人员，而开发人员又不停地埋怨需求的不清不楚，或者变更的没完没了。又如果正巧需求和开发都是同一个人或者小组来做的，那么他们便会开始埋怨客户的苛刻及工期的紧张。

总之一件事，没有人会跳出来说：我们原本就错了。然而事实上问题可能真的处在源头：我们把目标定错了。

我们看到，在项目的平衡三角（时间、资源和功能）中讨论的是目标问题，但并不讨论质量问题。......

......

如果原定的目标（的整体）本身就过大，那么无论如何平衡这三者之间的关系，其结果仍旧是保证不了质量。

问题是：又有谁愿意在最初签订协议的时候，就降低或者放弃协议的标的呢？

那我们该咋办嘛？

 

第六节 枝节与细节

刚才说到目标与质量的问题时，提及“平衡时间、资源和功能三者的关系”。这其实是一个实施过程中的细节。或者说，它是一个具体的方法，而不是目的。

......

大多数情况下，管理人员有责任去审核、评估其他成员的工作成果。这个时候可以讨论“细节决定成败”这样的问题，因为这决定了产品的最终质量，而质量是工程的目标之一。

而在另一些情况下，例如管理人员做事件的决策的时候，就必须要学会忽略枝节问题。

比如在做架构设计决策时，像按钮图标好看不好看这些细节估计就得忽略，而在具体地实现这个按钮时，估计就得关注了，否则版本一发布，可能就因为你的一个图标而显得不够专业。

......

因此我只好用最笨的方法提示管理者：别管它是细节还是枝节，只要你感到你的脚趾已经沾上了泥淖(chuo)，就快点回头。

沾上了泥淖(chuo)是什么意思？回头是什么意思？

用脚趾去感觉，有时比用头脑去思考来得有效。

 

第七节 细解“法”与“式”

软件工程学科中的很多思想与其他传统的工程学科既有的思想、方法和理论有紧密的关系。所以甚至有些软件工程角色被推荐去阅读类似于《建筑的永恒之道》这样的书。......

我得找找这本书翻翻？

由此看来，《营造法式》中所解决的问题，与我们今天的软件工程中所遇到的问题如出一辙：

工程管理者不能兼通各个工种；

不同的开发人员对设计和只做的理解不仅相同。

那么《营造法式》是如何解决上述的两个问题呢？

这就回到了“法式”这个词的含义上来了。法式二字，是宋代官方文件的常用词，法指“律令”、条例，“式”指定式、方法。所以《营造法式》颁行的初衷，是希望能有办法将工程中所用的元素：

“按类分别排出，有条例规章作为依据”；

“按照条文画成图样，对将来的工作有所补助”。

......

那么，我们怎么能指望在某种（或几种）过程理论，以及一些模式方法之上，找到一个能一成不变的办法去实施我们的软件工程呢？

相较于《营造法式》，我们的软件工程实践类学术专著仍然非常粗糙，未必能像“法式”那样值得趋从跟随。当然我们也不应当因噎废食，妄论优劣。因此对于“某某模式”与“某某模型”之类，我们的态度仍然是“与式不同，比类增减”。

“与式不同，比类增减”是啥意思？

 

第八节 灵活的软件工程

“未蕴而变，自欺也。知律而变，智者之道也”，实为良言。

“知律”的另一层意思，是在于“知道原理”。明白“为什么要这样”或者“为什么不是那样”。这在软件开发中是常见的问题，大多数人不知就里地使用着技巧和方法，而一旦出了问题，则归咎于这些技巧和方法的不好。而真正的问题在于，这些人（我们通常叫做Copy&Clear）并不知道这些技巧，技术和方法的原理，因而不知道变通，也不知道回避错误。

有时确实是这样，比如我可能会简单地使用多媒体定时器，但是上次关闭定时器引起程序崩溃的问题，我就抱怨是多媒体定时器没设计好，实际上我知道，应该是我没使用对，为什么没使用对呢，那就是我对其原理理解不够。但是，有时我们确实没有那么多时间去研究透一个东西，我们该如何选择呢？

所以死读一本《软件工程》的人不会做真正的软件工程。

所以我写《大道至简--软件工程实践者的思想》。

 

 

这段时间的郁闷终于解决了：

答：首先要有积极的心态，把麻烦和困难当做学习、锻炼、挑战！比如今天胡家凯让我搞每日构建，我就觉得没有把握搞定，就有点想推脱，我干嘛不当做是公司提供机会让我学习，好机会啊！你不认为它是问题，它就不是问题！哈哈！！！！！！！