软件架构师应该知道的97件事 笔记(五)
63. 架构师首先是开发人员
身居要位仍然要继续跟进各自领域的发展。获得开发人员的尊重和信任，让开发人员自愿接下任务。
时不时的去处理一些比较复杂的任务，目的：a)让自己做到宝刀不老 b)有助于向开发人员证明自己不是只会吹牛皮的
主要目标是创建可行、可维护的解决方案。且自己设计的系统自己应该能编程实现。
64. 根据投资回报率(ROI)进行决策
我们对项目所做的每一个决策--无论是技术、过程、还是与人相关都可以看作是一种投资形式。假设产品上市时间对投资方是至关重要的，那么快速发布就能带来更高的投资回报率，这个时候“完美的架构”就不如架构稍差，但能快速完成的版本。
将架构决策视为投资，并将相关的回报率也一并考虑在内。
65. 一切软件系统都是遗留系统
系统再先进，对接手它的人而言，都是遗留系统，所以不应该排斥这个标签。
66. 起码要有两个可选的解决方案
对某个问题，如果只考虑了一个解决方案，就有麻烦了。如果没有对比其它方案之前就想当然地给出了解决方案，那就要三思了。
67. 理解变化的影响
架构师在解决方案中给出的抽象，应该能为更高的层次提供坚实基础，应该能足够务实地应付未来的变化。了解变化，包括人与人，系统与系统的。要清楚认识解决方案中变化的类型和将带来的影响。
68. 你不能不了解硬件
架构师既要负责连接业务需求和软件解决方案，也要负责连接硬件和软件。硬件方面的一些知识同软件架构一样重要，比如说硬件的容灾能力、容量规划等。如果缺乏硬件规划能力，最好和基础设施架构师紧密合作。
69. 现在走捷径，将来付利息
碰到架构问题或设计缺陷，作为架构师，一定要坚持成本还很低廉时就动手。搁置越久，为之付出的利息也就越高。
70. 不要追求“完美”，“足够好”就行
“足够好”指的是，剩余的不完美之处，对系统的功能、可维护性或性能不会产生任何有深远意义的影响。
71. 小心“好主意”
“好”主意的邪恶之处：它们是好的，不容易被发现它们的问题，如：某框架有升级版本，我们也应该使用新版本。某技术很强大，我们可以把它用于……
72. 内容为王
很多系统无止境地强调需求、设计、开发、安全等，从未关注系统真正的要点---数据。对基于内容的系统，数据尤其重要。在新系统的设计过程中，必须留出一部分精力专心考评内容库。比如系统重点关注哪些内容，能否及时更新，内容主要来源等等。
系统的成功取决于其内容。
73. 对商业方，架构师要避免愤世嫉俗
自我感觉过于良好，往往会忘记倾听，并且会拒绝听取、分析别人的建议。过度自信，会让你在业务领域头破血流。业务是架构师职业存在的原因，为业务服务是我们的生存之本，倾听和了解雇主的业务，是我们必须掌握的最为关键的技能。
不能只提批评意见，还需要针对不足提出建设性的意见。
74. 拉伸关键维度，发现设计中的不足
通过某些关键维度被拉伸，可以以此来发现系统设计的限制。 (即提前想象某些维度被扩大、拉伸 )
如：了解基础设计的规划是否能够应付增长的需求，圈出限制范围。对吞吐量的峰值能否正常处理等等。
75. 架构师要以自己的编程能力为依托
为项目设计架构时，对实现每个设计元素所需的工作量，要做到心中有数：如果以前曾开发过其中某中设计元素，那么估算所需工作量就会容易得多。
不要在设计里使用自己没有亲自实现过的模式，不要使用自己没有用之写过代码的框架等等，如果架构依赖于各种你未曾亲身使用过的设计元素，那其中就存有许多负面影响，如无法估计实现设计所需的时间，无法容易的避免那些设计元素里面的陷阱，开发人员遇到问题时无法向你请教等等。
(架构师平时紧跟职业步伐，平常多关注，多自己使用一些框架、模式等，在需要使用这些东西的时候，肯定是有经验的了 )
76. 命名要恰如其分
如果不知道一个东西应该叫什么，那你肯定不知道它究竟是什么。
如果无法给出个合适的命名，那也就无法继续编程。如果发现自己需要多次理性命名，那么最好停下来，直到弄清楚要做的究竟是什么。
一定要起个好名字！！！！！！！！
77. 稳定的问题才能产生高质量的解决方案
最好的架构师不是去解决难题，而是围绕难题开展工作。架构师要能够将四处弥漫的软件问题圈起来，并画出其中的各边界，确保对问题有稳定、完整的认识。
如果问题是稳定的，那么问题解决之后，就永远不会再来烦你。
78. 天道酬勤
具有创造力虽然是成功架构师的一项重要特质，不过成功架构师同样还需要具有勤奋的特质。很多时候不是能力不足导致项目失败，而是由于勤奋不够，紧迫感不强导致的。
79. 对决策负责
很多失败的项目，究其根本原因，是因为做出了不当的决策，或无法执行正确的架构决策。
做出有效决策的方法：
a)对决策过程有充分的认识（决策以书面形式记录下来了，与决策执行人沟通过）
b)定期对架构决策进行复审，检查决策的实际效果和预期结果。
c)要贯彻架构决策，架构师不仅要参与设计阶段，后续仍然要持续跟进。
d)可以将一些决策交给问题域专家。
80. 弃聪明，求质朴
小聪明会诱导我们在软件开发中使用奇技淫巧。聪明的设计僵硬难改，细节会对全局产生太多的牵扯。质朴的方案中，每个组件只做一件事，组件耗时少，易于创建，以后维护也更容易。