张逸:晴窗笔记

老美的国庆节自然不是10月1日，因此在我们举国同庆祖国60华诞的日子里，他们不得不呆在Office里继续上班，所以微软在那天发给我的邮件，我到今天才看到。邮件的主题是“恭喜您成为Microsoft MVP”。想起来，这已经是我的连续第四任了。从2006年10月第一次被评上MVP开始，到现在还没有一次落选，这让我感到很欣慰。实际上，在这三年的时间（第四任MVP的任期是从今年１０月到明年。不过，微软准备将MVP任期调整到与自然年相同，所以不知这一届的任期是到什么时候结束），我在社区发表了无数篇与微软技术相关的文章，同时，还撰写以及翻译（与徐宁合译）了一本书（著作目前正在写第二版，而译著的第二版也由我承担，目前译稿已经交付出版社，就等着出版了）。尤其在InfoQ担任编辑之后，我的翻译量骤增，加上我自己写的一些原创文章，以及在技术方面的日积月累，使我在申请连任MVP时，显得底气十足。

但我深知，自己现在还存在诸多不足。技术的道路是没有止境的，我丝毫不敢懈怠。现在的我，除了平时的工作，主要是为我的第二本书做大量的准备，翻阅了大量的文献与著作，更需要从项目中总结经验。目前，我关注的技术重心还是在软件架构方面。经历得越多，越觉得自己无知。我还有很长的一段路要走。或许，过一段时间，我希望能写一些系统解决方案中关于架构的文章，尤其是架构模式在实际开发的运用。我正在学习Ruby，现在的我已经为动态语言之美而深深折服。未来，我希望能够用Ruby On Rails来开发自己的个人网站。当然，WCF和WF自然不能完全丢弃，这两个重量级技术在企业开发中是如此的重要，我怎么能够就此放弃呢？

恩，在微软创新日重庆站，我还将担任讲师，负责讲解“开启Web创新新篇章——ASP.NET MVC技术与微软Web平台简介”。我期待10月15日，在重庆市图书馆，与你们见面。

在我看来，我从第一版出版之后得到的读者反馈实在是有限。除了有少数几位细心的读者给我指出书中的错误之外，大体上就都是泛泛而谈了。这对本书第二版的写作带来一些障碍。因为我无法知道读者对每一章的评价，不知道哪些章节对大家有益，哪些章节还有不足之处。我只能根据自己的经验来揣摩读者的想法，对第一版的内容进行改善。同时，在新版中增加第一版出书之后所获得的新知识与新认识。第二版在风格上仍然沿袭了第一版的特色，但内容无疑更加丰富。

在第一篇《设计之要》中，我会增加两个新的章节，分别介绍面向对象思想与设计原则，以及领域驱动设计。同时，删去原书的第5章《设计，由你掌握》。增加的这两章，前者是讲解设计基础，而后者则会以一个完整的案例为读者展现领域驱动设计的要点、宗旨、原则和相关思想。第五章的部分内容会合并到原书第1章《设计之道》与第2章《封装变化》之中。此外，我会极大地丰富第1章的内容，企图通过这一章为读者全面介绍软件设计的相关思想与技术。对于《封装变化》一章，我修订了一些小小错误，同时增加了“封装对象结构变化”一节。关于解除具体耦合，原书只是简单介绍了依赖注入。第二版不仅会深入介绍依赖注入，还将增加注入表驱动法、惯例优于配置、服务定位器等模式与方法。对于原书第3章和第4章对于重构和测试驱动开发的介绍，我准备更换一下演示的案例。尤其是重构一章，关于数学容器的设计实在太过于简单了。

第二篇《.NET Framework与设计模式》在第一版是针对.NET 2.0进行分析的。在第二版会针对最新的.NET框架进行分析。这一篇的变动不会太大，但可能会增加一些在.NET框架中的设计模式分析。目前，我已经完成了第6章《Factory Method模式》和第7章《Composite模式》的修改。我修改了第6章的Factory Method模式的例子。而在第7章，我则改善了原有的设计，使之更加完美和优雅。

第三篇《媒体播放器的设计之旅》的变化或许会比较大。因为我会开发一个真实的媒体播放器，用以演示各种模式的运用。因此，可能会增加几种模式的运用，不过关于第一版中讲解Adapter模式的章节，则可能会删去。

