迷迷糊糊的工作了这么长时间，竟然忙得忘记了最初的梦想.doc

迷迷糊糊的工作了这么长时间，竟然忙得忘记了最初的梦想迷迷糊糊的工作了这么长时间，竟然忙得忘记了最初的梦想。继续努力啦！(二)2011-06-29 23：3431.Programming is an act ofdesign by Einar Landre?xml：namespace prefix=o ns=urn：schemas-microsoft-com：office：office/【编程是创意设计，不是照图施工】汽车厂要出一辆新汽车，必须经历概念车创意设计、流水线生产这两大阶段。软件编程中，主要的工作是都是创意设计，很少照本宣科的。既然大家都知道设计新车型、开发新药物这样的工作往往不能按时完成，也不能确保成功，那么我们也不要指望软件编程可以精确预测。32.Time changes everything by Philip Nelson【时间改变一切】随着时间的流逝，当初各路高手所设计的高瞻远瞩、机关算尽的框架、模式、范例、算法，有的如过眼云烟般消散得无影无踪了，有的则最终流传下来。历史带给我们三个启示：(1).坚持有价值的领域：如果我们熟悉的领域已经没有价值，要勇于探索新的领域，即便早期的尝试不成功，也要克服困难坚持下去，正确的领域总会有正确的方案，尽管它也许来得很晚。(2).简单规则：克服我们自身把问题复杂化的倾向，让方案保持简单。想一想，那些复杂的东西，如今哪个还在呢?(3).珍惜旧东西：虽然过去的东西不完全适合于现在的情景，可是把经历了时间考验的东西修一修，不是也很有把握满足新的需要吗?33.Give developers autonomy by Philip Nelson【让开发人员自治】架构师的职责不是要对开发人员如何工作进行指点。架构师的责任是在开发人员致力于编制类和方法、进行单元测试、创建数据库时，保证这些部分合在一起能正常运行。了解他们的痛处，做出对应的改进。测试困难吗?那就改善接口并减少依赖。领域抽象性不够或过度?那就澄清它。开发顺序不清楚?做个计划吧。开发人员使用API时总犯相同的错误?那要把API的设计调整得更简单明白。人们真的理解设计吗?和他们交流阐述吧。不确定哪些地方需要伸缩性吗?去和客户交流并了解他们的业务模型吧。总之，架构师要给开发人员创造一个工作环境，而不是干涉开发人员份内的工作。34.Value stewardship overshowmanship by Barry Hawkins【做管家，不做演员】管家是为雇主精打细算的人，演员是为观众哗众取宠的人。架构师提出的解决方案，关系到公司的人力、财力、物力和时间。公司把架构师职责授予一个人，他就要替公司平衡投入和产出比例。正如理财师要对客户承诺收益率一样，架构师也要时刻考虑公司的收益，而不能把项目当成自己显摆的舞台。35.Warning,problems in mirror maybe larger than they appear by Dave Quick【问题可能大于表象】项目中出现问题，往往得不到重视，最后难于收拾。原因主要有：对问题习以为常的温水煮青蛙效应；人们对新经历、新知识的畏惧心理；开发人员不以为然的乐观主义倾向；组员只关心个人目标不重视全局目标；人都有盲点，尤其是对自己的缺点视而不见。要克服以上不利因素，可以从这几方面着手：建立组织级别的风险管理机制；不搞少数服从多数，要鼓励悲观论调并进行讨论，进而提出中立的对策；敞开心胸，不断听取客户意见；让自己信任的人指出自己的盲点。36.The title of software architecthas only lower-caseas；deal with it by Barry Hawkins【软件架构师是新兴职业】软件架构师是一门新兴的职业，可是它具有律师、医生、建筑师一样的精英特质。大家努力吧！37.Software architecture hasethical consequences by Michael Nygard【软件架构也有伦理后果】说到人权、身份盗用、恶意程序等等，人们知道软件架构可以助人行善，也可以助人作恶。其实除了大是大非问题，平时很多地方都值得进行伦理思考。比如说，一个软件好用则千万个用户都省事，一个软件难用则千万个用户都麻烦，他们的轻松愉快或者垂头丧气不就取决于我们架构师吗?为了他们长久的简便，我们要承担一时的幸苦。软件影响太多的人了，不要设计违背伦理的软件，哪怕一点点都不要做。38.Everything will ultimatelyfail by Michael Nygard【万物皆会出错】硬件会出错，所以用冗余来对付。软件会出错，所以用监控软件来对付。可是监控软件也是软件啊，所以错误还是不可避免。网络是由硬件和软件组成的，所以网络的错误就是难免的了。怎么办?我们不能拒绝错误，我们必须接受错误。承认万物皆会出错，接着设计出适当的失败模式，才能让我们的系统安全地出错。例如，承认汽车是会撞车的，然后设计可压缩的部件来吸收撞击的能量，起到保护乘客的作用。在软件系统中，如果不设计失败模式，失败偏偏就会让你措手不及。39.Context is King by Edward Garson【情景为王】情景为王，简单性是它谦恭的仆人。所谓情景，指的是业务驱动力、新兴技术和思想潮流。首先要敞开思路，关注情景中各种各样的因素，给它们排出优先级，然后才能制定出简单的解决方案。40.Its all about performance by Craig LRussell【处处都要考虑性能】如果有一种车宽敞、舒适、省钱又环保，就一定卖得好吗?非也。一辆牛车即使达到这样的标准也未必有几个人去买。原因就在于它速度太慢了。软件设计也是一样，功能重要，性能也一样重要。性能不单单指系统响应时间，还包括用户操作步数、用户思考时间、用户输入时间等。性能还包括那些自动执行而不与人互动的部分，比如每日夜间处理任务。试想一下，如果一个每天夜间执行的任务到了第二天的夜间还没执行完，将会带来难以预料的后果。41.Engineer in the whitespaces by Michael Nygard【设计空白处】架构图通常由一些方块表示互相依赖的系统，它们之间用箭头连接，箭头边上写着小小的几个字，剩下的就是大片的空白。这空白处看似什么都没有，可是在现实中，有网卡、入侵检测系统、防火墙、消息队列服务、数据格式转换服务、通信设备，甚至可能穿越万水千山。因此，在这个箭头旁，还是要把一些重要问题考虑清楚：(1).调用方操作太过频繁怎么办?忽略、礼貌地拒绝或者竭力满足?(2).如果响应超时则调用方怎么办?重试、等待或视为接收方故障?(3).双方收到的数据版本或者格式与期待的不一致时怎么办?(4).两方中的任何一方短暂消失会有什么影响?举个例子，假设有个箭头写的是HTTP搭载的SOAP-XML，它可能会有这样的注释：期待每个HTTP请求包含一条查询，每个HTTP响应发回一条查询结果。每秒最多接受100次请求，在99.999%比例下请求响应时间小于250毫秒。42.Talk the Talk by Mark Richards【入行说行话】专业人士之间常用行话交流，而架构师最重要的行话就是架构模式。模式可以按照层次范围划分为四类：企业架构模式、应用架构模式、集成模式、设计模式。企业架构模式处理高层架构，设计模式处理组件内部的架构。常见的企业架构模式有事件驱动架构(EDA)、面向服务架构(SOA)、面向资源架构(ROA)以及管道架构(PA)。应用架构模式是企业架构内部应用或子系统架构的模式，例如J2EE中的会话面(Session Faade)、传输对象(Transfer Object)模式。集成模式是在应用、子系统、组件之间共享信息和功能的模式，比如文件共享、远过程调用和各种消息收发模式。设计模式是最底层的模式，是架构师和开发人员交流的标准词汇。还要了解反面模式(anti-patterns)，也就是那些反复出现、起负作用、需要避免的过程。常见的反面模式包括分析麻痹(Analysis Paralysis)、委员会设计(Design By Committee)、蘑菇房管理(Mushroom Management)、死亡征途(Death March)等。了解架构模式何以让我们更清楚、简洁、高效地沟通，所谓入行说行话(walk the walk and talk the talk)。43.Heterogeneity Wins by Edward Garson【异构取胜】在分布式软件系统中，通信协议已经发生了一个重要的演变，就是从二进制协议向文本协议转变。文本协议，比如用于Web服务的XML/SOAP、表述性状态转移(REST)、原子资源(Atom)、可扩展消息传递及呈现协议(XMPP)，使得通信更为简单灵活，系统的不同部分可以按照自己的需要选择不同的编程语言，以便发挥最佳的效果。由此形成的异构系统，必将超越过去由单一语言主宰的系统。44.Dwarves,Elves,Wizards,andKings by Evan Cofsky【小矮人、精灵、巫师和国王】RandyWaterhouse在Cryptonomicon中将他遇到的人分为四类，他们是：小矮人(Dwarves)：他们在黑暗的洞穴中辛勤劳动，制作出漂亮的物品。他们的手艺名扬四方，他们的力量改变着大地。精灵(Elves)：他们温文尔雅，终日创造美丽神奇的东西。他们天赋极高，能实现其他种族不可思议的东西。巫师(wizards)：他们精通魔法，无比强大。国王(Kings)：他们是领袖，知道如何调遣其他角色。架构师好比是国王，该熟悉各个角色，还要保证所设计的架构中具有这些角色的位置。只为个别角色设计架构，就只能吸引个别的角色，不能发挥大家的特长。一个好国王，会给大家树立追求的愿景，会让大家各司其责，共同学习，共同成长，实现目标。45.Learn from Architects ofBuildings by Keith Braithwaite【向建筑师学习】建筑是一种社会行为，是人类活动的物质场所。-Spiro Kostof(在建筑中要充分考虑人和社会的因素)良好的教育和丰富的心灵也许能造就伟大的头脑，却不能造就伟大的建筑。-Frank Lloyd Wright(不断尝试和改进才能接近完美)医生出了错可以将死人埋掉，建筑师出了错只能让客户种爬藤遮丑。-ibid(避免设计错误很重要)建筑师坚信，不仅要做上帝身边的助手，还应该伺机取得上帝的宝座。-Karen Moyer(要立志精通客户的业务)在建筑中和在一切操作艺术中一样，最后都要归于操作。操作的结果应当就是良好的建筑。好建筑有三个条件：有用、牢固、愉悦。-Henry Watton(好东西不经要有用、耐用，还要赏心悦目啊)建筑师一定是雕塑家或画家。如果他不是雕塑家或画家，他只能做个建筑工。-John Ruskin(美很重要)听起来有点矛盾、但它的确是一个重要的真理：没有哪个建筑能达到无瑕疵的崇高。-ibid(好作品也带有作者和时代的局限性)46.Fight repetition by NiclasNilsson【消除重复】软件开发中有两条真理：抄袭是作恶；重复劳动降低开发速度。如果一个项目的软件大量存在复制、粘贴、修改的工作方式，或者不同地方都在处理验证、审核、日志、数据持久化之类的工作，那么就有严重的重复问题。消除重复是架构师的职责。完全顺序书写的代码只适合于给计算机执行，良好的代码是给人读的，要让人读起来清楚、高效、轻松，那么就要消除重复性。使用恰当的框架(包括面向方面编程框架)、对功能进行再抽象等，都是消除重复的方法。47.Welcome to the Real World byGregor Hohpe【走进现实世界】工程师喜欢精确，01世界的软件工程师尤其喜欢按部就班的顺序处理，喜欢是非分明。可是现实世界却是凌乱的。客户下单之后很快又要取消，支票被拒付，信件丢失，付款延期，承诺落空。用户不按要求输入数据，不按规定步骤操作。分布式系统带来了更多的不一致性：服务连不通，不发通知就改接口，没有事务保证。现实就是这个样子，早晚总会出问题，你得承认它。但也别太害怕。事件驱动编程、状态机模式、错误重试等这些都是可以采用的技术。只是，在现实世界里，你要记住：星巴克咖啡店不适用两阶段提交。48.Dont Control,but Observe byGregor Hohpe【宁观察、不控制】过去的系统比较简单而固定，在架构上是实现设计模型，按模型控制构建过程。但是，21世纪的软件开发中，在松耦合的基础上对软件提出了随着时间演化的柔性(flexible)要求，因此就不再能够严格控制。针对这种情况，可以先不用设计静态的结构，而是在演化中持续观察，从观察所得到的数据中抽象出当时的模型，按照规则对模型进行验证，保证它没有循环依赖、空接收通道的消息发送等问题。49.Janus the Architect by DaveBartlett【向雅努斯学习】雅努斯(Janus)是罗马神话中的门神，他有两个头颅，守卫着过去通向未来的大门。架构师要向雅努斯那样，能倾听客户的诉求、分析他们的趋势。他设计出来的架构既要满足眼前的需要，又要适应即将到来的变革，经得起时间的考验。50.Architects focus is on theboundaries and interfaces by EinarLandre【架构师关注边界和接口】处理复杂系统的基本策略是分而治之、各个击破。架构师要将整个系统划分成若干情景(Context)，各个情景有自己明确的边界(Boundary)，情景之间有组织归属、功能使用或者技术依赖关系，这些关系通过接口来具体实现。关注边界和接口的结果，是形成低耦合、高内聚的系统。51.Challenge assumptions-especially your own by Timothy High【不要想当然】因为assume(想当然)=ass(蠢驴)+u(你)+me(我，所以想当然会使你我与蠢驴为伍。没有事实依据的道听途说未必正确，没有事实依据的主观臆断往往是错的。即使正确的结论，也因时势的变迁而发生改变。所以，在架构设计中，但凡要在几种选项之间做出取舍的地方(比如性能与可维护性、成本与上市时间等)，都要提供选择的理由。理由不能只是简单的论断，要有考查的要素(比如技术条件、人员技能、政策环境等)及其事实依据，。52.Record your rationale by Timothy High【记录你的理由】在作出技术取舍的时候，都要提供选择的理由。提供理由的方式是把它记录下来。要说明做了什么决定、选择了什么、拒绝了什么，为何选这种而不选那种。这些文档可以让开发人员理解架构设计的内在逻辑、让客户理解为何某些部分要求更加昂贵的硬件设备、让将来条件改变以后对系统架构进行修改更容易。53.Empower developers by Timothy High【培养开发人员】架构师要尽力培养开发人员。为他们提供足够的设备、网络、数据、资料。保证他们具有所需的技能，不足的就要安排培训。开发人员除了能动手实践，还要参与学术讨论，所以如果有出差经费的要让组员参加各种宣讲或会议，没有经费的也要加入技术性的邮件列表并参与本地的一些活动。平庸的团队不可能做出大事情，要尽可能参加选择开发人员的过程，寻找那些对技术好学上进并且善于与团队合作的人。在和软件设计的大目标不冲突的地方，要让开发人员自主决策。制定编码原则、编码规范。保护开发人员免受不必要的文字工作、办公室杂务等打搅。架构师虽然不是项目经理，但在软件开发过程方面要积极参与管理，消除各种障碍。54.It is all about the data by Paul W.Homer【软件都跟数据有关】一般讨论编码的时候，都是站在面向指令的视角，讲命令、函数、算法。可是要理解一个复杂的系统(比如UNIX操作系统)，就很难在成千上万行代码中理出头绪。这时，如果我们关注代码下面的数据(比如UNIX系统的文件、进程等)，就相对容易理解些了。形成这种对比的原因是代码很庞杂，而数据则很简洁。后者就是面向数据的视角。大多数问题的核心是数据问题。关注数据，能更容易地处理复杂系统问题。要在系统建设早期完整地设计数据结构，避免在系统建设过程中或投入运行后再来修改数据结构。数据结构修改将导致大量的代码修改。55.Control the data,not just thecode by Chad LaVigne【控制数据，而不只是代码】只有由代码自动构建程序的工具是不够的。手工或者编写脚本来修改数据库、添加数据不仅效率低下，而且容易出错。自动构建工具不仅要考虑代码的变化，还要考虑数据结构的变化，它们是不可分割的一个整体。56.Dont Stretch The ArchitectureMetaphors by David Ing【不要让比喻误导他人】在描述抽象或新的设计时，架构师喜欢使用比喻。可是，比喻容易让人误解。比如，一个游艇一样的系统，言者可能指的是池子里的小船，而听者理解的是横跨太平洋的豪华游轮。又比如，一个文件柜，言者只是想表示内容是按字母排列的，而听者却想的是文件柜有六个面、上面还嵌入了一个钟表。只在开始的时候使用比喻，然后要迅速转入精确的描述，不能停留在比喻上。57.Focus on Application Supportand Maintenance by Mncedisi Kasper【关注应用支持与维护】很