《软件架构师应该知道的97件事》摘…

近期，借了一本书——《软件架构师应该知道的97件事》，很不错的，都是一些拥有丰富经验的国外架构师们的一些观点，借此把一些觉得很好的论点摘录下来。

1. 关注根本复杂性，消除偶发复杂性，抽丝剥茧制定解决方案，才是真正的挑战。
2. 人才是项目成败与否的基础，对话是最古老但很完善的技术帮助你解决问题。学会尊重他人，给予团队成员充分的信任，是聪明的架构师获得成功必须掌握的核心技能。对话技巧——不要把对话当成对抗；不要带着情绪与人沟通；尝试通过沟通设定共同的目标。
3. 架构是决定应用性能的根本因素。
4. 分析客户提出的需求，定位真正的问题。
5. 起立发言无形中增添了一种权威和自信，自然就控制了场面。听众不会轻易打断你的发言。这些都会让你的发言效果大为改观。
6. 只有认识到故障始终会发生的这一事实，才能针对特定的故障设计对策。
7. 项目投资人在和你讨论项目及各类资源需求时，他明白他在和你谈判，会绞尽脑汁占得先机，故决不能在该决断下来的要求上妥协让步。
8. 所有需求必须量化，不允许出现“灵活”、“易扩展”等词，这导致验收时缺乏依据。
9. 不存在放之四海皆准的解决方案，也不可能做出一个十全十美的设计，需要在性能、可用性、安全等问题上做好平衡。
10. 提前关注性能，即在项目开始不久，就需要对项目周期性地进行性能测试，这样做可以在前期确定架构是否有问题，另外，也提供了一个起始基准，为今后诊断和解决性能问题提供重要依据。
11. 建设好团队的工作氛围和良好的工作习惯，不允许草率提交开发任务。尽量给开发人员提供一些方便的建构和测试手段，减轻开发人员的负担。
12. 业务目标至上，必须在业务、技术方面做好平衡。
13. 解决方案先简单可用，再考虑通用性和复用性。
14. 不要目空一切高高在上，认为什么都懂什么都对；不要炫耀技术才华，甚至是刁难开发团队，而且应该亲力亲为，并将技能传授给开发人员。
15. 要顶住压力，轻易不要缩短进度或调整进度。
16. 重视不确定性。这时要设法利用分离或封装将决策和最终依赖于决策的代码隔离开。
17. 不要轻易放过不起眼的问题，多和客户、团队成员沟通。
18. 让大家学会复用——让大家知道它们存在；让大家知道如何使用它们；让大家认识到利用已有资源好过自己动手。
19. 先尝试后决策。对于复杂或者不确定的问题时，先做个小项目尝试验证后再对其做出决策。
20. 应该掌握并精通业务领域知识，才能成为一个好的架构师。
21. 项目不易过大，可以把一个大项目分成几个小项目分阶段来完成，这样失败的可能性也会大大降低。
22. 不管是开发新项目还是替换已有的系统，都应该分段式部署。