第四篇《设计模式应用实践》仍然沿用旧有的风格。我会对第17章的Builder模式案例进行调整，因为本章的案例对于Builder模式的应用还不够典型。第18章《Command模式应用实践》的案例不会改变，但我会进一步完善它，尤其是充分利用Command模式的特性。第19章《Chain of Responsibility模式应用实践》写得过于矫情，我可能会考虑删去它，也可能会用另外的案例代替。经读者提醒，第21章《Proxy模式应用实践》存在一个小小的错误，我会在第二版中对其进行修正。第22章《复合的设计模式实践》思想是好的，但明显有过度设计的嫌疑，且设计思路并不够好。我会考虑对其进行大的手术。此外，我可能还会增加一些章节，不过具体有哪些，我现在还说不清楚。

第五篇《.NET体系架构设计》叙述的内容以现在看来，过于陈旧了。我会在其中适度地增加体系架构设计的相关知识。最关键的是，第二版不再以PetShop作为讲解的模板，拟考虑对DinnerNow（或者StockTrader）进行分析。在这一篇中，会增加对LINQ、WCF、WF等知识的介绍。当然，介绍的思路与结构不会发生太大的变化，仍然以分层式架构作为主体框架。

极限编程中有一条著名的懒汉原则，称之为KISS原则，KISS是Keep it simple and stupid的缩写。简略地说，就是设计尽量保证简单。极限编程坚持只为今天的需求设计以及编码，而不用考虑明天。这颇有一些“做一天和尚撞一天钟”的意味。

这个原则带来一个问题，那就是我们还需要设计吗？

我们强调设计，其目的就在于设计出合理、优雅的结构，以提供具有良好复用性与可扩展性的系统，这是一种未雨绸缪，为未来考虑。而现在，我们若要遵循KISS原则，就是不再考虑明天的需求。显然，这两者的观点是相悖的。于是，矛盾出现：一方面我们需要保持设计简单，不做无谓的功能预测；另一方面，我们又需要拥抱变化，在尽可能少的改变结构与代码的情况之下，满足未来的需求。

如何解决这个矛盾。让我们先看看提出简单原则的初衷。在《敏捷开发思想之拥抱变化》一篇中，我提到需求的变化是不可避免的。即使是最优秀的需求分析师和架构设计师都不可能在项目之初穷尽所有客户要求的功能，作出最完美的分析与设计，即做到“增之一分则太多，减之一分则太少”。我们需要把握分析和设计的“度”。但事实却是，我们总喜欢越俎代庖，利用自己的经验帮助客户提出需求，而事后证明这些需求往往是多余的。我们总是在重复做着“吃力不讨好”的事情，与其如此，还不如在事先偷懒取巧。因为需求的变化总是不可控的，根据“利益趋避原则”，自然应选择对自己更有利的一个趋向。

但这种简单并不是“简陋”，即使我们不需要考虑明天的需求，一些好的重用原则与可扩展原则仍然需要遵循。例如，我们应尽量保证对象是高内聚、低耦合的；我们应遵循“面向接口编程”原则。一言以蔽之，我们需要做到：
1、减少依赖；
2、合理抽象；
3、功能最简。

简单设计还需要重构来保证设计的质量。我们之所以敢于奢谈“简单”，正是因为重构的保障。即使设计过于粗陋，合理利用重构也能够亡羊补牢。在重构过程中，我们仍然需要遵循简单原则，仅为当前的需求对系统结构进行重构。例如，我们在最初的需求分析中，只有一个功能要求发送电子邮件。那么，我们可以编写一个方法来封装发送电子邮件的实现，这个方法甚至可以放在业务对象的私有方法中。随着需求的逐步演进，新增的几个功能同样需要发送电子邮件，此时就有必要利用重构技术，将原来发送电子邮件的方法独立到单独的类中。但是，基于简单原则，我们没有必要完善所有功能，例如增加发送Meet Request的功能。因为目前的需求并不需要。

