当你熟悉了一门语言之后，你会发现，编程语言只有喜欢与不喜欢的问题，没有会不会的问题。任何的一门语言，你都可以在两周内掌握并开始熟练编程。因为任何的一门语言，他们的底层函数库都是那么的相似，而他们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)并不知道这些技巧、技术和方法的原理，因而不知道变通，也不知道回避错误。
所以死读一本《软件工程》的人不会做真正的软件工程。
所以我写《大道至简——软件工程实践者的思想》