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

1.积累一批满意的客户，选择切合实际的技术解决他们的难题，让他们乐于推荐你，才是最好的履历。信誉远胜过时髦的编程技巧和流行的范式。掌握最新的技术趋势，与时俱进固然重要，但不能让客户为此买单。
2.把客户的长远需求摆在自己的短期利益之上，才能立于不败之地。
3.应该尽量选择源自实际项目的框架，警惕那些象牙塔里的产品，分析方案中有多少代码直接用来解决业务问题，有多少只是用来实现用户与应用之间的交互；谨慎使用软件厂商在幕后推动的方案，它们并非一无是处，但往往包含偶发复杂性；要量体裁衣，为问题制订“合身”的解决方案。架构师的责任在于解决问题的根本复杂性，同时避免引入偶发复杂性。
4.大多数项目是由人完成的，人才是项目成败与否的基础。
5.学会尊重他人，给予团队成员充分的信任，是聪明的架构师获得成功必须掌握的核心技能。
6.关于对话的技巧：
a)不要把对话当成对抗：如果能看到他人的优点，并把沟通视为请教问题的机会，就会有所收获，同时也能避免引起对方的戒备之心。
b)不要带着情绪与人沟通。
c)尝试通过沟通设定共同的目标。
7.以沟通为中心，坚持简明清晰的表达方式和开明的领导风格。
8.让开发人员参与架构的制订过程，他们才会买你的账。
9.架构才是影响应用性能和可伸缩性的决定因素。
10.架构师可以通过询问客户，分析客户要求的功能和需求的真正意义，定位真正的问题，从而提出比客户的建议更好、成本更低的解决方案。通过关注问题的真正含义，理顺需求的轻重缓急：把最有价值的需求摆在第一位。
11.架构师应该通过与客户而对面的交流，关注客户的需求，引导客户回答为什么的问题。
12.重视推销自己的想法。
13.让沟通事半功倍，起立发言是最简单、有效的方法！
14.应当承认系统中必然存在着不同形式的故障隐患，无论如何都无法彻底消灭。事先针对故障设计好防范模型，才能应对威胁系统安全的意外情况。
15.工程师总是想尽办法寻求合作，谈判者则绞尽脑汁占得先机。谈判时，绝不能在对方的第一个要求上妥协让步。
16.使一切需求量化，没有量化的需求会导致用户验收系统时缺乏依据，架构师不知所措，开发工作失去正确的指导。例如再有人对系统提出“可伸缩”的要求，一定要问题清楚新用户从何而来，为什么数量会增加，心脏何时增加，会增加多少。拒绝“很多”、“马上”这类模棱两可的答案。
17.架构师应该与团队成员合作，共同作出决策，修改设计以符合实际情况。没有天生完美的设计，所有的设计都要在实现的过程中逐步完善。
18.沉下心来改善系统的生产效率，缩短流程，避免各行其是，才能缩短开发时间。
19.每当要权衡取舍时，都应该把高投资回报率当作目标。
20.尽量提供足够的高质量信息，持续反馈开发中的成果，用于支持业务决策。关键在于加大透明度。架构师必须与开发团队合作，设法建立反馈回路，持续有规律地向业务部门提供信息。
21.要在项目开始后尽早地、频繁地发布可工作的软件。
22.用业务目标驱动项目开发，才能保证软件开发团队的长远利益。
23.先确保解决方案简单可用，再考虑通用性和复用性。
24.架构师应该尽早参与项目，与团队成员并肩工作，而不是坐在象牙塔里发号施令。
25.优秀的架构师之间都保持着紧密的联系。
26.应该在项目中鼓励推广持续集成的方法和工具。
27.要建立牢固的数据模型，必须隔离来自应用层的bug；必须严格遵守引用完整性；尽可能使用域约束规则；还要选择恰当的键，即保证引用完整性，又遵守约束规则。要实现可扩展性，就必须正确地将数据标准化，以便在今后的数据模型上添加架构层；千万不要偷懒走捷径。
28.精益软件开发的原则之一：推迟决定，它不是指故意拖延，而是强调作出的决定应该基于足够的事实，不能仅凭假定和猜测。
29.与客户密切合作，确保双方理解每项需求的业务价值。驱动架构的是需求，不是架构师，你的任务是竭尽所能满足需求。
30.重要团队合作。架构属性于团队，不是架构师一个人的。
31.检查你的工作，和团队一起测试，检查架构对每项需求的支持情况。
32.自我反省。
33.敏捷软件开发工具---精益软件开发方法
34.高水平的架构师不仅要懂技术，还要掌握问题空间对应的业务领域知识。缺乏业务领域知识的架构师不能顺利地解决业务问题，无法才业务需求，也就难以设计有效的架构来满足需求。
35.成功的架构师能够自如地运用企业高管和用户熟悉的行业术语与他们沟通。
36.掌握业务领域知识有助于软件架构师更好地理解要解决的难题、有争议的问题、业务目标，以及数据和流程。
37.以文档驱动的、照着说明依样画葫芦的方法是引发许多软件问题的罪魁祸首。
38.在软件工程里，与传统行业的设计文档具有相同地位的只有源代码。软件的生产则是自动化的，由编译器、构建工具和测试代码共同完成。
39.应该给予团队成员足够的自主权，让他们发挥自己的创意和能力。
40.作为架构师，观察整个系统是怎样组合在一起的，是工作重点。开发人员忙于编写类、方法、测试代码，使用接口和数据库，架构师则要确保所有这些东西良好地协调动作。要善于倾听各种抱怨并设法加以改进。
41.别再自以为是，用时间的放大镜仔细研究简单原则的真正涵义。
42.怎么控制项目的规模（范围）：
a.抓住真正的需求。如果一项需求不能为公司带来收益，就应该放弃。
b.分而治之。比起由相互依赖的子系统组成的大项目，几个相互独立的小项目更容易管理。
c.设置优先级。虽然有些需求会随业务变化甚至取消，但是关键需求通常会维持不变。理清需求的优先级，优先实现最关键的需求。
d.尽快交付。看到演示产品之前，多数客户都不知道自己想要什么。首先实现最重要的需求，尽快获得客户的反馈，越快越好。
e.《解析极限编程--拥抱变化》
43.尽早部署独立的组件既可以增加商业利润，又可以改善架构品质。
44.《企业应用架构模式》
45.具体情况具体分析，努力找出最简单的解决方案。
46.架构师安排任务时，应该时刻考虑所有开发人员的性格特点。从这个角度来看，架构是一个指南，为不同性格的团队成员安排合适的任务，让大家在工作过程中相互学习。
47.复制是魔鬼。重复性的工作拖累开发进度。
48.架构师一定要警惕示例可能会产生的影响。这些代码和配置将成为成百上千个系统切片的模板，应该做到简洁、意图明确，只包含无法抽取掉的、与领域问题相关的内容。架构师应该对那些可能重复的内容保持高度警惕，因为你的每行代码都会被复制。
49.消灭重复的内容是你的责任，为此，应该重新研究框架，创造更完善的抽象机制，请专门制作工具的程序员帮你完成切面框架或者使用代码生成器。
50.分布式系统不但是松耦合、异步、并发的，而且不遵守传统的事务主义，这些都是程序员的噩梦。
51.用异步的、并发的请求代替一个接一个的方法调用。设计应用时，借助事件驱动的过程链模型或状态模型控制无序的状况，通过调整、重发，甚至试探的办法纠正错误。
52.《企业集成模式：设计、构建及部署消息传递解决方案》
53.灵活性是分布式系统的重要指标。
54.只要不违背软件设计的总体目标，就让开发人员自己做出决策。但是，不仅为了质量，也为了能够对开发人员进行深度授权，我们要在总数上设置限制。为了一致性，也为了减少麻烦和无关紧要的决定，我们要创建一些标准。创建一个清晰的路线图，向开发保山说明应当如何放置源代码文件，如何对之命名，何时应当创建新文件等诸如此类的问题。这可以节省他们的时间。
55.定义软件架构，就是要在质量属性、成本、时间以及其它各种因素之间，做出正确的权衡。此份文档应能向你自己、经理人员、开发人员及软件的其它利益相关者，清楚阐明选择某种解决方案，而非另外一种的原因，包括其中做出的权衡。这种实践可获得的最重要好种是：它逼着你明确说出理由，有助于确保基础是扎实稳固的；如果相关条件发生变化，需要对决策重新评估它可以作为一个起点。
56.臆断是事情搞砸的根源。
57.事实和假设是构建软件的两在支柱。务必确保软件的基石坚实可靠。
58.设计模式是对觉问题的可征用解决方案。当这些方案能够解决的问题出现时，我们能够识别出来，当地 应用设计模式，这才是我们的任务。不要让一展设计模式功力的欲望，遮蔽了务实的真知。应该保持对系统的洞察力，提供切实有效的商业解决方案，使用模式解决适用的问题才是最重要的。
59.由于应用程序超过80%的生命周期都是在维护上，在设计时就应该多多关注支持和维护的问题。忽略这一点，你将惊恐万分地注视着寄予厚望的应用程序停止工作，成为你架构师生涯中无法抹去的败绩。
60.可追溯性、审计和日志记录至关重要。
61.先考虑原则、公理和类比，再考虑个人意见和口味
62.数据是每个系统的核心。
63.试图鱼油未来的需求时，错的概率是50%，错得很离谱的概率是49%。今天只需要解决今天的问题就好。
64.让开发人员信任的最快捷的办法，是获得他们的尊重和信任。我们都知道获得开发人员信任的最快捷方式：你的代码就是你的资本。
65.投资回报率（Return On Investment,ROI），是衡量投资是否成功的指标之一。将架构决策视为投资，并将相关的回报率也一并考虑在内。在判断每个决策选项是否务实或恰当时，这种方法很有用。
66.管理变化并非架构师的职责，但架构师要变化是可控的。有许多工具和技术可以用以减轻变化的影响：
a.进行小规模的增量渐变
b.构建可重复运行的测试用例，并经常运行
c.让测试用例更易编写
d.跟踪好依赖关系
e.系统性的行动，根据反馈信息作出进一步的反应。
f.自动化重复工作
67.硬件容量规划是和软件架构同等重要的事情，不管身边是否有基础设施架构师，都要将之安排在第一优先级。架构师既要负责连接业务需求和软件解决方案，也要负责连接硬件和软件。
68.现在走捷径，将来付利息。设计不当的特征可能会成为后续特征的基础，将来需要花很高的成本来更正。
69.碰到架构问题或设计缺陷，作为架构师，一定要坚持成本还很低廉时就动手。搁置越久，为之付出的利息也将越高。
70.应用程序开发不是选美大赛，停止吹毛求疵的做法，不要再浪费时间追求尽善尽美。
71.系统的成功取决于其内容。优秀内容成就优秀系统，内容为王。
72.要找到能和业务方建立良好关系的方法，不要让自我破坏这种关系。
73.如果无法给出合适的命名，那也就无法继续编程。如果发现自己需要多次更改命名，那么最好停下来，直到弄清楚要做的空间是什么。
74.架构师要能够将四处弥漫的软件问题圈起来，并画出其中的各种边界，确保对问题有稳定的、完整的认识。
75.架构师必须能从整体上看待杂乱无章的数据、概念、数据和处理逻辑，架构师要能够将它们作为整体看待，并将它们分解为更小的片段或块。重点在于，这些问题块必须是稳定的，它们在范围上有限且稳定，可以作为系统模块解决。这些问题块应该具备以下特性：
a.内聚性：问题块在概念上是统一的，其中所有的任务、数据和特征都是相关的。
b.能够很好地和其他块做好事开：这些块在概念上进行了规范化处理；它们很少重叠或根本就不重叠。
如果问题是稳定的，那么，问题解决之后，就永远不会再来烦恼你。只要问题是稳定的，你就可以创建出一个拥有稳定设计的系统。稳定的设计可以让你集中精力，打造出高质量的应用程序。
76.很多时候，不是能力不足导致项目的失败，而是由于勤奋不够，紧迫感不强。
77.对自己的决策负责。如何才能成为负责任的架构师，做出有效的架构决策呢？
首先，必须对决策过程有充分的认识，只有满足以下两个条件，才算已经完成架构决策：
a.该决策已经以书面的形式记录下来；由于架构决策很少是无关紧要的小事。它们必须经过校核证实，并可被追溯
b.必须已和执行该决策及会直接或间接受其影响的人进行过沟通，达成共识
其次，要定期对架构决策进行复审，对照检查决策的实际效果和预期结果，识别出哪些有效，哪些无效。
第三，要贯彻架构决策。
最后，可以将一些决策委托给相应问题哉的专家。
78.聪明的软件价格昂贵，不易维护，僵脆易折。所以不要追求聪明，尽量用最浅显易懂的质朴方法，恰如其分地进行设计。
79.《Java SOA Cookbook》
80.精心选择有效技术，绝不轻易抛弃
81.客户的客户，才是你真正的客户
82.设计是一个不断发现的过程。在实现时，我们会发现通常无法预知的新信息。设计是在不断变化的世界中持续进行探索试验的过程，只有接受这些，我们才能明白，设计过程也必须保持灵活性和连续性。事务发展总会出人意料。
83.系统应该由多个相互独立的框架组成，其中每个框架都精专于各自的领域，但同时又非常简洁、包容和灵活。
84.着重强调项目的商业价值：
a.形成价值陈述。价值陈述是你的决策摘要，用以说明组织的业务为何要采用某种特定的软件架构。这一步的关键，是要将你的架构方案与其他既有方案或可选方案进行比较。重点应放在说明其在提高生产力、改进业务效率方面的能力，而不是强调其采用的技术如何高明。
b.建立量化的试题标准。对于承诺要交付的价值，需要在合理范围内进行量化。量化得越具体越到位，项目也将越具说服力，越能让人相信好的架构可以带来丰厚的回报。越早建立试题标准，就越容易把握人们的认知，帮助推销自己的架构提案。
c.回过头来关联传统商业的衡量方式。如果能将技术分析转化为账务数据，则会更为完美。毕竟，传统商业衡量方式中唯一不变的参数便是经济收益。
d.知道该在哪里停止。在知道该在哪里停止之前，要准备好一张路线图用以捕获远景目标，清楚地知道每一个里程碑将带来的商业价值。让利益相关者自己决定在何处停止。如果每处的商业价值都十分显著，那么，很可能你会获得持续不断的资金支持。
e。寻找恰当的时机。
85.数据库的变化不应该影响构建活动的连续性。要把数据库也作为一个构建单元包含在内，做到一次性构建整个应用程序。
86.对于技术债务，它的利息表现为系统的不稳定性，心脏由于临时性手段和缺乏合适的设计、文档工作和测试带来的不断构筑的维护成本。所以，尽快还清技术债务。
87.我们应该学会像长焦镜头一样，不断地拉近放远，以确保正确的锁定问题，而不是只一味地接受别人给出的问题。不要立即着手去解决摆在面前的问题，而要看看自己是否可以改变问题。
88.对我们构建的工具，用户体验应该是上手的，这是成功的决定性因素。
89.分析瘫痪是今天架构师们碰到的问题之一，此问题最大的归因，是试图去猜测对未来而言最好的技术。
90.架构师的目标，是要去了解和衡量接受度问题带来的威胁，并朝能减轻这些威胁的方向开展工作。项目拥戴者可以帮助消除用户授受度问题。这个职位最理想的人选，是能代表用户或利益相关方的人，有时候，他要说服自己就是用户或利益相关方。如果没有这样的人，那么在一开始就要努力寻找这样的人。一旦召集到项目拥戴者，就要尽力给予支持。
91.可以借助询问：如果我加上总是，永远，不管在任何情况下，你对此还会做出同样的陈述吗？对陈述进行测试。对于如此绝对 承诺，人们通常会有所抑制，因此必须会进一步完善措辞。通过这种语言上的筛子，迫使其中的概念显现出来，并澄清概念。不断重复，直至只剩下可信陈述的详尽列表，这些可信陈述简单、可核实，描述了系统的本质特性。
92.对最终用户而言，界面就是系统