“简单”并不只限于设计。在敏捷开发过程中，我们还需要保证项目计划的简单，以及文档的简单，乃至于过程的简单。项目计划的简单可以由小步行进的迭代周期来保证，通过对项目阶段的分解，简化项目计划。至于文档的简单，我们完全可以抛弃复杂标准的文档模板，转而书写仅仅是自己需要关注的内容。至少，项目内部的文档完全可以言之有物，而不需要注重形式。我们还可以通过对项目过程进行裁剪，来保障过程的简单性。事实上，在极限编程中，很多原则和实践都是为了实现简单而提出的。例如计划游戏、小版本、简单设计，包括持续集成和代码所有权，都是为了提高开发过程的效率，这实际上也是简单的一种体现。

“简单最好”是一种心态，更是一条原则。

Scott等就ASP.NET MVC 1.0编写了Professional ASP.NET MVC 1.0一书，并提供了免费的第一章、第二章下载。其中，第一章以一个完整的案例NerdDinner讲解了如何使用ASP.NET MVC技术对网站进行开发。这个一篇指导意义非常强的教程，对于ASP.NET MVC的初学者是最合适不过的教学案例了。第一章提供了html版和PDF版，EntLIb论坛对 这些内容进行了翻译，提供了比较完整的HTML中文版。HTML网页固然方便，但毕竟过于零散，不如PDF文档显得正式和统一。此外，EntLib对 Scott的案例作了少量的修改，增加了EntLib的标识。同时，该网站还省略了教程中集成地图的部分，我觉得略有遗憾。所以，我在EntLib的基础 上，完善了整个文档的翻译，还原了英文版的本来面目，并提供了PDF格式的文档。

内容包括：
1、创建MVC Web Application
2、创建数据库
3、创建Model模型
4、控制器和视图
5、创建、更新、删除记录
6、模型绑定的安全性
7、ViewData和ViewModel
8、Partials和Master页面
9、认证和授权
10、AJAX实现RSVP响应
11、集成AJAX地图
12、单元测试
13、依赖注入

完整文档下载：ASP.NET MVC Step by Step中文版

在WS-*标准和规范中，WS-Discovery是在2008年才加入了OASIS标准。WS-Discovery在标准被定义为Web Service Dynamic Discovery，其目的是为定位服务定义Discovery协议，主要应用在为客户端动态搜索一个或多个目标服务。OASIS为WS- Discovery提供了两种操作模式：ad hoc和managed模式。

ad hoc模式根据类型在托管目标服务的范围内查找目标服务。客户端会以多播的形式发送一个Probe（探测）消息，如果服务匹配该信息，则以单播方式直接将响应发送到客户端。为了能够根据名称定位目标服务，客户端会以相同的多播组发送一个Resolve（解析）消息，同样的，匹配该消息的服务会直接以单播方式响应客户端。消息交换的流程如下图所示：

全文阅读>>

最 佳的架构、需求和设计出自于自组织的团队。蜂巢中的工蜂们看似忙碌，但其工作却是有序而有效，归根结底就是它们的组织架构其实是自我组织的。在自我组织的 团队中，团队是一个整体，没有角色之分、职位之分、也没有高下之分。团队成员的任务不是项目经理强加于身，而是根据自己的愿望和能力对任务进行合理评估， 并主动进行领取。被动与主动所产生的驱动力显然不可同日而语。

自我组织的团队是一个平行的组织，由于没有管理与被管理之间的关系，因而氛围更加和谐，组织更加开放，管理更加松散，这种自由化的组织方式更容易让团队成 员体现自我价值，对团队会产生一种认同感，促发他们的开发热情，从而提高开发效率。平等的关系会促进团队成员的有效沟通，自由的管理有助于发挥团队成员的 技术特长，开放的平台则能够保证协作的效率。一个卓越的团队应该是目标一致，团结协作，同时又能各司其职，有条不紊。

自我组织的团队建立在团队个人能力的基础之上。它其实是一把双刃剑。如果团队成员个人能力有限，或者自我约束能力较差，而管理人员又无法把握松散管理的度，就很可能出现一些问题。例如：
1、团队人员无所适从，不知道该做什么。很多开发人员对敏捷方法不能适应，他们已经习惯了听从命令与安排的方式；
2、任务安排不平衡，团队成员在开发过程中偷工减料。耽于安逸的开发人员或许会利用管理的漏洞或管理人员对他的信任，胡乱估计任务的工作量，或者夸大任务实现的难度；
3、自由失去节制，无论是技术方案的讨论和评审，还是任务工作量的评估，因为没有绝对权威，很容易失去控制，因纠缠于细节而让大量的讨论浪费时间。

