《条架构师须知》word版.doc

97条架构师须知【一】97条架构师须知【一】2011-06-30 07：34 A.M.1.Dont put your resume ahead ofthe requirements by Nitin Borwankar【需求先于履历】身为架构师要平衡客户、公司和个人的利益。用时兴的技术为个人履历增光添彩固然重要，但应该把客户的长远需求放在首位。约束技术偏好，能够使客户、团队、自己和家人都多些快乐。在未来的工作中，客户的口碑是比个人的履历更加宝贵的东西。2.Simplify essential complexity；diminish accidental complexity by NealFord【简化先天复杂性，避免后天复杂性】任何业务问题都有其复杂性，简化复杂性是客观需要。但为此采取的工作很可能带来新的复杂性。了解代码中真正用于处理业务的比例，从实践中发展出恰当的系统框架，避免随意添加框架。后天复杂性的积累会使系统越来越难以维护和升级。3.Chances are your biggest problemisnt technical by Mark Ramm【技术不是最大问题】聪明的架构师能够选择最恰当的技术，而有效的架构师则还要说服开发人员理解他的选择。软件是由人开发的，人心不齐才是最大的问题。有时人的问题导致项目失败，却让技术来背黑锅。必要时应进行平等的对话、理性的分析、耐心的解释。4.Communication is King；Clarityand Leadership its humble servants byMark Richards【沟通为王，澄清和引领为仆】闭门造车、发号施令的架构师必将被反抗的开发者所推翻。架构师应就项目的宗旨和目标与开发人员沟通。有效沟通的要点是简明和垂范。抛开长篇大论的Word文档，使用清晰易懂的Visio图形；讨论时使用白板，对重要的内容拍照记录。与QA、PM和开发人员密切合作，让他们了解架构过程，洞悉架构全景，引领他们走出迷茫。5.Architecting is aboutbalancing by Randy Stafford【在平衡中进行架构】架构工作包括模块划分、接口定义、职责分配、模式应用、性能优化等传统技术活动，也要考虑安全、可用性、支持、发布、开发条件等问题，更要照顾管理人员、操作人员、维护人员等有关各方的关切。要在平衡各方关切的过程中开展架构工作。6.Seek the value in requestedcapabilities by Einar Landre【鉴别客户要求中的价值】客户往往把他们的思考作为解决他们所面临的问题的方案。但客户要求未必都是对解决实际问题有价值的。架构师应当提出更好、更节约的解决方案。这一目标可以通过和客户进行讨论达到。和客户讨论时，多从业务角度问问为什么，少使用软件术语，不要假定客户具有软件方面的知识。7.Stand Up！by Udi Dahan【站着说话】架构师和项目组成员的沟通，不应象过去和机器打交道一样随意。当你的听众超过一个人时，自己就应当站着说话。站着说话的好处是有指挥整个房间的气势，增加了你的权威和自信，别人更不容易打断你的话。站着说话还能使用眼神交流、肢体语言，也有助于控制声音。站着说话，能提高沟通效果。8.Skyscrapers arent scalable byMicheal Nygard【摩天大楼不可伸缩】把软件工程比喻成盖楼，有好的一面。从荒芜的工地到耸立的高楼，过程漫长。每一段时间中，每一个工人都要各尽其责，每一个未完工的构件都要稳稳当当才行，值得软件工程学习，这就是一次一个组件的增量部署。这个比喻也有不恰当的一面。摩天大楼在造成以后就不可搬迁、不可加层。而软件则可以反复调整，这就是及早发布(Early release)。9.Youre negotiating more oftenthan you think.by Michael Nygard【谈判多过你的想象】我们作为工程师，更愿意与人协作。而项目负责人作为控制项目成本的人，更在乎削减成本。我们看到的是谈话，他看到的是谈判，所以我们常常遭受预算打击。如果你提了冗余、备份之类的东西后，他问你这个东西必须要有吗?,千万不要让步。不要说没有也行，只是会在故障恢复期间不能运行这样的话。反而要说：事实上不仅要两套，要四套才能确保万无一失。没有这个，每天就至少会有三次出问题，而且不排除当你正在给董事长做演示的时候出问题。10.Quantify by Keith Braithwaite【量化】需求必须量化。快、好、伸缩性、可用性、灵活、极少、大量等都不是需求，因为它们不可量化，这些词找不到客观的衡量标准。谈需求的时候，必须说明数目、时间、来源、去向，不能准确给出数值的，必须指明一个具体的范围。例如：最大响应时间1500毫秒，平均响应时间为750至1250毫秒。11.One line of working code isworth 500 of specification by Allison Randal【一行正确代码胜过千言万语】设计说明是宏观描述，代码则是微观实现。可是如果设计说明脱离了编码实现，犹如违背物理学原理的大楼设计，纵使它美轮美奂，也会转眼间土崩瓦解。架构师做设计时，要时刻想着编码人员如何实现它。设计完成后，如果程序员提出质疑，往往就是设计有问题，至少是设计不清晰。对设计进行再修改是正常的事情。12.There is no one-size-fits-allsolution by Randy Stafford【没有通用解决方案】一双鞋难合千人脚，过去积累的经验未必适合现在具体的应用情景，架构师要坚持锻炼自己的情景意识，按照新的情景进行设计。想要打造一个通用的解决方案往往造成过度设计，添加大量无关宏旨、甚至影响性能的不合理要求。13.Its never too early to thinkabout performance by Rebecca Parsons【尽早考虑性能】用户通常只会提出功能需求。架构师要尽早考虑非功能需求。性能测试也要及早展开。14.14.Application architecturedetermines application performance byRandy Stafford【软件系统架构决定性能】如果架构不良，性能就不会良好。资源不是无限的，动用再多的性能调优手段，到头来也是束手无策。15.Commit-and-run is acrime.by Niclas Nilsson【带错提交是祸害】下班时间到了才写完最后一行代码，干脆省略了编译、测试的过程，直接提交代码，迅速奔赴约会。这种做法使得隐藏的错误随着项目组其他开发人员更新代码而扩散，导致其他人不敢更新代码，打乱了大家的工作流程。个别开发人员把自己该做的工作留给他人是错误的。当然，架构师也应考虑给开发人员创造好有利的环境。比如，自动构建工具、自动测试工具、测试驱动开发实践、持续集成服务器等。16.There Can be More than One by Keith Braithwaite【世界并非千篇一律】技术上能做到强求统一，实现一套数据模型、一种消息格式、一套收发系统，如此等等。可是业务世界往往是不一致、多侧面、甚至模糊的。统一的设计未必能满足各种业务要求，应当要允许那些互相矛盾、重复或交叉的非功能特性存在。17.Business Drives by Dave Muirhead【业务决定技术】为了建设一个系统，架构师必须把技术部门和业务部门团结在一起。但要明白二者的立场是不同的，避免技术人员作出业务决策。建造系统通常都是讲求投资回报的，从开工到投产要不断遇到各种技术上的决策，要一直以满足业务部门的要求为准则，才能获得最大的投资回报。如果业务部门对技术部门的提问迟迟不予答复，那么可以视为委托开发团队考虑。即使这样也不能直接将问题交回给技术人员，因为业务问题是宏观问题，技术决策是微观问题。架构师应当组织讨论并拿出答案。18.Simplicity before generality,use before reuse by Kevlin Henney【先简化再泛化、先使用再重用】用户掏钱买的往往不是什么通用的功能，大多数时候他们只看重其中自认为重要的部分。设计的产品要先满足具体的要求，经过实践并简化掉那些不必要的东西，才能进行泛化推广；要先有使用的机会，才能带来重用的机会。如果一开始就以通用、重用为目的闭门造车，结果很可能是无用、难用、弃用。19.Architects must be handson by John Davies【架构师必须是高手】架构师不是空谈家，他必须在数据库、软件编程、数据信息、网络等某一领域有专长并且通晓其它领域，换句话说，他要想带领团队就必须知道团队成员需要知道的技术。架构师和项目经理，好比飞机上的副驾驶和驾驶。飞机常常是副驾驶操纵，可是关键时刻得看驾驶的。项目经理忙于日常任务安排、资源调配，而架构师看似清闲，而在技术决策中要提出重要的意见，对保证项目的质量和按期交付起着很大的作用。20.Continuously Integrate by Dave Bartlett【持续集成】过去软件项目中提倡及早构建、及时发布，以便尽早发现风险、避免风险。随着自动构建技术日趋成熟，现在已经能够做到持续集成了。持续集成(CI)工具可以自动构建、测试，在完成时还能向外发送电邮或即时信息。21.Avoid Scheduling Failures byNorman Carnovale【避免延期】人的工作能力是有限的。同样的工期内要增加工作量，就难免延期。不增加工作量但是强求缩短工期反而常常导致延期。因为，赶工通常造成设计不良、缺陷数量上升、测试不足等问题，日后处理这些问题反而需要更多的时间。因此，碰到有人要求缩短工期，应坚决主张原定工期。确实必须缩短工期的，就要将部分非必需功能从开发任务中剔除，留待下一期开发中去处理。这是一个协商谈判的过程，架构师要有一定的技巧才能处理好。22.Architectural Tradeoffs by Mark Richards【架构中的取舍】没有哪个系统能同时做到高性能、高可用、高安全、高通用。架构师要带领同事和客户开诚布公地沟通，先满足重要的目标，再满足次要的目标。23.Database as aFortress by DanChak【数据库即堡垒】开发团队的人员是流动的，用户的人员也是来来往往的，但是架构师要保证有一个东西不变，那就是数据库结构。从项目的第一天，就要抱着建造堡垒一样的态度设计数据库，使它能经历时间流逝和需求微调的考验。24.Use uncertainty as adriver by Kevlin Henney【以不确定为动力】生活中人们期待有多种选择，可如果自己设计软件，却往往喜欢省事，在几个选项中只采用一个。如此一来，软件对用户就不那么平滑顺手。一个设计是否良好，是用修改所需的成本来衡量的。当遇到技术上的选择时，不要匆忙决定，要退一步想想有没有不进行选择的办法?只在是非分明、条件明确的情况下才需要选择。25.Scope is the enemy ofsuccess by Dave Quick【项目规模是成功的敌人】架构师如果好大喜功，不切实际地扩充项目的范围，在时间、人力、物力、功能、质量等级、交付难度、风险系数、约束条件等方面不断加码，使项目变大、变复杂，那么就是在促使项目走向失败。当项目规模扩充时，失败的可能性也在以更快的速度增加。以下是避免规模增长的几个策略：(1).求真务实：真实的需求是什么(客户的底线在哪里)?(2).各个击破：这个项目不能再分解成几个各自独立的小项目吗?(3).主次有别：哪些是重要而稳定的需求?哪些是次要而易变的需求?(4).及早发布：错误是不可完全避免的，早点让用户见到作品就是给自己留下改正错误的时间。26.Reuse is about people andeducation,not just architecture byJeremy Meyer【重用要靠受过教育的人员】一个设计良好、漂亮、可重用的框架或者代码库，只能由了解它、会用它、相信它的人来使用。(1).了解：没有人会去查找自己不知道的东西，只有在公司中将它的信息推送到开发人员和设计人员面前，他们才会了解它。(2).会用：一点便通的人很少，大多数人必须经过培训才会使用它。(3).相信：新来的人往往瞧不起旧的东西，他们倾向于通过重头编写来证明自己的才能，要设法让他们相信重用成熟稳定的组件框架胜过自己编写。27.There is noIinarchitecture by Dave Quick【架构中没有我字】不成熟的架构师爱犯的毛病是：以为自己比客户懂需求；把开发人员看作实现自己主张的资源；听不进和自己不同的意见。以下认识有助于架构师的成长：(1).不是架构师决定架构，是完整准确的需求决定架构，因此要密切接触客户进行需求分析。(2).架构不是架构师一个人的，是整个团队的，架构师需要队员远胜于队员需要架构师，因此要从心底尊重他们、团结他们。(3).模型不算是架构，只有能用的模型才是架构，因此要和组员一起进行演练以便检查确认模型能支撑需求。(4).自我肯定、自我保护是人的天性，遇到压力便表现出来，因此要每天花几分钟审视自己：是否对他人表达了应有的敬意和谢意?是否冷淡了他人的善意?是否真的明白他人为何与自己意见不同?28.Get the 1000ft view by Erik Doernenburg【生成低空视图】要了解地面的情况，需要适当的高度。在30000英尺的高空只能看到大块的轮廓，不能看到它的结构；在地面则迷失在身边的细节里而失去整体感觉；在大约1000英尺的低空，刚好能看清楚地面的结构。类似地，要了解软件系统的质量也要适当的距离。系统架构图太宏观，很多关系不清楚；源代码又太微观，关系太琐碎；只有在类和方法这一级生成图表，才能评估软件的质量。29.Try before choosing by Erik Doernenburg【试了再选】选择哪一个框架?使用哪个代码库?架构师不能坐在象牙塔的顶端做出设计并颁布给开发人员使用。在做出技术选择之前，他应该放低身段，找开发人员商量，让他们对可选的几种方案分别实现，再提出各自的建议，最后由架构师综合分析决定使用哪一种方案。30.Understand The BusinessDomain by Mark Richards【了解业务领域】软件架构既要采用高超的技术，又要深刻地反映业务领域的特点，才能实现业务目标。比如，保险业适用面向服务的架构，金融业适用基于工作流的架构。了解业务的最高标准，就是能用业务语言和公司的老总级人物交流。业务领域的知识是不断更新的，比如汽车保险业新出现的一种临时停车保险，就是一种新的业务动向。能够把握领域发展动向，就能未雨绸缪，当公司有需要时可以迅速提出解决方案。31.Programming is an act ofdesign by Einar Landre【编程是创意设计，不是照图施工】汽车厂要出一辆新汽车，必须经历概念车创意设计、流水线生产这两大阶段。软件编程中，主要的工作是都是创意设计，很少照本宣科的。既然大家都知道设计新车型、开发新药物这样的工作往往不能按时完成，也不能确保成功，那么我们也不要指望软件编程可以精确预测。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 Fa?ade)、传输对象(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