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

当你熟悉了一门语言之后,你会发现,编程语言只有喜欢与不喜欢的问题,没有会不会的问题。任何的一门语言,你都可以在两周内掌握并开始熟练编程。因为任何的一门语言,他们的底层函数库都是那么的相似,而他们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 声为仄声来填词,并以此论平仄,而全然不想词的格律的根基是“词律”与“音律”这两个部分的融合。

        我曾经参与过一个讨论,叫“古人是如何说话的” 。在我看来,古人做文章和说话是两回事,文章中之乎者也,日常交流中还是市井俚语的。因此评论中会说“以俚语入词”。也可见填词作文章与说话毕竟是不同。再者说话也存在方言的问题,因此方言之间平仄音调也当不同。古代的歌妓是要求会“官话”的,这相当于现在“普通话”的地位,她们歌唱起来,也是用的“官话” 。更进一步的推论是:古代的词律中的平仄是以官话为基础的。然而如今的普通话毕竟不是古时的“官话”,也就是说,即使我们以普通话的四声为基础在论平仄,在古人看来,也是可笑的:这样做出来的词,依旧不可唱,也不可读。

        因此今人做词的标准,是应该重定的了。除了词格(这里仅指字句的格式)和用韵之外,其它的部分是无法遵循的了。在各字的平仄以及句式上,应当以“能通顺”和“能品味”为准,风格上则以古雅为益。 仅此而已。

        对于我这样的格律观点,一位网友曾有一句“未蕴而变,自欺也。知律而变,智者之道也”,实为良言。变向不变求。不变者,万变之所源,亦万变之所归。习诗词之法度,若蚕虫之结茧,若无结茧于前,何有破茧于后?故,知律而变,智者之道也。 “知律而变”中的“律”字,若解释作“规律”,那么便是可以用于软件工程中的了。“道”是规律,如果明“道”,而可以变化无穷,这样做软件工程才是活的。就如同今人难于填词一样,不明道,则不明智,不明智则无所以为,因而在软件工程实施中不可避免的盲目与停滞。  “知律”的另一层意思,是在于“知道原理”。明白“为什么要这样”或者“为什么不是那样”。这在软件开发中是常见的问题,大多数人不知究竟地使用着技巧和方法,而一旦出了问题,则归究于这些技巧和方法的不好。而真正的问题在于,这些人(我们通常叫做 Copy&Paster)并不知道这些技巧、技术和方法的原理,因而不知道变通,也不知道回避错误。

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

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

posted on 2010-07-17 00:51  ybwang1989  阅读(...)  评论(...编辑  收藏

导航

统计