软件架构师应该知道的97件事

1．客户需求重于我的简历
客户需求至上。为了本身的简历更炫而采用新技术是沽名钓誉，每每事与愿违。

2．  简化根本复杂性 ，消除偶发复杂性
根本复杂性指的是问题与生俱来的、没法避免的困难。偶发复杂性是人们解决根本复杂性的过程当中衍生的。分析问题比如拨云见月、水落石出。架构师的责任在于解决问题的根本复杂性，同时避免引入偶发复杂性。

3．  关键问题可能不是出在技术上
大多数项目是由人完成的，人才是项目成败与否的基础。学会尊重他人，给予团队成员充分的信任，是聪明的架构师得到成功必须掌握的核心技能。团队同心，其利断金。

4．  以沟通为中心，坚持简明清晰的表达方式和开明的领导风格
沟通应当言简意赅、详略得当，别拖泥 带水。

5．  架构决定性能
种瓜得瓜，种豆得豆，架构设计也是一 样道理。它是影响应用性能和可伸缩性的决定因素，性能参数是没法简单地经过更换软件，或者“调优”底层软件架构来改善，必须遵循分布式计算和物理学的基本原理，必须在架构的设计（或从新设计）上投入更多精力。

6．  分析客户需求背后的意义
抽丝剥茧，洞见症结。不要被表面需求 迷惑。

7．  起立发言
让沟通事半功倍，起立发言是最简单、有效的方法。

8．  故障终究会发生
系统必然存在不一样形式的故障隐患，不管如何都没法完全消灭，应该提早设计预防措施，限制故障。

9．  咱们经常忽略了本身在谈判
工程师应该适时转换角色，学习谈判的 技巧。毫不能在与对方谈判的第一个要求上就妥协让步。

10． 量化需求
没有规矩，不成方圆。在记录需求的过程当中，对一些模糊的描述好比“灵活”，“可维护性”，“性能”等经过简单的问题来量化需求，好比“数量多少”，“有多频繁”，“不能超过多长时间”等。若是缺少客观的标准，就只能任凭挑剔的用户摆布。

11． 一行代码比五百行架构说明更有价值
可工做的代码才是目标，设计只是达成 目标手段。摩天大楼的建筑师若是一味追求美观而无视物理定律，早晚会自作自受。

12． 不存在放之四海皆准的解决方案
软件世界没有放之四海皆准的解决方案。架构师必须培养和训练情境意识，才能更好地设计架构和解决问题。

13． 提早关注性能问题
尽早展开性能测试。尤为是对性能要求苛刻的系统，能够验证架构和设计是否符合实际性能要求。

14． 架构设计要平衡兼顾多方需求
平衡兼顾项目的技术需求和相关各方的业务需求。

15． 草率提交任务是不负责任的行为   （ Niclas Nilsson ）
要设法杜绝开发人员草率提交任务的念头。

16． 不要在一棵树上吊死   （ Keith Braithwaite ）
为客户提供多样化的解决方案。

17． 业务目标至上 （ Dave Muirhead ）
技术决策不能脱离业务目标和现实条件的约束。

18． 先确保解决方案简单可用，再考虑通用性和复用性   （ Kevlin Henney ）
 若是存在多个可实施方案难以取舍，“先简单后通用”原则能够成为最终的评判标准。经过经验提练的简单方案，远赛过不切实际的通用性。

19． 架构师应该亲历亲为 （ John Davies ）
一马当先才能赢得同事的信任。

20． 持续集成 （ David Bartlett ）
持续集成确保当前的开发不会出现意外，借助它能够取得更稳定、更符合要求的开发成果。

21． 避免进度调整失误 （ Norman Carnovale ）
不惜一切代价拒绝调整项目进度的要求。为提升交付速度而改变计划会带来一系列的问题。

22． 取舍的艺术 （ Mark Richards ）
架构不可能知足全部需求。鱼和熊掌不可兼得，应牢记瑞典和波兰战争中瑞典瓦萨号（Vasa）战舰的故事。

23． 打造数据库堡垒 （ Dan Chak ）
一开始就要定义好数据模型。数据模型的设计必须作到可以拒绝无效数据，阻止无心义的关系。

