软件架构师应该知道的97件事 笔记(四)

46. 避免重复
如果开发人员复制救命代码中的内容，说明这部分还可以简化，甚至全部提取出来。
消灭复制是架构师的责任，如果有重复，则应该重新研究框架，创造更完善的抽象机制。

47. 欢迎来到现实世界
现实世界是不可预知的，随时都可能发生一些让人预料不到的事情，如客户撤消订单，付款时间延误等。
如果现实世界带来了麻烦，不要怕，不要报怨，寻找解决办法应对即可。

48. 仔细观察，别试图控制一切
我们已经进入了分布式、松耦合的时代，不要妄想掌控一切，这样只会让你设计出紧耦合、脆弱的方案。但是撒手不管也是危险的状态。正确的做法是：仔细观察，提取模型，然后检查验证。

49. 架构师好比两面神
要有兼顾前后、过去与未来的能力。善于倾听和观察，思想开放，即要满足当前需求，又要兼顾未来的发展规划。即要让系统易于访问，又要保证系统安全；即要让设计符合当前的业务流程，又要体现管理层对未来发展规划的考虑。融合不同的思想和观念，兼顾不同的设想和目标，才能开发出皆大欢喜的产品。

50. 架构师当聚焦于边界和接口
分而治之，分离关注点。对架构师来说，困难在于找到设置边界的自然之处所需要的接口。情景地图为架构师提供了一个强大的工具，使得他们可以聚焦于“哪些应该归在一起，而哪些应该分开”，从而使他们能够以一种可顺畅沟通的方式，实施明智的分而治之。

51. 助力开发团队
要在职责范围内尽量去助力开发团队，不能仅仅是只说不做。要确保开发人员拥有所需的技能，定期进行培训、讨论、实践等。在选拔开发人员过程中，也尽量选择那些热衷于学习，有亮点的。当不违背软件设计的总目标时，就让开发人员自己做出决策。要保护好开发人员，避免让他们卷入太多不重要的工作之中。

52. 记录决策理由
记录软件架构决策理由的文件，长期来看非常有用，因为架构不会经常变，所以也不用付出过多维护精力。
它一般会记录如下基本问题：1. 我们做了什么决策？ 2. 为什么这样决策？ 3. 还有哪些解决方案没有采用？ 等等
用处：1.沟通工具 2.移交项目给别人 3.写文件也会迫使自己明确这样决策的理由，有助于确保基础是扎实稳固的。 4.当相关条件变化时，需要重新决策时，这份文档是一个不错的起点。

53. 挑战假设，尤其是你自己的
“臆断是事情搞砸的根源” --- 韦森“延期判决”法则
要对一些假设清楚明确，拿出相关的经验数据验证假设，最后再做出决策。事实和假设是构建软件的两大支柱。务必确保软件的基石坚实可靠。

54. 分享知识和经验
软件行业还非常年轻，想要持续发展，则传播经验和知识是非常重要的。
在个人层面，也利于成长，能更好的理解和修正已知的知识和经验。

55. 模式病
避免过度使用模式，适合的才是好的

56. 不要滥用架构隐喻
隐喻对那些通常比较抽象、复杂和变化移动的目标，提供了很好的具体媒介。无论是与其他队员沟通，还是与最终用户讨论架构全局，找到有形实物作为正要构建的东西的隐喻都是十分诱人的。这在开始的时候很有效，都使用一种语言，能让大家感觉到正确的方向，不断演化前进。但隐喻也容易被滥用。
滥用隐喻可能让其他团队成员沉溺于隐喻，且隐喻不能完全展现问题。如业务系统还在构想之中时，和方共享的是最乐观的可能解读，并没有包括任何必要的约束等。

57. 关注应用程序的支持和维护
架构师大多出身于开发人员，而非系统管理员，所以很容易站在开发者的角度上来思考。所以设计出来的系统，会让系统管理员遇到很多问题，导致很多新的问题。
要学会多角度考虑，尽早引入支持负责人，让其参与规划应用程序的支持。

58. 有舍才有得
CAP定理：在分布式系统中通常期望的3个特性，即一致性、可用性和分区容错性是无法同时获得的。
永远不要放弃质疑，因为架构设计的教条往往从根基上削弱了交付能力。权衡是不可避免的，并且接受一些权衡，往往能产生富有创造性和创新性的结果。

59. 先考虑原则、公理和类比，再考虑个人意见和口味
用原则、公理和类比来指导创建过程，有很多优点：
a)架构文档化更容易 b)更容易交流与传奇架构师的个人意见与经验 c)清晰的架构能把架构师解放出来 等
如果单凭个人经验、意见和口味来盲目地创建架构，是无法获得这些好处的。
原则和公理还能确保架构上的一致性。

60. 从“可行走骨架”开始开发应用
“可行走骨架”是对系统的最简单实现，它贯串头尾，将所有的主要的构架组件连接起来。然后小步的、增量式的，能不断得到反馈向正确方向前进。

61. 数据是核心
从概念上看，数据要比代码更加精练，也更好理解。即使对地最复杂的系统，从面向数据的视角，即通过底层信息的结构整体看待系统，也可将系统缩减为细节的有形集合。数据在大多数问题中牌核心地位，业务领域问题经由数据蔓延到代码中。只有数据真正构成了每个系统的核心。

62. 确保简单问题有简单的解
简单问题使用简单解，听起来容易做起来难。架构师经常出于炫技心理，容易过度设计。架构师会从主观的判断或潜在不确定需求出发，产生调整解决方案的强烈冲动。不要试图猜测未来的需求，错的概率是50%，错的离谱的概率是49%。不要从主观猜测未来需求，而是从反馈中不断生成真实的需求。