如 何解决这三个问题？对于第一个问题，基本无解，除非你有足够的煽动力或超凡的演讲能力，改变这些开发人员的思想，乃至于开发习惯。最佳方式是循序渐进，并 对自我组织的方式进行改进，例如和传统的管理方式结合起来。或者就放弃敏捷的管理方式吧。如果说敏捷是鱼，只能在水中生活，你怎么能让它上岸呢？

对于第二个问题，需要动用团队的力量。例如对任务的评估，我们可以利用计划游戏，或者设计计划纸牌对任务工作量进行估算。总之，我们应尽量让团队对任务工作量的估算不要出现太大的偏差，使任务的开发在可控的范围内。此外，及时召开回顾会议，也是杜绝这类问题的一件利器。

第三个问题需要团队的管理者建立某些准则，例如对技术问题的讨论设定时间的限制。一旦超出该时间，就应该把问题放在一边，或者由管理者利用自己的权威和经验下定结论，而不能无限制的争执下去。

自 我组织的团队管理者需要因时因人而置宜。Larry L. Constantine在《人件集》中提到：“对于开放型的团队来说，最好的领导应该表现得像他们中的一个同事一样，能够参与所有的技术问题讨论，包括分 析、设计和系统构建。”例如在Scrum中，团队角色就是一个自我组织的团队，由团队来确定每个Sprint的工作内容。而Scrum Master就不再是控制者，而是指导者；不是上司，而是教练。他必须理解自组织团队的重要性。

自我组织是敏捷管理的精髓，也是敏捷管理成败的关键！

秉承敏捷宣言的精神（个体与交付重于过程和工具；可用的软件重于完备的文档；客户协作重于合同谈判；响应变化重于遵循计划），我认为，敏捷开发大致应该体现如下的思想：拥抱变化、自我组织、简单最好、客户至上、有效沟通、精益求精。

1、拥抱变化

Kent Beck和Martin Fowler在介绍极限编程（eXtreme Programming）时，最先提到的就是要拥抱变化。这基本上代表了敏捷阵营对于变化的一种态度，那就是不拒绝，而且还要主动求变。有一句经典的论断 说得好：“在软件开发领域中，唯一的不变就是变化。”其实，不仅仅是软件开发领域，世间万事万物都处在永恒的变化之中，这是宇宙的基本规律。奥巴马在竞选 美国总统的时候，提出的口号就是“变化”。变化才是真正的常态。

传统的软件开发过程由于过分强调文档的完整，重视与客户的谈判与签订合同。 所以，开发团队最希望的一件事情是冻结需求规格说明书。只要双方签字，需求就确定下来，不可更改。若要更改，必须经过需求变更委员会，走非常严格的需求变 更流程。如果软件开发真能如此，倒也算是我们开发人员的幸事。但现实总是残酷的，需求总是会变化。变化的原因有以下几种：
1）业务发生了变化；
2）客户对业务的理解发生了变化；
3）需求分析人员对需求的理解出现了偏差，需要修正。

对于第一点，或许我们还能够根据合同与客户讨价还价，而对于后两点，尤其是第三点，我们显然是不可拒绝的。而敏捷方法则要求团队随时响应客户的需求，针对变化给出相应的解决方案。

如何拥抱变化呢？我想可以通过如下方式来实现：
1）现场客户

很 多开发团队并不喜欢客户对他们指手画脚，甚至认为他们不停提出的需求变化让他们疲于应对。但现场客户给团队开发带来的益处还是要远远超过他带来的坏处。无 论团队中聚集了多么权威的领域专家，但真正了解客户需求的还是客户自己。也许他们很难用语言来表述自己的想法，但有了和现场客户的及时沟通，我们才能够在 发生变化的初始就能够获得第一手的资讯。如果事情总要发生，早解决绝对比晚解决要好，而且要好得多。

如果在开发中，没有办法让客户成为团队 的一员，那么我们也应该指定一位客户代表，退而求其次，也应该在团队中指定一位业务专家负责业务事宜，也就是Scrum中Product Owner的角色。总之，我们需要在项目开发中，能够让开发人员在对需求理解发生困惑时，能够明确地知道由谁来负责。而一旦需求发生变化，也必须有专门的 角色负责向整个团队或者相关人士传达。至于业务功能的优先级和重要程度排定，也必须由这个角色指定。