24． 重视不肯定性 （ Kevlin Henney ）
推迟决策，建设性地利用不肯定性。推迟决定不是故意拖延，而是强调做出的决定应该基于足够的事实，不能仅凭假定和猜想。

25． 不要轻易放过不起眼的问题 （ Dave Quick ）
别忘了温水煮青蛙的故事。

26． 让你们学会复用 （ Jeremy Meyer ）
重复利用已有资源，首先要改变你们的观念。

27． 架构里没有大写的“I ” （ Dave Quick ）
不要让本身变成自大狂。辩解容易，难的是学会中止辩解，恃才傲物容易，难的是拥有自知之明。

28． 使用“ 一千英尺高” 的视图 （ Erik Doernenburg ）
选择合适的架构视图。不能太抽象，也不能细节太多，看清整个架构。

29． 先尝试后决策 （ Erik Doernenburg ）
越晚作出决策，可利用的信息就越多。可先经过尝试，对问题的最佳解决方案有了共识，再组织协调制定决策。

30． 掌握业务领域知识 （ Mark Richards ）
掌握业务领域知识有助于架构师选择合适的架构模式，更好地制定针对将来的扩展计划，适应不断变化的产业趋势。

31． 程序设计是一种设计 （ Einar Landre ）
软件开发也分红设计和生产两个阶段。程序设计属于设计范畴，而不是生产范畴，软件的生产则是自动化的，由编译器、构建工具和测试代码共同完成。

32． 让开发人员本身作主 （ Philip Nelson ）
架构师的工做重点是仔细观察整个系统是怎样组合在一块儿的，确保系统良好地协调运做，应该给予团队成员足够的自主权，让他们发挥本身的创意和能力。

33． 时间改变一切 （ Philip Nelson ）
选择值得投入精力的工做，漂亮的解决方案搭配正确的任务，才能经受时间的考验。别跟之前的工做过不去。回顾过去的工做，永远会以为之前的设计和本身的指望有差距，把这些问题看成从此的工做标准，克制本身回过头去修改的冲动。

34． 设立软件架构专业为时尚早 （ Barry Hawkins ）

 这个本身分析吧！

35． 控制项目规模 （ Dave Quick ）
分而治之，将大项目分解成独立的小项目，设置优先级，尽快交付，实现最重要的需求，尽快得到客户的反馈，越快越好。

36． 架构师不是演员，是管家 （ Barry Hawkins ）
架构师的职责和管家类似，承担着管理他人资产的责任，架构师应该尽量为客户利益着想，计算可用的时间和人力，综合考虑成本和复杂性等因素，设计出折中的解决方案，不能存有私心，卖弄时髦的软件框架和流行的技术词汇，只会把系统变得更复杂，给公司形成损失。

37． 软件架构的道德责任 （ Michael Nygard ）
架构师的决定会影响许多人，务必慎重。虽然设计必填项从表面上看并没有不妥之处，但其实是架构师在强迫用户接受本身的意图。必填项迫使用户准备更多的信息，这个过程经常会耽搁工做，让人很是沮丧。

38． 摩天大厦不可伸缩 （ Michael Nygard ）
但软件能够。不管是开发新项目仍是替换已有的系统，都应该逐个部署系统组件，一来能够将风险分散到各个时间段，每次砌好“一块砖”，二来迫使咱们设计清晰的组件间接口。

39． 混合开发的时代已经来临 （ Edward Garson ）
混合编程是指在同一套软件系统中同时采用多种核心编程语言。新的技术变革正逐步瓦解咱们以往积累的技术成果，架构师应拥抱这种变化，跳出原有的思惟模式，充分挖掘软件的多元化特性。

40． 性能至上 （Craig Russell ）

性能，减小软件响应时间，提升人机交互效率！
41． 留意架构图里的空白区域 （ Michael Nygard ）
空白区域“充满”了各类软件和“硬件”。隐藏着一系列复杂的事件，应该考虑各类隐藏的细节，才能顺利地解决空白区域里的问题。

