条架构师须知一.docx
《条架构师须知一.docx》由会员分享，可在线阅读，更多相关《条架构师须知一.docx（15页珍藏版）》请在冰豆网上搜索。
条架构师须知一
97条架构师须知【一】
97条架构师须知【一】2011-06-3007：
34A.M.1.Don'tputyourresumeaheadoftherequirementsbyNitinBorwankar
【需求先于履历】
身为架构师要平衡客户、公司和个人的利益。
用时兴的技术为个人履历增光添彩固然重要，但应该把客户的长远需求放在首位。
约束技术偏好，能够使客户、团队、自己和家人都多些快乐。
在未来的工作中，客户的口碑是比个人的履历更加宝贵的东西。
2.Simplifyessentialcomplexity；diminishaccidentalcomplexitybyNealFord
【简化先天复杂性，避免后天复杂性】
任何业务问题都有其复杂性，简化复杂性是客观需要。
但为此采取的工作很可能带来新的复杂性。
了解代码中真正用于处理业务的比例，从实践中发展出恰当的系统框架，避免随意添加框架。
后天复杂性的积累会使系统越来越难以维护和升级。
3.Chancesareyourbiggestproblemisn'ttechnicalbyMarkRamm
【技术不是最大问题】
聪明的架构师能够选择最恰当的技术，而有效的架构师则还要说服开发人员理解他的选择。
软件是由人开发的，人心不齐才是最大的问题。
有时人的问题导致项目失败，却让技术来背黑锅。
必要时应进行平等的对话、理性的分析、耐心的解释。
4.CommunicationisKing；ClarityandLeadershipitshumbleservantsbyMarkRichards
【沟通为王，澄清和引领为仆】
闭门造车、发号施令的架构师必将被反抗的开发者所推翻。
架构师应就项目的宗旨和目标与开发人员沟通。
有效沟通的要点是简明和垂范。
抛开长篇大论的Word文档，使用清晰易懂的Visio图形；讨论时使用白板，对重要的内容拍照记录。
与QA、PM和开发人员密切合作，让他们了解架构过程，洞悉架构全景，引领他们走出迷茫。
5.ArchitectingisaboutbalancingbyRandyStafford
【在平衡中进行架构】
架构工作包括模块划分、接口定义、职责分配、模式应用、性能优化等传统技术活动，也要考虑安全、可用性、支持、发布、开发条件等问题，更要照顾管理人员、操作人员、维护人员等有关各方的关切。
要在平衡各方关切的过程中开展架构工作。
6.SeekthevalueinrequestedcapabilitiesbyEinarLandre
【鉴别客户要求中的价值】
客户往往把他们的思考作为解决他们所面临的问题的方案。
但客户要求未必都是对解决实际问题有价值的。
架构师应当提出更好、更节约的解决方案。
这一目标可以通过和客户进行讨论达到。
和客户讨论时，多从业务角度问问为什么，少使用软件术语，不要假定客户具有软件方面的知识。
7.StandUp！
byUdiDahan
【站着说话】
架构师和项目组成员的沟通，不应象过去和机器打交道一样随意。
当你的听众超过一个人时，自己就应当站着说话。
站着说话的好处是有指挥整个房间的气势，增加了你的权威和自信，别人更不容易打断你的话。
站着说话还能使用眼神交流、肢体语言，也有助于控制声音。
站着说话，能提高沟通效果。
8.Skyscrapersaren'tscalablebyMichealNygard
【摩天大楼不可伸缩】
把软件工程比喻成盖楼，有好的一面。
从荒芜的工地到耸立的高楼，过程漫长。
每一段时间中，每一个工人都要各尽其责，每一个未完工的构件都要稳稳当当才行，值得软件工程学习，这就是一次一个组件的增量部署。
这个比喻也有不恰当的一面。
摩天大楼在造成以后就不可搬迁、不可加层。
而软件则可以反复调整，这就是"及早发布"（Earlyrelease）。
9.You'renegotiatingmoreoftenthanyouthink.byMichaelNygard
【谈判多过你的想象】
我们作为工程师，更愿意与人协作。
而项目负责人作为控制项目成本的人，更在乎削减成本。
我们看到的是谈话，他看到的是谈判，所以我们常常遭受预算打击。
如果你提了冗余、备份之类的东西后，他问你"这个东西必须要有吗?
",千万不要让步。
不要说"没有也行，只是会在故障恢复期间不能运行"这样的话。
反而要说：
"事实上不仅要两套，要四套才能确保万无一失。
没有这个，每天就至少会有三次出问题，而且不排除当你正在给董事长做演示的时候出问题。
"
10.QuantifybyKeithBraithwaite
【量化】
需求必须量化。
"快"、"好"、"伸缩性"、"可用性"、"灵活"、"极少"、"大量"等都不是需求，因为它们不可量化，这些词找不到客观的衡量标准。
谈需求的时候，必须说明数目、时间、来源、去向，不能准确给出数值的，必须指明一个具体的范围。
例如：
最大响应时间1500毫秒，平均响应时间为750至1250毫秒。
11.Onelineofworkingcodeisworth500ofspecificationbyAllisonRandal
【一行正确代码胜过千言万语】
设计说明是宏观描述，代码则是微观实现。
可是如果设计说明脱离了编码实现，犹如违背物理学原理的大楼设计，纵使它美轮美奂，也会转眼间土崩瓦解。
架构师做设计时，要时刻想着编码人员如何实现它。
设计完成后，如果程序员提出质疑，往往就是设计有问题，至少是设计不清晰。
对设计进行再修改是正常的事情。
12.Thereisnoone-size-fits-allsolutionbyRandyStafford
【没有通用解决方案】
一双鞋难合千人脚，过去积累的经验未必适合现在具体的应用情景，架构师要坚持锻炼自己的情景意识，按照新的情景进行设计。
想要打造一个通用的解决方案往往造成过度设计，添加大量无关宏旨、甚至影响性能的不合理要求。
13.It'snevertooearlytothinkaboutperformancebyRebeccaParsons
【尽早考虑性能】
用户通常只会提出功能需求。
架构师要尽早考虑非功能需求。
性能测试也要及早展开。
14.14.ApplicationarchitecturedeterminesapplicationperformancebyRandyStafford
【软件系统架构决定性能】
如果架构不良，性能就不会良好。
资源不是无限的，动用再多的性能调优手段，到头来也是束手无策。
15.Commit-and-runisacrime.byNiclasNilsson
【带错提交是祸害】
下班时间到了才写完最后一行代码，干脆省略了编译、测试的过程，直接提交代码，迅速奔赴约会。
这种做法使得隐藏的错误随着项目组其他开发人员更新代码而扩散，导致其他人不敢更新代码，打乱了大家的工作流程。
个别开发人员把自己该做的工作留给他人是错误的。
当然，架构师也应考虑给开发人员创造好有利的环境。
比如，自动构建工具、自动测试工具、测试驱动开发实践、持续集成服务器等。
16.ThereCanbeMorethanOnebyKeithBraithwaite
【世界并非千篇一律】
技术上能做到强求统一，实现一套数据模型、一种消息格式、一套收发系统，如此等等。
可是业务世界往往是不一致、多侧面、甚至模糊的。
统一的设计未必能满足各种业务要求，应当要允许那些互相矛盾、重复或交叉的非功能特性存在。
17.BusinessDrivesbyDaveMuirhead
【业务决定技术】
为了建设一个系统，架构师必须把技术部门和业务部门团结在一起。
但要明白二者的立场是不同的，避免技术人员作出业务决策。
建造系统通常都是讲求投资回报的，从开工到投产要不断遇到各种技术上的决策，要一直以满足业务部门的要求为准则，才能获得最大的投资回报。
如果业务部门对技术部门的提问迟迟不予答复，那么可以视为委托开发团队考虑。
即使这样也不能直接将问题交回给技术人员，因为业务问题是宏观问题，技术决策是微观问题。
架构师应当组织讨论并拿出答案。
18.Simplicitybeforegenerality,usebeforereusebyKevlinHenney
【先简化再泛化、先使用再重用】
用户掏钱买的往往不是什么通用的功能，大多数时候他们只看重其中自认为重要的部分。
设计的产品要先满足具体的要求，经过实践并简化掉那些不必要的东西，才能进行泛化推广；要先有使用的机会，才能带来重用的机会。
如果一开始就以通用、重用为目的闭门造车，结果很可能是无用、难用、弃用。
19.ArchitectsmustbehandsonbyJohnDavies
【架构师必须是高手】
架构师不是空谈家，他必须在数据库、软件编程、数据信息、网络等某一领域有专长并且通晓其它领域，换句话说，他要想带领团队就必须知道团队成员需要知道的技术。
架构师和项目经理，好比飞机上的副驾驶和驾驶。
飞机常常是副驾驶操纵，可是关键时刻得看驾驶的。
项目经理忙于日常任务安排、资源调配，而架构师看似清闲，而在技术决策中要提出重要的意见，对保证项目的质量和按期交付起着很大的作用。
20.ContinuouslyIntegratebyDaveBartlett
【持续集成】
过去软件项目中提倡及早构建、及时发布，以便尽早发现风险、避免风险。
随着自动构建技术日趋成熟，现在已经能够做到持续集成了。
持续集成（CI）工具可以自动构建、测试，在完成时还能向外发送电邮或即时信息。
21.AvoidSchedulingFailuresbyNormanCarnovale
【避免延期】
人的工作能力是有限的。
同样的工期内要增加工作量，就难免延期。
不增加工作量但是强求缩短工期反而常常导致延期。
因为，赶工通常造成设计不良、缺陷数量上升、测试不足等问题，日后处理这些问题反而需要更多的时间。
因此，碰到有人要求缩短工期，应坚决主张原定工期。
确实必须缩短工期的，就要将部分非必需功能从开发任务中剔除，留待下一期开发中去处理。
这是一个协商谈判的过程，架构师要有一定的技巧才能处理好。
22.ArchitecturalTradeoffsbyMarkRichards
【架构中的取舍】
没有哪个系统能同时做到高性能、高可用、高安全、高通用。
架构师要带领同事和客户开诚布公地沟通，先满足重要的目标，再满足次要的目标。
23.DatabaseasaFortressbyDanChak
【数据库即堡垒】
开发团队的人员是流动的，用户的人员也是来来往往的，但是架构师要保证有一个东西不变，那就是数据库结构。
从项目的第一天，就要抱着建造堡垒一样的态度设计数据库，使它能经历时间流逝和需求微调的考验。
24.UseuncertaintyasadriverbyKevlinHenney
【以不确定为动力】
生活中人们期待有多种选择，可如果自己设计软件，却往往喜欢省事，在几个选项中只采用一个。
如此一来，软件对用户就不那么平滑顺手。
一个设计是否良好，是用修改所需的成本来衡量的。
当遇到技术上的选择时，不要匆忙决定，要退一步想想有没有不进行选择的办法?
只在是非分明、条件明确的情况下才需要选择。
25.ScopeistheenemyofsuccessbyDaveQuick
【项目规模是成功的敌人】
架构师如果好大喜功，不切实际地扩充项目的范围，在时间、人力、物力、功能、质量等级、交付难度、风险系数、约束条件等方面不断加码，使项目变大、变复杂，那么就是在促使项目走向失败。
当项目规模扩充时，失败的可能性也在以更快的速度增加。
以下是避免规模增长的几个策略：
（1）.求真务实：
真实的需求是什么（客户的底线在哪里）?
（2）.各个击破：
这个项目不能再分解成几个各自独立的小项目吗?
（3）.主次有别：
哪些是重要而稳定的需求?
哪些是次要而易变的需求?
（4）.及早发布：
错误是不可完全避免的，早点让用户见到作品就是给自己留下改正错误的时间。
26.Reuseisaboutpeopleandeducation,notjustarchitecturebyJeremyMeyer
【重用要靠受过教育的人员】
一个设计良好、漂亮、可重用的框架或者代码库，只能由了解它、会用它、相信它的人来使用。
（1）.了解：
没有人会去查找自己不知道的东西，只有在公司中将它的信息推送到开发人员和设计人员面前，他们才会了解它。
（2）.会用：
一点便通的人很少，大多数人必须经过培训才会使用它。
（3）.相信：
新来的人往往瞧不起旧的东西，他们倾向于通过重头编写来证明自己的才能，要设法让他们相信重用成熟稳定的组件框架胜过自己编写。
27.Thereisno'I'inarchitecturebyDaveQuick
【架构中没有"我"字】
不成熟的架构师爱犯的毛病是：
以为自己比客户懂需求；把开发人员看作实现自己主张的资源；听不进和自己不同的意见。
以下认识有助于架构师的成长：
（1）.不是架构师决定架构，是完整准确的需求决定架构，因此要密切接触客户进行需求分析。
（2）.架构不是架构师一个人的，是整个团队的，架构师需要队员远胜于队员需要架构师，因此要从心底尊重他们、团结他们。
（3）.模型不算是架构，只有能用的模型才是架构，因此要和组员一起进行演练以便检查确认模型能支撑需求。
（4）.自我肯定、自我保护是人的天性，遇到压力便表现出来，因此要每天花几分钟审视自己：
是否对他人表达了应有的敬意和谢意?
是否冷淡了他人的善意?
是否真的明白他人为何与自己意见不同?
28.Getthe1000ftviewbyErikDoernenburg
【生成低空视图】
要了解地面的情况，需要适当的高度。
在30000英尺的高空只能看到大块的轮廓，不能看到它的结构；在地面则迷失在身边的细节里而失去整体感觉；在大约1000英尺的低空，刚好能看清楚地面的结构。
类似地，要了解软件系统的质量也要适当的距离。
系统架构图太宏观，很多关系不清楚；源代码又太微观，关系太琐碎；只有在类和方法这一级生成图表，才能评估软件的质量。
29.TrybeforechoosingbyErikDoernenburg
【试了再选】
选择哪一个框架?
使用哪个代码库?
架构师不能坐在象牙塔的顶端做出设计并颁布给开发人员使用。
在做出技术选择之前，他应该放低身段，找开发人员商量，让他们对可选的几种方案分别实现，再提出各自的建议，最后由架构师综合分析决定使用哪一种方案。
30.UnderstandTheBusinessDomainbyMarkRichards
【了解业务领域】
软件架构既要采用高超的技术，又要深刻地反映业务领域的特点，才能实现业务目标。
比如，保险业适用面向服务的架构，金融业适用基于工作流的架构。
了解业务的最高标准，就是能用业务语言和公司的老总级人物交流。
业务领域的知识是不断更新的，比如汽车保险业新出现的一种临时停车保险，就是一种新的业务动向。
能够把握领域发展动向，就能未雨绸缪，当公司有需要时可以迅速提出解决方案。
31.ProgrammingisanactofdesignbyEinarLandre
【编程是创意设计，不是照图施工】
汽车厂要出一辆新汽车，必须经历概念车创意设计、流水线生产这两大阶段。
软件编程中，主要的工作是都是创意设计，很少照本宣科的。
既然大家都知道设计新车型、开发新药物这样的工作往往不能按时完成，也不能确保成功，那么我们也不要指望软件编程可以精确预测。
32.TimechangeseverythingbyPhilipNelson
【时间改变一切】
随着时间的流逝，当初各路高手所设计的高瞻远瞩、机关算尽的框架、模式、范例、算法，有的如过眼云烟般消散得无影无踪了，有的则最终流传下来。
历史带给我们三个启示：
（1）.坚持有价值的领域：
如果我们熟悉的领域已经没有价值，要勇于探索新的领域，即便早期的尝试不成功，也要克服困难坚持下去，正确的领域总会有正确的方案，尽管它也许来得很晚。
（2）.简单规则：
克服我们自身把问题复杂化的倾向，让方案保持简单。
想一想，那些复杂的东西，如今哪个还在呢?
（3）.珍惜旧东西：
虽然过去的东西不完全适合于现在的情景，可是把经历了时间考验的东西修一修，不是也很有把握满足新的需要吗?
33.GivedevelopersautonomybyPhilipNelson
【让开发人员自治】
架构师的职责不是要对开发人员如何工作进行指点。
架构师的责任是在开发人员致力于编制类和方法、进行单元测试、创建数据库时，保证这些部分合在一起能正常运行。
了解他们的痛处，做出对应的改进。
测试困难吗?
那就改善接口并减少依赖。
领域抽象性不够或过度?
那就澄清它。
开发顺序不清楚?
做个计划吧。
开发人员使用API时总犯相同的错误?
那要把API的设计调整得更简单明白。
人们真的理解设计吗?
和他们交流阐述吧。
不确定哪些地方需要伸缩性吗?
去和客户交流并了解他们的业务模型吧。
总之，架构师要给开发人员创造一个工作环境，而不是干涉开发人员份内的工作。
34.ValuestewardshipovershowmanshipbyBarryHawkins
【做管家，不做演员】
管家是为雇主精打细算的人，演员是为观众哗众取宠的人。
架构师提出的解决方案，关系到公司的人力、财力、物力和时间。
公司把架构师职责授予一个人，他就要替公司平衡投入和产出比例。
正如理财师要对客户承诺收益率一样，架构师也要时刻考虑公司的收益，而不能把项目当成自己显摆的舞台。
35.Warning,problemsinmirrormaybelargerthantheyappearbyDaveQuick
【问题可能大于表象】
项目中出现问题，往往得不到重视，最后难于收拾。
原因主要有：
对问题习以为常的温水煮青蛙效应；
人们对新经历、新知识的畏惧心理；
开发人员不以为然的乐观主义倾向；
组员只关心个人目标不重视全局目标；
人都有盲点，尤其是对自己的缺点视而不见。
要克服以上不利因素，可以从这几方面着手：
建立组织级别的风险管理机制；
不搞少数服从多数，要鼓励悲观论调并进行讨论，进而提出中立的对策；
敞开心胸，不断听取客户意见；
让自己信任的人指出自己的盲点。
36.Thetitleofsoftwarearchitecthasonlylower-case'a's；dealwithitbyBarryHawkins
【软件架构师是新兴职业】
软件架构师是一门新兴的职业，可是它具有律师、医生、建筑师一样的精英特质。
大家努力吧！
37.SoftwarearchitecturehasethicalconsequencesbyMichaelNygard
【软件架构也有伦理后果】
说到人权、身份盗用、恶意程序等等，人们知道软件架构可以助人行善，也可以助人作恶。
其实除了大是大非问题，平时很多地方都值得进行伦理思考。
比如说，一个软件好用则千万个用户都省事，一个软件难用则千万个用户都麻烦，他们的轻松愉快或者垂头丧气不就取决于我们架构师吗?
为了他们长久的简便，我们要承担一时的幸苦。
软件影响太多的人了，不要设计违背伦理的软件，哪怕一点点都不要做。
38.EverythingwillultimatelyfailbyMichaelNygard
【万物皆会出错】
硬件会出错，所以用冗余来对付。
软件会出错，所以用监控软件来对付。
可是监控软件也是软件啊，所以错误还是不可避免。
网络是由硬件和软件组成的，所以网络的错误就是难免的了。
怎么办?
我们不能拒绝错误，我们必须接受错误。
承认万物皆会出错，接着设计出适当的失败模式，才能让我们的系统安全地出错。
例如，承认汽车是会撞车的，然后设计可压缩的部件来吸收撞击的能量，起到保护乘客的作用。
在软件系统中，如果不设计失败模式，失败偏偏就会让你措手不及。
39.ContextisKingbyEdwardGarson
【情景为王】
情景为王，简单性是它谦恭的仆人。
所谓情景，指的是业务驱动力、新兴技术和思想潮流。
首先要敞开思路，关注情景中各种各样的因素，给它们排出优先级，然后才能制定出简单的解决方案。
40.It'sallaboutperformancebyCraigLRussell
【处处都要考虑性能】
如果有一种车宽敞、舒适、省钱又环保，就一定卖得好吗?
非也。
一辆牛车即使达到这样的标准也未必有几个人去买。
原因就在于它速度太慢了。
软件设计也是一样，功能重要，性能也一样重要。
性能不单单指系统响应时间，还包括用户操作步数、用户思考时间、用户输入时间等。
性能还包括那些自动执行而不与人互动的部分，比如每日夜间处理任务。
试想一下，如果一个每天夜间执行的任务到了第二天的夜间还没执行完，将会带来难以预料的后果。
41.EngineerinthewhitespacesbyMichaelNygard
【设计空白处】
架构图通常由一些方块表示互相依赖的系统，它们之间用箭头连接，箭头边上写着小小的几个字，剩下的就是大片的空白。
这空白处看似什么都没有，可是在现实中，有网卡、入侵检测系统、防火墙、消息队列服务、数据格式转换服务、通信设备，甚至可能穿越万水千山。
因此，在这个箭头旁，还是要把一些重要问题考虑清楚：
（1）.调用方操作太过频繁怎么办?
忽略、礼貌地拒绝或者竭力满足?
（2）.如果响应超时则调用方怎么办?
重试、等待或视为接收方故障?
（3）.双方收到的数据版本或者格式与期待的不一致时怎么办?
（4）.两方中的任何一方短暂消失会有什么影响?
举个例子，假设有个箭头写的是"HTTP搭载的SOAP-XML"，它可能会有这样的注释：
"期待每个HTTP请求包含一条查询，每个HTTP响应发回一条查询结果。
每秒最多接受100次请求，在99.999%比例下请求响应时间小于250毫秒"。
42.TalktheTalkbyMarkRichards
【入行说行话】
专业人士之间常用行话交流，而架构师最重要的行话就是架构模式。
模式可以按照层次范围划分为四类：
企业架构模式、应用架构模式、集成模式、设计模式。
企业架构模式处理高层架构，设计模式处理组件内部的架构。
常见的企业架构模式有事件驱动架构（EDA）、面向服务架构（SOA）、面向资源架构（ROA）以及管道架构（PA）。
应用架构模式是企业架构内部应用或子系统架构的模式，例如J2EE中的会话面（SessionFa?
ade）、传输对象（TransferObject）模式。
集成模式是在应用、子系统、组件之间共享信息和功能的模式，比如文件共享、远过程调用和各种消息收发模式。
设计模式是最底层的模式，是架构师和开发人员交流的标准词汇。
还要了解反面模式（anti-patterns），也就是那些反复出现、起负作用、需要避免的过程。
常见的反面模式包括分析麻痹（AnalysisParalysis）、委员会设计（DesignByCommittee）、蘑菇房管理（MushroomManagement）、死亡征途（DeathMarch）等。
了解架构模式何以让我们更清楚、简洁、高效地沟通，所谓入行说行话（walkthewalkandtalkthetalk）。
43.HeterogeneityWinsbyEdwardGarson
升级会员 