2）定期迭代和小版本交付

不仅要定期迭代，而且要尽可能地让迭代周期短，并及时交付可以工作的小版本发布。XP的迭代周期通常为一周，而发布一个小版本大约是一个月。而Scrum则将迭代称之为Sprint，持续时间推荐为一个月。Sprint结束就需要向客户展示当前迭代完成的版本。

敏 捷方法绝对不可闭门造车，因为需求总是可能存在二义性，且需求总是处于不断的变化中。若能定期交付一个可以工作的小版本，一方面可以给与开发团队和客户以 信心，另一方面也有助于我们及时获得客户的反馈。而衍生带来的还有一个好处是我们可以免费找到最优秀的测试人员了，那就是我们的客户。如果没有现场客户， 则小版本的交付则显得尤为重要，因为它给了我们及早修订错误的机会。

3）持续改进

开发过程总是会出现错误，无论是开发方法、技能，还是团队管理与团队合作。持续地改进我们的开发方法、管理方法与开发过程，才能够及时而有效地解决错误，避免重蹈覆辙。一个能够持续改进的团队是一个成长的团队，同时必然会是一个拥抱变化的团队。

在 Scrum中，每个Sprint完成并结束了评审会议之后，都会召开一个回顾会议，即使总结优秀经验，检讨错误与教训，团队方能够从错误中成长起来。此 外，回顾会议还能够帮助团队正确地认识自己，帮助团队成员进行交流与沟通。作为“鸡”角色的客户若能参加回顾会议，可以让客户更直观地了解团队，比提出自 己的看法，有助于在后面的开发过程改善合作的质量。

设计模式最经典的书籍自然是GOF的《设计模式》，但很多人的反应是这本书太难理解了，并不适合初学者阅读。这话说得在理。一方面，本书使用的C++示例难倒了一大群Java和.NET的开发人员；另一方面，这本书的风格过于专业化，更偏向于学术论文的风格（事实上，本书的雏形就是来源于GOF中Erich Gamma的博士论文），因此就显得有些晦涩难懂了。

基本上，本书可以作为我们参考的标准，是经常查阅的文献资料。如果你对某个设计模式还有困惑不解之处，阅读本书，然后细细品味，总会给你一些豁然开朗的感觉。夸张点说，这本书可以说是设计模式的红宝书，即使人手一册，也不为过。说句题外话，我还是喜欢外版书的封面设计，给人一种艺术的美感，让人看着就有想买的冲动。国内专业书籍的装帧与设计，做得好的，真的很少。

全文阅读>>

本讲义主要包括以下三部分：面向对象三要素、面向对象五原则和面向对象六视点。面向对象三要素包括：封装(Encapsulation)、继承 (Inheritance)、多态(Polymorphism)。五原则自然是众所周知的OO五原则：单一职责原则、开放封闭原则、Liskov替换原则、依赖倒置原则和接口隔离原则。前面两部分内容是大多数OO设计都需要掌握的内容，在讲解中虽然加入了我的一些理解，但讲义中并无太多新鲜的东西。最后一部分则是我这段时间对面向对象的认识与思考，分别包括：复用、扩展、分离、变化、简约和一致。这些内容是我的第二本著作的雏形，当然讲义中展现的内容仅仅是冰山一角，不过大体框架已经具备了。

讲义下载：OOD.pdf

Mediator模式有一种本事，就是可以让本身需要互相协作的对方，可以不用知道彼此，而把两者之间的联系，转交给Mediator来处理。换句话说，Mediator模式解除了需要互相协调的对象之间的依赖。这也是Mediator（调停者）模式名字的由来。一个颇为形象的例子是聊天室。进入聊天室的用户总是要彼此通信的，这些对象如果直接进行交互，就会彼此连接，最后织成一张纷繁复杂的大网。要分清彼此之间的关系，真可以说是“剪不断理还乱” 了。所以，引入一个聊天室对象来管理用户间的交流，就势成必然。

全文阅读>>