42． 学习软件专业的行话 （ Mark Richards ）
架构师必须掌握基本的架构模式和设计模师，学会识别不一样的模式，并借助它们和同行及开发人员进行交流。模式可分类四大类：
企业架构模式定义架构的全局框架结构。
应用架构模式指出了全局架构下的子系统及局部应用的设计方法。
集成模式研究怎样在系统的组件、应用和子系统之间传递信息，共享功能。
设计模式研究架构中每一个组件的构造方法。

43． 具体情境决定一切 （ Edward Garson ）
 架构不存在设计理念，具体情境决定一切，根据具体情境设计尽可能简单的解决方案。

44． 侏儒、精灵、巫师和国王 （ Evan Cofsky ）
开发团队不该该同质化。软件架构师比如国王，应该熟悉各类人的性格特色，招聘不一样性格的人加入本身的团队，为不一样性格的团队成员安排合适的任务，轻构化解各类难。由一帮性格相同的人设计的架构只能吸引一样性格的人加入团队，只能解决一类问题。

45． 向建筑师学习 （ Keith Braithwaite ）
借鉴建筑行业的经验。架构师应该蕴含适当的艺术成分！

46． 避免重复 （ Niclas Nilsson ）
两条公认的软件开发的真理：
（1） 复制是魔鬼。
（2） 重复性的工做拖累开发进度。
消灭重复的内容是架构师的责任，为此应该从新研究框架，创造更完善的抽象机制，或者使用代码生成器。

47． 欢迎来到现实世界 （ Gregor Hohpe ）
现实世界比软件世界复杂。不要抱怨现实世界中用户需求带来的麻烦，不妨从中寻找解决问题的灵感。

48． 仔细观察，别试图控制一切 （ Gregor Hohpe ）
选择合适的抽象层次能提供有效的信息，也方便用基本的验证规则检查模型，架构师应仔细观察，提取模型，而后检查验证，别妄想掌控一切。

49． 架构师比如两面神 （ David Bartlett ）
架构师应该像两面神同样，眼观六路、耳听八方。

50． 架构师应关注边界和接口  （ Einar Landre ）
寻找天然的边界，分而治之。架构师应关注和绘制“有界情境”和“情境地图”，有界情境是用以惟必定义一个模型或概念的区域，一般以一朵云或一个气泡来表示。情境地图则包含了一系列有界情境及它们之间的接口。

51． 助力开发团队 （ Timothy High ）
优秀团队是成功的保障，要尽可能助力开发团队。

52． 记录决策理由 （ Timothy High ）
记录架构决策背后的理由，长期有用，又无须为之付出过多精力维护，具备极高的投资回报价值。

53． 挑战假设, 尤为是你本身的 （ Timothy High   ）
臆断是事情搞砸的主要根源。必定要拿出相关的经验证据，仔细验证假设，才能作出最终决策，务必要确保软件基石坚实可靠。

54． 分享知识和经验 （ Paul W. Homer ）
讨论有助于发现不足，只有能很是容易地作出解释，才代表你真正理解了。只有不断解释和讨论，才能把经验凝聚成知识。帮助周围的人不断改善，他们也会帮助咱们发挥出所有的潜力。

55． 模式病 （ Chad La Vigne ）
不要让一展设计模式功力的欲望，遮蔽了务实的真知。使用模式解决适用的问题才是最重要的。

56． 不要滥用架构隐喻 （ David Ing ）
不要耽溺于系统隐喻之中，只将之用于探索性的沟通，不要反让它拖了后腿。

57． 关注应用程序的支持和维护 （ Mncedisi Kasper ）
应用程序的支持和维护，永远都不该该是过后才考虑的事情。因为应用程序超过80%的生命周期都是在维护上，在设计时就应该多多关注支持和维护的问题。考虑生产环境修误错误的压力，生产环境中的日志记录级别要比开发环境中的低不少，考虑开发人员与支持人员具备不一样的技能等。

58． 有舍才有得
珍惜须要权衡的时机，远胜毫无约束和限制。

59． 原则、公理和类比胜于我的意见和口味 （ Michael Harmer ）
清楚的架构原则，可以使那些不熟悉某项特别技术或组件的人，明白其中的原因，更透彻地理解他们本不熟悉的技术。

