46. 避免重复
如果开发人员复制救命代码中的内容,说明这部分还可以简化,甚至全部提取出来。
消灭复制是架构师的责任,如果有重复,则应该重新研究框架,创造更完善的抽象机制。
47. 欢迎来到现实世界
现实世界是不可预知的,随时都可能发生一些让人预料不到的事情,如客户撤消订单,付款时间延误等。
如果现实世界带来了麻烦,不要怕,不要报怨,寻找解决办法应对即可。
48. 仔细观察,别试图控制一切
我们已经进入了分布式、松耦合的时代,不要妄想掌控一切,这样只会让你设计出紧耦合、脆弱的方案。但是撒手不管也是危险的状态。正确的做法是:仔细观察,提取模型,然后检查验证。
要有兼顾前后、过去与未来的能力。善于倾听和观察,思想开放,即要满足当前需求,又要兼顾未来的发展规划。即要让系统易于访问,又要保证系统安全;即要让设计符合当前的业务流程,又要体现管理层对未来发展规划的考虑。融合不同的思想和观念,兼顾不同的设想和目标,才能开发出皆大欢喜的产品。
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%。不要从主观猜测未来需求,而是从反馈中不断生成真实的需求。