周爱民《大道至简软件工程实践者的思想》读书笔记.doc

周爱民大道至简 软件工程实践者的思想读书笔记当你熟悉了一门语言之后，你会发现，编程语言只有喜欢与不喜欢的问题，没有会不会的问题。任何的一门语言，你都可以在两周内掌握并开始熟练编程。因为任何的一门语言，他们的底层函数库都是那么的相似，而他们API都是那样的依赖于操作系统。A语言里有的，B语言里也基本都有。通常而言，语言的差别主要表现在适用范围上。一些语言适合做数值处理，小数点后可以精确到原子级，而小数点前则可以表达到宇宙之无穷；另一些语言则适合做图形处理，它的底层函数库比其它语言可以快上十倍或数十倍；还有一些语言则适合于做网页，要用它来做一个通讯薄软件都将是史无前人的挑战。成天讨论这门语言好，或者那门语言坏的人，甚至是可悲的。不但是悲其一叶障目，更要悲叹于那种大愚若智的自得心态。你仔细看看，在所有的算法描述中，有且仅有三种执行逻辑：顺序、分支和循环。简单若顺序表，复杂如树、图，它们的算法都是用上面这三种执行逻辑来描述的。在没有工程的时代，出现了非常非常多的人物。其中算法大师，有游戏大师，有语言大师，有挣钱的大师唯独，没有工程大师。嗯，可以理解嘛，那是没有工程的时代。好蛮荒，好远古的。绝对可以用面向过程的方法来实现任意复杂的系统。要知道，航天飞机也是在面向过程的时代上的天。但是为了使一切变得不是那么复杂，还是出现了面向对象程序设计的方法。我：倒也不是不可能彻底。有绝对OO的模型，这样的模型我见过。哈哈但说实在的，我觉得小应用用绝对OO的方式来编写，有失应用的本意。我们做东西只是要用，而不是研究它用的是什么模型。所以，Hello World也用OO方式实现，原本就只是出现在教科书中的Sample罢了。哈哈。Soul：还有不可能用彻底的面向对象方法来表达世界。因为这个世界不是面向对象的。是关系网络图，面向对象只是树，只能片面的表达世界。所以很多时候面向对象去解决问题会非常痛苦。所以编程退到数据结构更合理，哈哈。做管理起码需要能承担责任，这是最基本的素质。史记循吏列传记载了李离伏剑的故事。春秋时晋国最高司法长官李离，因为过听杀人，断狱失误，把一个不该处死的人错判了死刑。随后自拘于廷，请死于君，晋文公欲以其下属有过为由免他的罪，而李离说：臣居官为长，不与吏让位；受禄为多，不与下分利。今过听杀人，傅其罪下吏，非所闻也。随后拔剑自杀了同样的道理，你的项目经理职位又没有让给别人做，你拿的经理级工资又没有分给别人，那项目失败了，你为什么要把责任推到别人头上呢?做管理起码需要能承担责任，这是最基本的素质。三人团队中的那个领导，不是要程咬金一样的牛人，而是要李离一样的死士。项目完成不了，切脑袋的事倒不必做，递交辞呈的那点勇气总是要有的这些符号和标识也有个专用名称，En.这个叫模型语言(ML)。他们无时无刻不在向你展现他们的专业(这已经是他们还存在的唯一原因了)。如果他们更加专业，他们会告诉你他们用的是UML。向你介绍这个名词的时候，他们的眼镜或者眼睛里通常将大放异彩。到现在为止，你应该看到，咨询公司除了把问题搞得更加复杂之外，他们仍然需要面对最直接的问题：与客户如何交流?他们的解决之道是模型语言。有什么差别吗?程序员不能要求客户会C Language，难道需求分析师们就能要求客户会UML吗?！沟通的三层障碍第一层不再与你要表达的内容，而在于你如何表达，就是不知所云。对于两个聪明人来说，正确的结论通常只有一个，因此如果出现了争执，那么讨论的问题一定不是同一个问题。所以我们经常会读到一种文档，这种文档没有前提没有概要，开始就说我们如何做或者为什么要这样做你大概要在翻很多页之后才能找到一个结论：哦，原来这个家伙在说这件事。通常，如果一件事情正确，那它就是正确的，无论你的分析过程如何，结论也不过如此。所以你应该把结论放在文档的前边，把指导性的原则放在更前边，把事件的前因与目标以概要的形式放在最前边。一个聪明人只需要200字就可以说完的一件事，同样另一个聪明人也只需要这200字就能理解。对于一件事来说，起因、目标、结论和原则都已经确定了，生下来的过程控制还需要聚室而谋吗?第二层障碍出现在跟聪明人的讨论中，让人觉得不知所为如果一件事要足够长的时间才能讨论清楚，那么等他讨论清楚了，这件事本身也就失去了意义。讨论清楚事件A，与实施事件A之间的确是存在前后逻辑的，但如果维持这个逻辑的成本使得A不能被实时，那维持它的前提也就不存在了。除了事件这种沟通成本之外，沟通消耗的人力成本也是关键。事情A需要两个人来沟通与解决，与需要10个人沟通来解决，所消耗的成本显然是不一样的，人多不仅仅使得沟通变得更复杂。所以，一个结论是需要在大多数人之间作出还是只要在一两个人之间作出，是在一开始就要被确定下来的。用尽可能少的人，在尽可能短的事件内作出决定，这是降低沟通成本的关键。正因为有了人和事件这些成本因素的制约，所以我们讨论清楚再做这个假设可能就会很荒谬。第三层障碍的主要表现是不知急缓解决之道，则是不要把沟通目标设定为让对方认同在我们的确没有办法把一件事讨论清楚的时候，就是旁观的人最重要了。作为管理者，应当去观察、理解和发现问题(或者由专人想你汇报)。你要尽量去听去思考，因为作为这个角色，你总是有机会去纠正问题的。但是，不要急于去纠正-在一个会议上即时某种想法有问题，也绝不是在你发言的三分钟里就能纠正的，而是在最后你作出的决策里去纠正的。这种决策通常有两种：给出明确的答案存而不论看起来然你给出明确答案是职责所在，反过来说，存而不论就似乎是在推卸责任了。但是可能在某些情况下存而不论才是最好的决策。项目经理不是理论家，所以并不是一定要把一件事讨论清楚才能实作。理论是要以沟通成本为代价的，也可能以牺牲事件本身做代价。因此作为管理者，你应该适时地种终止讨论沟通不过是手段，是工具之一种，管理者的目标是项目本身。因此讨论不清楚就暂不清楚，让需要讨论的人(而不是整个团队)继续去讨论。于你而言，于整体而言，有的异无关宏旨无碍大局，可以存而不论。很多人把问题的本质给忘掉了。从最开始，从我们编程开始，我们的目的就是实现一个东西。无论这个东西是小到一个称手的工具，还是一个大到千万的工程，我们的目标，都是要实现它。工程只是一种实现的途径。最初做开发的前辈们，不用什么工程或者过程，也一样编出了程序，也一样解决了问题，也一样实现了目的。而现如今，我们讲工程了，讲过程了，讲方法了，却什么都再也做不出来了。不奇怪么?工程被当成了借口，掩盖了我们做事的真正目的：实现。因此，我们在一个项目中常常听到说工程要这样做，或者工程要那样做，而绝少听到项目要求这样做或者客户的本意是那样的。这样的结果是：我们做完了工程(的每一个过程)，却没有完成项目(的每一个实现目标)。为工程而工程的人，都迷失在项目中了。就象开发人员迷失在一个技术的细节上一样。专注于RUP或者RAD之间的区别的人，可以把每一个过程的流程图都画出来，却也被这每一个流程给捆绑得死死的，再也没有挣扎一下的力气。S公司午餐时间有一个规定：从11：30到12：10由部门一午餐，从12：10到12：50由部门二午餐，这给员工A带来了巨大的困扰：他必须学会记住什么时候去吃饭。对于一个要从11：30就开始关注的，在13：30之前必然发生的、并且将影响到他一下午的肚子是否咕咕响的问题，他不得不从11：30之前就开始留意。他可能选择盯着看电脑右下角的始终是否准时，也可能写着烟观察旁边的同时是否蠢蠢欲动。当然，对于一个开发人员来说，有一件事从11：30开始就不能做了：他不能再投入全部经历去开发。因为专注与一件事，就可能忘掉另一件事：吃饭。他们经常说的话是我通常习惯这样这样或者是我们以前怎样怎样又或者是我原来所在的部门如何如何这总让我想到一种奇特的动物，一种生活在水里，却长着肺的鱼。经验，是源于对过去的思考，而不是对过去的复制。过去有过辉煌的人，你是来解决问题而不是来分享成功的。千万不要把自己的经验直接拿到项目中来套。我曾经做过我这样想过对这个问题我思考过了这些言论只能把问题的根苗填实在团队的缝隙里。应该清楚的是，保障每一次沟通的有效性都是最重要的事情。沟通不是打电话或者请客户吃饭那样简单。你得到的每一次沟通机会，都是向客户了解更深层次的需求机会，因此最好在见到客户之前，你就已经设计好了所有的问题和提问方式。在很多的时候，我所听到的沟通，都是一种形式。例如与客户吃饭或者打回访电话。其实沟通是具有目的性的，如果在没有明确目的的情况下与客户沟通，那将是浪费客户和自己的时间。这种目的，可以是了解项目的讯息、挖掘潜在的项目最末了，才是交流感情在每一次回顾项目时都应该注意：流于形式的沟通，可能是使得你的项目被不断推翻和不断延迟的最直接原因。你不是团队的腿大凡是做技术出身的管理人员，总有愚公那种本能的实现欲望。如果一一件事自己能做而别人不能做或者做的不好，那么他总恨不得自己去做。但，一方面你根本不可能通过亲力亲为解决掉团队行进的问题；而在另一方面，你至少为团队带来了一下三重危险一：我必须跑到终点，否则团队到不了终点，这是每个人的责任，没人可以替代。你成为团队的腿，将使成员质疑自己的价值和能力，也忘却自己的责任。助长团队惰性，原来的执行曾变得效率地下，而管理层将疲于奔命。二：成员将失去在解决问题过程中学习的机会。三：对于一个人而言，成功的激励远远大于其它，一个从来没有享受过登顶乐趣的人，一定不会喜欢登山。你帮他跑到终点，实际上也是剥夺了他作为团队成员来分享成功的权利。让一个人总是去做没有成就感的工作，他将渐而生厌，你也无异于自毁长城。对于一个团队来说解决掉一个技术问题远远比团队的整体行进次要。因此你不要冲在前面披荆斩棘-把这个事情交给技术经理去做，或者教而习之，由成员自己去做。夫战，勇气也，一鼓作气，再而衰，三而竭振奋士气这件事情，经不起一再空耗即使所有的讨论结果都倾向于对这名员工的否定，你仍然可以给出一个机会来让这名员工去自我证明，这种机会可能只是几小时或者一两天的技术探索。这种情况下，如果他能证明他的正确，那他会感激这次机会。如果结论是他错了，你无形间树立了自己的威信，这件事，直说不是不行的问题其实就是你期望的东西和你体验的东西之间的差别。猿猴之为人，学会制作和使用工具是最重要的标志。因为我不知道语言只是工具这句话，究竟是对语言的膜拜，还是漠视。如同工程与编程，单以编程而论，讲究技法之精妙，追求细节与枝节是可以的；但对于工程来说，能让团队理解、统一执行、迅速有效的实战技法，才是真实所需的。就如陈康肃公，有当世无二之技，不能用于群站，也是无益。因此，我们最终看到拥有利器巧技的六国都不在了，最后只剩下一个强秦统一了天下。对于管理者来说，重要的并不是让大家都关注工程的每一个方面。工程管理者应当认识到开发人员的工匠思想的本质，并且善用之。在很多公司看来当官可能是对员工的最大激励。然而深处官场的人又如何能够理解技术人员的思想呢?其实很多的开发人员，无非是追求更宽松的工作环境，更好的学术研究分为。换而言之，他们跟地上就是关注于工具与技法的。公司应当给出员工在技术方向上的发展路线很多大公司在这一点上做的不错。他们把技术职级与管理职级分开。对于开发人员来说，吸引他的是无限的开发空间。例如当初微软打算用三百万年薪和数万股股票从BorLand挖走Anders Hejlsberg，未果。后来，盖茨提出给他一个小组和极多的资源，然他尽情地发挥，他这才动心，从此就有了VS.NET我开始了解Interface之后，才真正有了软件设计的观念。而一旦有了软件设计的观念，实现的过程就变得越来越不重要。真正做工程的人，只是简单地说：不平，刨之，不直，斗之。至于刨和斗是不是某个思想家，理论家或者实践家来发明的，与用不用他，没有关系。然而大多数人不会赞同你把工具拿来换个方式用。但我如今看来，这个工具的样子是不是刨或者斗都不再重要，只要能完成所需要做的事情就行了。例如我现在.有时候甚至会用PowerPoint来写代码，例如要表达一种动态的UI效果，我可以用Delphi IDE加一些组件，并写代码来完成，也可以用PPT的动画效果来做，而我通常会选择后者。无所谓是什么，只在乎他能不能用。一个工具无比强悍，但你可能只用它来输入几行代码。那么你输入这行代码就可以了，关注它那些强悍的功能干什么呢?于某时干某事，使用的就是最好的。前提是你要有看明白这些工具的实质的能力。只要能够分辨出所需的部分，适度地用在你的工程中，就可以了。何必把它看作救世良药，一味传道布道做信徒状呢。工具被如何设计的本质，就是为了应对不停变化的需求。而被重新设计的工具，又产生了新的用法。所以追根溯源，工匠们的思想，就都被禁锢在这生生不息的变化的需求中了。工具也因为这个过程而变得越来越复杂，似有万般功用。然而对于确定的项目来讲，只有对这个项目有用的那些功能，才是这个工具的价值所在。灵活的软件工程并不象现代人想见的那样，古诗词一定是逐字论平仄的。变化或者变通，其实是常见之事。因此古词谱中，才常会见到冠以摊破、减字、添字等字的词格。然则古人在词格上的这种变通，是基于音律的。通常说的词律是指词格，这与音律是两回事。词律(格)是平仄，音律则是乐器、音调与歌舞。古词中用来吟唱与歌舞的词牌就不能混用，律不同，调不同，如是之。注古人做词的变格，势必依音律而为之，舍周邦彦、东坡、辛弃疾此等人物，轻易变格，是为他人所笑话的。所以，词谱中所录变格既少，且俱为名家所创。然而古词的音律(亦即是律谱)已经失传了，也就是说，今天的词是用来读的，不是唱，也不是舞，甚至连吟哦也不是。所以今人总是拿普通话中的1、2声作为平声，3、4声为仄声来填词，并以此论平仄，而全然不想词的格律的根基是词律与音律这两个部分的融合。我曾经参与过一个讨论，叫古人是如何说话的。在我看来，古人做文章和说话是两回事，文章中之乎者也，日常交流中还是市井俚语的。因此评论中会说以俚语入词。也可见填词作文章与说话毕竟是不同。再者说话也存在方言的问题，因此方言之间平仄音调也当不同。古代的歌妓是要求会官话的，这相当于现在普通话的地位，她们歌唱起来，也是用的官话。更进一步的推论是：古代的词律中的平仄是以官