60． 从“ 可行走骨架” 开始开发应用 （ Clint Shank ）
“可行走骨架”是对系统的最简单实现，它贯穿头尾，将全部主要的架构组件链接起来。从“ 可行走骨架” 开始，增量培育系统成长 。

61． 数据是核心（ Paul W. Homer ）
从“数据是核心”这个角度去认识系统，能大大下降理解复杂度 。

62． 确保简单问题有简单的解 （Chad La Vigne ）
    试图猜想将来的需求时，错的几率是50%，错得很离谱的几率是49%。今天只须要解决今天的问题就好。
    把应用发布出去，从反馈中生成真实的需求。

63． 架构师首先是开发人员 （Mike Brown ）
碰到麻烦时，架构师可不能只会干吹烟圈却一筹莫展。得到开发人员信任的最快捷方式：你的代码就是你的资本。做为架构师，主要目标应该是建立可行、可维护的解决方案，固然，也必定要可以解决当前的问题。

64． 根据投资回报率（ROI ）进行决策（ George Malamidis ）
  在判断每一个决策选项是否务实或恰当时，将架构决策视为投资，并将相关的回报率也一并考虑在内。

65． 一切软件系统都是遗留系统（ Dave Anderson ）
软件很快便会过期，修改维护无可避免。需考虑如下几点：
（1） 清晰性：各个组件和类的角色清晰。
（2） 可测性：系统易于验证。
（3） 正确性：结果和设计或指望的一致。
（4） 可跟踪：能迅速诊断出故障并立马解决问题。

66． 起码要有两个可选解决方案（ Timothy High ）
 软件架构是要在全部给定的约束条件下，寻找到解决问题的最佳方案。指望第一个解决方案即知足所有的需求和约束，几乎是不可能的。若是对手头的问题只有一个解决方案，这意味着将没有进行折衷权衡的余地。这个惟一的解决方案可能没法令系统投资方满意。

67． 理解变化的影响 （ Doug Crawford ）
清楚认识变化类型及其影响。变化有多种不一样的表现形式：
（1） 功能需求的变化
（2） 可扩展性需求的演进
（3） 系统的接口被修改
（4） 团队人员流动等。
管理变化并不是架构师的职责，但架构师要确保变化是可控的，有许多工具和技术能够用以减轻变化的影响。
（1） 进行小规模的增量渐变。
（2） 构建可重复运行的测试用例，并常常运行。
（3） 让测试用例更易编写。
（4） 跟踪好依赖关系。
（5） 系统性的行动，根据反馈信息做出进一步反应。
（6） 自动化重复的任务。

68． 你不能不了解硬件（ Kamal Wickramanayake ）
硬件容量规划，是和软件架构同等重要的事情。水平伸缩能力是关键，能够在须要时才添加硬件，而无须一开始就过量采购。

69． 如今走捷径，未来需付息（ Scot Mcphee ）
及时还清技术债务。可能以为单元测试并不直接产生价值，因而就让开发人员跳过这些严格的测试工做，这将致使所交付的系统在将来更难修改，并且在修改时信心不足。 除了避免在开发初期走捷径，发现有不当的设计决策时就要尽快修正，搁置越久，为之付出的利息也将越高。

70． 不要追求“完美”，“足够好”就行（ Greg Nyberg ）
避免过分设计。不要屈服于企图使设计或实现达到完美的诱惑。把目的设定在“足够好”就行，当已经达成目标时，就停下来。

71． 当心“好主意” （ Greg Nyberg ）
 “骆驼的鼻子”是 一个隐喻，指一旦容许一些不指望但很小的状况发生，后面就会招致巨大而没法避免的状况发生。“好主意”就如“骆驼的鼻子”，它将致使范围膨胀，复杂度上升，竭力把和业务需求无关的东西塞入应用中，这纯粹是浪费精力。

72． 内容为王 （ Zubin Wadia ）
内容即网络，即界面。在联系日益紧密的今日世界，内容质量很快成为了成败的关键。优秀的内容指的是其内容之间互相关联，而不是空洞割裂。系统的成功取决于其内容，在设计过程当中，要对内容价值的评估给予足够重视。

