2018年/12月/05日
架构师97件事
- 客户需求重于个人简历
- 简化根本复杂性，消除偶发复杂性
关键问题可能不是出在技术上
以沟通为中心，坚持简明清晰的表达方式和开明的领导风格
- 架构决定性能
- 分析客户需求背后的意义
- 起立发言
故障终究会发生
我们常常忽略了自己在谈判
量化需求 没有规矩，不成方圆。在记录需求的过程中，对一些模糊的描述比如“灵活”，“可维护 性”，“性能”等通过简单的问题来量化需求，比如“数量多少”，“有多频繁”，“不能超过多长 时间”等。如果缺乏客观的标准，就只能任凭挑剔的用户摆布。
一行代码比五百行架构说明更有价值 可工作的代码才是目标，设计只是达成 目标手段。摩天大楼的建筑师如果一味追求美观 而无视物理定律，迟早会自食其果。
不存在放之四海皆准的解决方案
提前关注性能问题
尽早展开性能测试。尤其是对性能要求苛刻的系统，可以验证架构和设计是否符合实际
性能要求。
架构设计要平衡兼顾多方需求 平衡兼顾项目的技术需求和相关各方的业务需求。
草率提交任务是不负责任的行为(NiclasNilsson) 要设法杜绝开发人员草率提交任务的念头。
不要在一棵树上吊死(KeithBraithwaite) 为客户提供多样化的解决方案。
业务目标至上(DaveMuirhead)
先确保解决方案简单可用，再考虑通用性和复用性(KevlinHenney)
如果存在多个可实施方案难以取舍，“先简单后通用”原则可以成为最终的评判标准。通过 经验提练的简单方案，远胜过不切实际的通用性。
架构师应该亲历亲为(JohnDavies) 身先士卒才能赢得同事的信任。
持续集成(DavidBartlett)
持续集成确保当前的开发不会出现意外，借助它可以取得更稳定、更符合要求的开发成果。
避免进度调整失误(NormanCarnovale)
取舍的艺术(MarkRichards)
架构不可能满足所有需求。鱼和熊掌不可兼得，应牢记瑞典和波兰战 中瑞典瓦萨号 (Vasa)战舰的故事。
打造数据库堡垒(DanChak)
一开始就要定义好数据模型。数据模型的设计必须做到能够拒绝无效数据，阻止无意义的关系。
重视不确定性(KevlinHenney)
推迟决策，建设性地利用不确定性。推迟决定不是故意拖延，而是强调作出的决定应该
基于足够的事实，不能仅凭假定和猜测。
不要轻易放过不起眼的问题(DaveQuick) 别忘了温水煮青蛙的故事。
让大家学会复用(JeremyMeyer) 重复利用已有资源，首先要改变大家的观念。
架构里没有大写的“I”(DaveQuick)
不要让自己变成自大狂。辩解容易，难的是学会停止辩解，恃才傲物容易，难的是拥有
自知之明。
使用“一千英尺高”的视图(ErikDoernenburg) 选择合适的架构视图。不能太抽象，也不能细节太多，看清整个架构。
先尝试后决策(ErikDoernenburg)
越晚做出决策，可利用的信息就越多。可先通过尝试，对问题的最佳解决方案有了共
识，再组织协调制定决策。
掌握业务领域知识(MarkRichards)
掌握业务领域知识有助于架构师选择合适的架构模式，更好地制定针对未来的扩展计
划，适应不断变化的产业趋势。
程序设计是一种设计(EinarLandre)
软件开发也分成设计和生产两个阶段。程序设计属于设计范畴，而不是生产范畴，软件
的生产则是自动化的，由编译器、构建工具和测试代码共同完成。
让开发人员自己做主 ( Philip Nelson )
架构师的工作重点是仔细观察整个系统是怎样组合在一起的，确保系统良好地协调运
作，应该给 团队成员足够的自主权，让他们发挥自己的创意和能力。
时间改变一切(PhilipNelson)
选择值得投入精力的工作，漂亮的解决方案搭配正确的任务，才能经受时间的考验。别
跟以前的工作过不去。回顾过去的工作，永远会觉得以前的设计和自己的期望有差距，
把这些问题当作今后的工作标准，克制自己回过头去修改的冲动。
设立软件架构专业为时尚早(BarryHawkins)
控制项目规模(DaveQuick)
分而治之，将大项目分解成独立的小项目，设置优先级，尽快交付，实现最重要的需求，尽快获得客户的反馈，越快越好。
架构师不是演员，是管家(BarryHawkins)
架构师的职责和管家相似，承担着管理他人资产的责任，架构师应该尽可能为客户利益
着想，计算可用的时间和人力，综合考虑成本和复杂性等因素，设计出折中的解决方
案，不能存有私心，卖弄时髦的软件框架和流行的技术词汇，只会把系统变得更复杂，
给公司造成损失。
软件架构的道德责任(MichaelNygard)
架构师的决定会影响许多人，务必慎重。虽然设计必填项从表面上看并无不妥之处，但
实际上是架构师在强迫用户接受自己的意图。必填项迫使用户准备更多的信息，这个过
程常常会耽搁工作，让人非常沮丧。
摩天大厦不可伸缩(MichaelNygard)
但软件可以。无论是开发新项目还是替换已有的系统，都应该逐个部署系统组件，一来 可以将风险分散到各个时间段，每次砌好“一块砖”，二来迫使我们设计清晰的组件间接 口。
混合开发的时代已经来临(EdwardGarson)
混合编程是指在同一套软件系统中同时采用多种核心编程语言。新的技术变革正逐步瓦
解我们以往积累的技术成果，架构师应拥抱这种变化，跳出原有的思维模式，充分挖掘
软件的多元化特性。
性能至上(CraigRussell) 性能，减少软件响应时间，提高人机交互效率!
留意架构图里的空白区域(MichaelNygard)
空白区域“充满”了各种软件和“硬件”。隐藏着一系列复杂的事件，应该考虑各种隐藏的细 节，才能顺利地解决空白区域里的问题。
学习软件专业的行话(MarkRichards)
架构师必须掌握基本的架构模式和设计模师，学会识别不同的模式，并借助它们和同行 及开发人员进行交流。模式可分类四大类: 企业架构模式定义架构的全局框架结构。 应 用架构模式指出了全局架构下的子系统及局部应用的设计方法。 集成模式研究怎样在系 统的组件、应用和子系统之间传递信息，共享功能。 设计模式研究架构中每个组件的构 造方法。
具体情境决定一切(EdwardGarson) 架构不存在设计理念，具体情境决定一切，根据具体情境设计尽量简单的解决方案。
侏儒、精灵、巫师和国王(EvanCofsky)
开发团队不应该同质化。软件架构师好比国王，应该熟悉各种人的性格特点，招聘不同
性格的人加入自己的团队，为不同性格的团队成员安排合适的任务，轻构化解各种难。
由一帮性格相同的人设计的架构只能吸引同样性格的人加入团队，只能解决一类问题。
向建筑师学习 ( Keith Braithwaite ) 借鉴建筑行业的经验。架构师应该蕴含适当的艺术成分!
避免重复(NiclasNilsson)
两条公认的软件开发的真理:
(1) 复制是魔鬼。
(2) 重复性的工作拖累开发进度。 消灭重复的内容是架构师的责任，为此应该重新研究框架，创造更完善的抽象机制，或 者使用代码生成器。
欢迎来到现实世界(GregorHohpe)
现实世界比软件世界复杂。不要抱怨现实世界中用户需求带来的麻烦，不妨从中寻找解
决问题的灵感。
仔细观察，别试图控制一切(GregorHohpe)
选择合适的抽象层次能提供有效的信息，也方便用基本的验证规则检查模型，架构师应
仔细观察，提取模型，然后检查验证，别妄想掌控一切。
架构师好比两面神(DavidBartlett) 架构师应该像两面神一样，眼观六路、耳听八方。
架构师应关注边界和接口(EinarLandre)
寻找自然的边界，分而治之。架构师应关注和绘制“有界情境”和“情境地图”，有界情境是 用以唯一定义一个模型或概念的区域，通常以一朵云或一个气泡来表示。情境地图则包 含了一系列有界情境及它们之间的接口。
助力开发团队(TimothyHigh) 优秀团队是成功的保障，要尽量助力开发团队。
记录决策理由(TimothyHigh)
记录架构决策背后的理由，长期有用，又无须为之付出过多精力维护，具有极高的投资
回报价值。
挑战假设,尤其是你自己的(TimothyHigh)
臆断是事情搞砸的主要根源。一定要拿出相关的经验证据，仔细验证假设，才能做出最
终决策，务必要确保软件基石坚实可靠。
分享知识和经验(PaulW.Homer)
讨论有助于发现不足，只有能非常容易地做出解释，才表明你真正理解了。只有不断解
释和讨论，才能把经验凝聚成知识。帮助周围的人不断改善，他们也会帮助我们发挥出
全部的潜力。
模式病(ChadLaVigne)
不要让一展设计模式功力的欲望，遮蔽了务实的真知。使用模式解决适用的问题才是最
重要的。
不要滥用架构隐喻(DavidIng) 不要耽溺于系统隐喻之中，只将之用于探索性的沟通，不要反让它拖了后腿。
关注应用程序的支持和维护(MncedisiKasper)
应用程序的支持和维护，永远都不应该是事后才考虑的事情。由于应用程序超过80%的 生命周期都是在维护上，在设计时就应该多多关注支持和维护的问题。考虑生产环境修 误错误的压力，生产环境中的日志记录级别要比开发环境中的低很多，考虑开发人员与 支持人员具有不同的技能等。
有舍才有得 珍惜需要权衡的时机，远胜毫无约束和限制。
原则、公理和类比胜于个人意见和口味(MichaelHarmer)
清楚的架构原则，能够使那些不熟悉某项特别技术或组件的人，明白其中的缘由，更透
地理解他们本不熟悉的技术。
从“可行走骨架”开始开发应用(ClintShank)
数据是核心(PaulW.Homer) 从“数据是核心”这个角度去认识系统，能大大降低理解复杂度 。
确保简单问题有简单的解(ChadLaVigne)
试图猜测未来的需求时，错的概率是50%，错得很离谱的概率是49%。今天只需要解决 今天的问题就好。 把应用发布出去，从反馈中生成真实的需求。
架构师首先是开发人员(MikeBrown)
碰到麻烦时，架构师可不能只会干吹烟圈却束手无策。获得开发人员信任的最快捷方
式:你的代码就是你的资本。作为架构师，主要目标应该是创建可行、可维护的解决方案，当然，也一定要能够解决当前的问题。
根据投资回报率(ROI)进行决策(GeorgeMalamidis)
在判断每个决策选项是否务实或恰当时，将架构决策视为投资，并将相关的回报率也一
并考虑在内。
一切软件系统都是遗留系统(DaveAnderson)
软件很快便会过时，修改维护无可避免。需考虑以下几点: (1) 清晰性:各个组件和 类的角色清晰。 (2) 可测性:系统易于验证。 (3) 正确性:结果和设计或期望的一 致。 (4) 可跟踪:能迅速诊断出故障并立马解决问题。
起码要有两个可选解决方案(TimothyHigh)
软件架构是要在所有给定的约束条件下，寻找到解决问题的最佳方案。期望第一个解决
方案即满足全部的需求和约束，几乎是不可能的。如果对手头的问题只有一个解决方
案，这意味着将没有进行折衷权衡的余地。这个唯一的解决方案可能无法令系统投资方
满意。
理解变化的影响(DougCrawford)
清楚认识变化类型及其影响。变化有多种不同的表现形式:
(1) 功能需求的变化
(2) 可扩展性需求的演进
(3) 系统的接口被修改
(4) 团队人员流动等。
管理变化 并非架构师的职责，但架构师要确保变化是可控的，有许多工具和技术可以用以减轻变 化的影响。
(1) 进行小规模的增量渐变。
(2) 构建可重复运行的测试用例，并经常 运行。
(3) 让测试用例更易编写。
(4) 跟踪好依赖关系。
(5) 系统性的行动，根 据反馈信息作出进一步反应。
(6) 自动化重复的任务。
你不能不了解硬件(KamalWickramanayake)
现在走捷径，将来需付息(ScotMcphee)
及时还清技术债务。可能觉得单元测试并不直接产生价值，于是就让开发人员跳过这些 严格的测试工作，这将导致所交付的系统在未来更难修改，而且在修改时信心不足。 除 了避免在开发初期走捷径，发现有不当的设计决策时就要尽快修正，搁置越久，为之付 出的利息也将越高。
不要追求“完美”，“足够好”就行(GregNyberg)
避免过度设计。不要屈服于企图使设计或实现达到完美的诱惑。把目的设定在“足够好”就 行，当已经达成目标时，就停下来。
小心“好主意”(GregNyberg)
内容为王(ZubinWadia)
内容即网络，即界面。在联系日益紧密的今日世界，内容质量很快成为了成败的关键。
优秀的内容指的是其内容之间互相关联，而不是空洞割裂。系统的成功取决于其内容，
在设计过程中，要对内容价值的评估给 足够重视。
对商业方，架构师要避免愤世嫉俗(ChadLaVigne)
“好主意”就如“骆驼的鼻子”是 一个隐喻，指一旦允许一些不期望但很小的情况发生，后面就会招致巨大而无法避免的情况发生。
过度自信，会让你在业务领域头破血流。不要让自己成为愤世嫉俗的“天才”，总是以一副 自作聪明，居高临下的语调，力求证明公司当前的运营是多么的糟糕不堪，以期触动业 务方。成为优秀架构师的秘诀之中有一个关键要素，那就是要对工作满怀激情，但不要 是那种带着愤怒和火气的“激情”。
拉伸关键维度，发现设计中的不足(StephenJones)
架构师要以自己的编程能力为依托(MikeBrown)
为项目设计架构时，对实现每个设计元素所需的工作量，要做到心中有数;如果以前曾开 发过其中某种设计元素，那么估算所需工作量将会容易得多。
命名要恰如其分(SamGardiner)
弄清楚要做的究竟是什么。设计就是要去实现各种意图，例如，快速、廉价、灵活、而
名字便是用来承载和传达这些意图的。
稳定的问题可以获得高质量的解决方案(SamGardiner)
架构师必须从整体上看待杂乱无章的数据、概念、数据和处理逻辑，架构师要能够将它
们作为整体看待，并将它们分解为更小的片段或块。这些问题块必须是稳定的，只要问
题是稳定的，就可以创建出一个拥有稳定设计的系统。稳定的设计可以让你集中精力，
打造出高质量的应用程序。
天道酬勤(BrianHart)
勤奋体现在很多方面，但归根结底是指具备坚强的毅力，并且对系统的每项任务和每个
架构目标，都能投入足够的精力。真正做好那些看似简单的任务，坚守承诺。很多时候，
不是能力不足导致项目的失败，而是由于勤奋不够，紧迫感不强。
对决策负责(YiZhou)
有效的架构决策包含: (1) 无论是以敏捷的形式还是传统的形式做出架构决策，都必 须对决策过程有充分的认识。 (2) 要定期对架构决策进行复审;对照检查决策的实际效 果和预期效果; (3) 要贯 架构决策，只有全程跟进实施过程，才能够确保最到位地实 现其设计意图。 (4) 并有所谓的全能技术天才，可以将一些决策委托给相应问题域的 专家。 弃聪明，求质朴(EbenHewitt)
别去理会什么流行风潮，只有真正睿智的架构师才懂得如何保持质朴。在质朴的方案中，每个组件只做一件事。
精心选择有效技术，绝不轻易抛弃(ChadLaVigne)
架构师工作很大的一部分，是要选择用以攻克难题的合适技术。精心选择熟悉的武器，
不到万不得已绝不轻易抛弃它们。同时，以审慎的态度更新你的技术武器库。
客户的客户才是你的客户!( Eben Hewitt )
假设你正在编写一个电子商务应用程序，那么该仔细考虑的应当是那些会在那个网站上
购物的人的需求。
事物发展总会出人意料(PeterGillard-Moss)
设计是在不断变化的世界中持续进行探索试验的过程。无论研究得多么深入透 ，无论
设计是如何深思熟虑，事情最后总会变得和你想的不一样，我们会发现通常无法预知的
新信息。
选择 此间能和谐共处的框架(EricHawthorne)
当心“无所不能”型的框架。系统应该由多个相互独立的框架组成，其中每个框架都精专于 各自的领域，但同时又非常简洁、包容和灵活。
着重强调项目的商业价值(YiZhou)
不仅仅只控制代码，也要控制数据(ChadLaVigne)
数据库的变化不应该影响构建活动的连续性。要把数据库也作为一个构建单元包含在内，做到一次性构建整个应用程序。
偿还技术债务(BurkhardtHufnagel)
在速度和架构间进行权衡，保持平衡。“脏但快速”的路线也许适合将修改快速纳入产品 中，但由于“脏但快速”的修复有隐性成本，记得安排开发人员回头去妥善修复解决，纳入 下一个计划发布的版本中。
不要急于求解(EbenHewitt) 不要立即着手去解决摆在面前的问题，而要看看自己是否可以改变问题。
打造上手的系统(KeithBraithwaite)
我们构建的系统，用户体验应该是“上手的”，一定要能够帮助人们做事，这是成功的决定 性因素。
找到并留住富有激情的问题解决者(ChadLaVigne)
以正确的方式有效地经营开发团队。应确保团队具有打不垮的首发阵容，而一旦已经拥 有“常胜铁军”，就要竭力维持。
软件并非真实的存在(ChadLaVigne) 需求文档不是蓝图，软件并非真实的存在，虚拟世界中的软件是柔韧可变的。
学习新语言(BurkhardtHufnagel)
防止沟通不畅和误解 。架构师要能够以业务人员可理解的术语向业务人员解释其中的问 题，以程序员可理解的术语向程序员转述业务上的问题。
没有永不过时的解决方案(RichardMonson-Haefel)
今天做出的选择，在未来很大程度上会是错误的，只要选择能满足当前需求的最佳解决
方案就行了。
用户接受度问题(NormanCarnovale)
清汤的重要启示(EbenHewitt)
软件架构设计需要不断的精炼浓缩。反思各种构想，直至可以确定系统中每个需求的本
质。
对最终用户而言，界面就是系统(VinayakHegde)
最终用户通过用户界面访问系统，用户交互应和产品健壮性和性能同等重要，好的用户
界面能够帮助客户提高生产力，能够帮助人们更加高效，也有利于产品自身的业务收
益。
优秀软件不是构建出来的，而是培育起来的(BilldehÓra)
要抵制试图设计出庞大完整的系统来“满足甚或超出”已知需求的特性期望的想法，要有宏 伟的远景， 但不要有庞大的设计。设计尽可能小的系统，帮助成功交付，并推动它向宏 伟远景目标不断演化。