站立会议对于Scrum的意义，就像我们每天早上起来总是希望看看报纸，听听新闻，了解每日时事，关心国计民生。站立会议有助于Scrum Master以及整个团队了解项目进展情况，以便于控制项目进度，掌握团队成员的开发效率，促进成员之间的交流与沟通，并使所有成员对整个项目能有一个全面的认识。

站立会议的重要性不言而喻。如何遵循Scrum的原则开展好每天的站立会议呢？我在推行的Scrum实践中，发现站立会议总是会随着项目的进展，慢慢地发生变形，最后甚至会变得物事人非。幸运的是，每日的会议却没有理由地达成了Scrum的目的。那么，在Scrum开展站立会议是否一定要极为死板地遵循Scrum的原则？我认为未必。以下是我在推行Scrum过程中的一些粗浅认识。

全文阅读>>

罗素说：“参差多态是幸福的本源”。我们的生活若能丰富多彩，每天都是新鲜的，就会觉得生活有滋有味，生命是有价值的，而我们的存在则是幸福而有意 义的。如果每天的生活都是在重复，人就容易过得浑浑噩噩，茫然不知生活的乐趣，最后得过且过，浪费了自己的生命。我常常觉得，作为一名软件开发人员，或许 是幸福的，因为在这个行业中，每天都有新鲜的技术与技能产生，每天都有许多未知的东西等待我们去探索，去学习，去分析。但这种幸福也许从本质上讲，是“痛 并快乐着”。新鲜的技术让我们兴趣盎然，但这种快如流星的技术更新速度，又有些让我们应接不暇。

全文阅读>>

6日晚，参会的InfoQ编辑和国际讲师们一起在恭王府边的四川饭店腐败了一次。腐败的地方选得很好，居然就在清朝第一贪官和绅府的旁边。这是我第 一次参加InfoQ的线下活动，也是与中文站编辑的初次谋面。有了网络就是神奇，虽然素昧平生，却已是多年好友。国际讲师也是济济一堂，包括 Thoughtworks首席科学家Martin Fowler，Spring之父Rod Johnson，eBay架构师Randy Shoup，《硝烟中的Scurm和Xp》作者、敏捷教练Henrik Kniberg，Dojo Toolkit的联合创始人Dylan Schiemann，当然还有我们InfoQ的老大、C4Media的总裁Floyd Marinescu。为了便于编辑与这些讲师之间的交流，组织人特定将我们这些编辑与讲师们交叉坐在一起。我正好就坐在Martin Fowler和Randy Shoup中间。Martin Fowler的大胡子看来有些威严，我只向他表达了几分仰慕之情，什么敬仰如滔滔流水之类的，就没有多言语了。反而是Randy长得比较慈眉善目，和他相 谈甚欢。谈了架构，SOA以及云计算，谈到Java平台与.NET的整合，也谈到了eBay的架构设计。除了技术，自然还要谈点轻松的内容。例如川菜、中 国文化，以及他对北京的感受，甚至谈到了旧金山的天气。抓住这个机会，我还给他宣传了我所在的城市——重庆，欢迎他到重庆去品尝品尝重庆火锅。这是 Randy第一次到北京，所以多向他灌输一点中国的悠久文化，也可以培养培养他对中国传统文化的敬仰之情。我教他说中文，听他大着舌头痛苦地讲着“你好 ”，颇感到Randy的几分可爱之处。没想到Randy还知道中文“花椒”，一问之下，原来他妹妹的什么亲戚曾经在香港呆过一段时间，还曾向他们邮寄过“ 花椒”。原来如此。

全文阅读>>

ByteBlocks的博客文章中总结了开发WCF/Silverlight的注意事项，这样的经验之谈字字千钧，可以让后来的开发者少走许多弯路。

绑定的选择

毫无疑问，我们应该选择BasicHttpBinding，这也是Silverlight仅仅支持的一种绑定。

全文阅读>>

Shivprasad koirala在CodeProject上发表了一篇文章Windows Workflow Foundation FAQ，介绍了WF的基础知识。这对于理清WF的整个脉络有一定帮助，摘译如下。

什么是Windows工作流基础？

WWF（张逸注：微软的官方简称为WF）是一种编程模型，用于在Windows中构建支持工作流的应用程序。WF程序集的命名空间为System.Workflow。

全文阅读>>