73． 对商业方，架构师要避免愤世嫉俗（ Chad La Vigne ）
过分自信，会让你在业务领域头破血流。不要让本身成为愤世嫉俗的“天才”，老是以一副自做聪明，居高临下的语调，力求证实公司当前的运营是多么的糟糕不堪，以期触动业务方。成为优秀架构师的秘诀之中有一个关键要素，那就是要对工做满怀激情，但不要是那种带着愤怒和火气的“激情”。

74． 拉伸关键维度，发现设计中的不足（ Stephen Jones ）
单独拉伸每一个维度，而后综合起来看待，即可暴露出那些隐藏于最初设计中的潜在限制与不足。架构师能够经过
拉伸关键维度，对解决方案进行校核：
（1） 了解基础设施的规划是否可以应付增加的需求，圈出限制范围。
（2） 确认在预期的吞吐量下，系统不但能在当天内及时完成全天的任务处理，同时具有峰值储备，才能应
对“特别忙碌的日子”，才能在停电后“加班补上”.
（3） 对当前的数据访问方案进行校核，确保其在系统伸缩扩展时依然有效。
（4） 确保在系统工做负载上升时，（若是须要）可以以增长硬件和转换处理路径的方式进行系统的伸缩扩展。
（5） 数据量持续上升，致使数据必须在更多的基础设施间进行分割时，要确保应用程序仍然可用。

75． 架构师要以本身的编程能力为依托（ Mike Brown ）
 为项目设计架构时，对实现每一个设计元素所需的工做量，要作到心中有数;若是之前曾开发过其中某种设计元素，那么估算所需工做量将会容易得多。

76． 命名要恰如其分（ Sam Gardiner ）
弄清楚要作的到底是什么。设计就是要去实现各类意图，例如，快速、廉价、灵活、而名字即是用来承载和传达这些意图的。

77． 稳定的问题能够得到高质量的解决方案（ Sam Gardiner ）
架构师必须从总体上看待杂乱无章的数据、概念、数据和处理逻辑，架构师要可以将它们做为总体看待，并将它们分解为更小的片断或块。这些问题块必须是稳定的，只要问题是稳定的，就能够建立出一个拥有稳定设计的系统。稳定的设计可让你集中精力，打造出高质量的应用程序。

78． 天道酬勤（ Brian Hart ）
勤奋体如今不少方面，但归根结底是指具有坚强的毅力，而且对系统的每项任务和每一个架构目标，都能投入足够的精力。真正作好那些看似简单的任务，坚守承诺。不少时候，不是能力不足致使项目的失败，而是因为勤奋不够，紧迫感不强。

79． 对决策负责（ Yi Zhou ）
有效的架构决策包含：
（1） 不管是以敏捷的形式仍是传统的形式作出架构决策，都必须对决策过程有充分的认识。
（2） 要按期对架构决策进行复审;对照检查决策的实际效果和预期效果;
（3） 要贯彻架构决策，只有全程跟进实施过程，才可以确保最到位地实现其设计意图。
（4） 并有所谓的全能技术天才，能够将一些决策委托给相应问题域的专家。

80． 弃聪明，求质朴（ Eben Hewitt ）
别去理会什么流行风潮，只有真正睿智的架构师才懂得如何保持质朴。在质朴的方案中，每一个组件只作一件事。

81． 精心选择有效技术，毫不轻易抛弃（ Chad La Vigne ）
架构师工做很大的一部分，是要选择用以攻克难题的合适技术。精心选择熟悉的武器，不到万不得已毫不轻易抛弃它们。同时，以审慎的态度更新你的技术武器库。

82． 客户的客户才是你的客户！（ Eben Hewitt ）
 假设你正在编写一个电子商务应用程序，那么该仔细考虑的应当是那些会在那个网站上购物的人的需求。

83． 事物发展总会出人意料 （ Peter Gillard-Moss ）
设计是在不断变化的世界中持续进行探索试验的过程。不管研究得多么深刻透彻，不管设计是如何深思熟虑，事情最后总会变得和你想的不同，咱们会发现一般没法预知的新信息。

84． 选择彼此间能和谐共处的框架 （ Eric Hawthorne ）
小心“无所不能”型的框架。系统应该由多个相互独立的框架组成，其中每一个框架都精专于各自的领域，但同时又很是简洁、包容和灵活。

85． 着重强调项目的商业价值（ Yi Zhou ）
可经过下面五步，成功将架构提案打造为典型的商业项目：
（1） 造成价值陈述，用以说明组织的业务为什么要采用某种特定的软件架构，重点应放在说明其在提升生产力、改进业务效率方面的能力。
（2） 创建量化的度量标准，量化得越具体越到位，项目也将越具备说服力。
（3） 回过头来关联传统商业的衡量方式，若是能将技术分析转化为财务数据，则会更为完美。
（4） 知道该在哪里中止。准备好一张路线图，用以捕获远景目标，清楚地知道每个里程碑将带来的商业价值。让利益相关者本身决定在何处中止。
（5） 寻找恰当的时机，若是时机不对，可能仍然没法成功推销你的点子。

86． 不只仅只控制代码，也要控制数据 （ Chad La Vigne ）
数据库的变化不该该影响构建活动的连续性。要把数据库也做为一个构建单元包含在内，作到一次性构建整个应用程序。

87． 偿还技术债务 （ Burkhardt Hufnagel ）
在速度和架构间进行权衡，保持平衡。“脏但快速”的路线也许适合将修改快速归入产品中，但因为“脏但快速”的修复有隐性成本，记得安排开发人员回头去妥善修复解决，归入下一个计划发布的版本中。

88． 不要急于求解（ Eben Hewitt ）
不要当即着手去解决摆在面前的问题，而要看看本身是否能够改变问题。

89． 打造上手的系统（ Keith Braithwaite ）
咱们构建的系统，用户体验应该是“上手的”，必定要可以帮助人们作事，这是成功的决定性因素。

90． 找到并留住富有激情的问题解决者 （ Chad La Vigne ）
以正确的方式有效地经营开发团队。应确保团队具备打不垮的首发阵容，而一旦已经拥有“常胜铁军”，就要竭力维持。

91． 软件并不是真实的存在 （ Chad La Vigne ）
需求文档不是蓝图，软件并不是真实的存在，虚拟世界中的软件是柔韧可变的。

92． 学习新语言 （ Burkhardt Hufnagel ）
防止沟通不顺畅和误解 。架构师要可以以业务人员可理解的术语向业务人员解释其中的问题，以程序员可理解的术语向程序员转述业务上的问题。

93． 没有永不过期的解决方案（ Richard Monson-Haefel ）
 今天作出的选择，在将来很大程度上会是错误的，只要选择能知足当前需求的最佳解决方案就好了。

94． 用户接受度问题（ Norman Carnovale ）
减轻用户接受度问题带来的风险。人们并不老是满心欢喜地接受新系统或系统的重大升级，架构师的目标，是要去了解和衡量接受度问题带来的威胁，并朝能减轻这些威胁的方向开展工做。最有效的解决办法，是运用系统设计自己来消解个中忧虑，包括培训、按期安排系统的演示，并分享用户重新系统中将会得到的知识。

95． 清汤的重要启示 （ Eben Hewitt ）
软件架构设计须要不断的精炼浓缩。反思各类构想，直至能够肯定系统中每一个需求的本质。

96． 对最终用户而言，界面就是系统 （ Vinayak Hegde ）
最终用户经过用户界面访问系统，用户交互应和产品健壮性和性能同等重要，好的用户界面可以帮助客户提升生产力，可以帮助人们更加高效，也有利于产品自身的业务收益。

97． 优秀软件不是构建出来的，而是培育起来的（ Bill de hÓra ）
要抵制试图设计出庞大完整的系统来“知足甚或超出”已知需求的特性指望的想法，要有宏伟的远景，
但不要有庞大的设计。设计尽量小的系统，帮助成功交付，并推进它向宏伟远景目标不断演化。
---------------------
做者：简单极致_李
来源：CSDN
原文：https://blog.csdn.net/lixiaopeng23/article/details/9997531
版权声明：本文为博主原创文章，转载请附上博文连接！