软件架构师应该知道的97件事之概括46-60

46、避免重复

你的开发人员在重复无需思考的工作吗？代码里面反复出现某些相似的片段？某些代码是复制粘贴后稍加修改而成的，如果出现这些情况，说明团队工作效率不高。

软件开发的真理：复制时魔鬼

                              重复性的工作拖累开发的进度。

消灭重复的内容是你的责任，为此，应该重新研究框架，创造更完善的抽象机制，请专门制作工具的程序员（toolsmith）帮你完成切面框架（aspect framework），使用代码生成器。要想消灭重复内容必须有人采取行动。

47、欢迎来到现实世界

工程师偏爱精确，整天和0和1打交道的工程师更是如此。

现实世界不是二进制的。顾客有可能撤销确认过的订单，支票有可能跳票，信件可能丢失，付款时间可能延迟，许下承诺还可能失信。

这些已经够糟了，可分布式系统又带来了新的不一致性。服务有可能失效，状态有可能在毫无征兆的情况下改变，事务处理可能得不到保证。

分布式系统不但是松耦合、异步、并发的，而且不遵守传统的事物语义。

48、仔细观察别试图控制一切

妄想掌控一切的架构师只能设计出紧耦合的、脆弱的解决方案，这一套已经行不通了。我们必须启动必要的辅助机制。

我们已经进入分布式、松耦合系统的时代。构建松耦合的系统多少有些麻烦，我们希望系统足够灵活，别因为一点点小的改动就支离破碎。

随着系统的配置越来越灵活，当前的系统配置包含了更多的信息，为了便于理解，必须从中提取模型。比如，搞清楚哪个组件负责向逻辑信道发送消息，哪个组件负责接收消息，就应该把组件间的通信关系用图标模型记录下来。

与模型驱动架构不同，你先构建出灵活的架构，然后从实际的系统状态中提取模型。

49、架构师好比两面神

罗马神话里面，两面神是司守门户和万物始末之神。他有两张面孔，凝视2个不同的方向。

两面神兼顾前后，过去与未来。架构师在不同的对象之间架起桥梁，比如梦想和现实、过去的成功和未来的方向、业务目标与开发i限制。

我们应该以两面神为榜样，工作上严格把关，综合考虑新情况与老经验，在成熟技术上不断创新，既满足当前的业务需求，又兼顾未来的额发展规划。

50、架构师当聚焦于边界和接口

“哪些应该在一起，哪些应该分开”

51、助力开发团队

架构师可以施加约束，也有机会成为推动者。

要确保开发人员拥有他们所需的工具。

要确保开发人员拥有所需的技能，确保他们能够获得必须的培训。

同时，也要尽可能的参与到开发人员的选拔中。

只要不违背软件设计的总体目标就让开发人员自己做决策。

最后，保护开发人员，不要让他们卷入到不那么重要的工作中。

52、记录决策理由

在软件开发社区，对于文档尤其是关于软件自身设计的文档的价值，争论颇多。分歧一般集中于两处，一处是“详细的前期设计”的有效价值，另一处则是使设计文档化和不断变化的代码库保持同步的难易程度。

记录软件架构决策理由的文档，长期有用，无需为之付出过多维护精力，具有很高的投资回报价值。

根据项目的不同灵活选择合适的文档格式来记录架构决策的方方面面，格式可以是文本、维基、或博客形式的速记备忘录，也可以使用较正式的模板。

比如这些文档：

可以作为和开发人员沟通的工具，说明应遵循的重要架构原则

当开发人员对架构背后的逻辑提出质疑时，使团队能够就事论事

向经理和利益相关者说明这样构建软件的确切原因

把项目移交给下任架构师

好处是：

它逼着你说出理由时，有助于确保基础是扎实稳固的、

如果相关条件发生变化，需要对决策重新评估，它可以作为一个起点

53、挑战假设，尤其是你自己的

延迟判决法则：“臆断是事情搞砸的根源”

软件架构师的最佳实践表明，应该记录下每个决策背后的理由，当这一决策包含权衡（性能vs.可维护性，成本vs.上市时间等）时尤须如此。

有些小道消息：

开源软件不可靠

位图索引带来的麻烦比好处多....

确保这些假设清楚明确，对后继者和未来的重新评估来说非常重要。更重要的是拿出证据。

不要忽略相关这个词语。

事实和假设是构建软件的两大支柱。务必确保软件的基石坚实可靠。

54、分享知识经验

从所有的失败的经验中，我们可以学到很多东西。在像软件开发这般年轻的行业中。为了持续发展传播经验和知识至关重要。每个团队在自己的小世界小角落里所学到的东西，可能会在全球产生影响力。

55、模式病

人们记录和发现模式，避免后来人重新发明车轮。

对于软件架构师而言，设计模式是极有价值的可用工具之一。使用模式，能够创造更易沟通更易理解的通用解决方案。模式与良好设计息息相关，如果发现自己试图把最喜欢的模式硬套在不适用的问题空间上，那么你也许是”模式病“患者。

不要让一展模式功底的欲望遮掩了务实真知。

56、不要滥用架构隐喻

架构师喜欢使用隐喻（metaphor）。对那些通常比较抽象、复杂和变化的移动的目标，隐喻提供了良好的具体媒介。找到实物作为正要构建的东西的隐喻，会更容易沟通和讨论架构全局。

滥用架构隐喻经常会出现问题，让架构师不知所措，比如：

业务领域的客户开始越来越喜欢系统隐喻，这时，系统还在构想中，在这种情况下所有各方共享的是最乐观的可能解读，但其中并没有包括任何必要的约束。

开发团队认为隐喻比实际业务更重要。由于团队耽溺于隐喻，你不得不开始修正那些古怪的决策。

所交付的系统包含了许多遗留名称，从早已老旧过时，有待重新鉴定隐喻，到多次重构和重复挖掘的概念。

57、关注应用程序的支持和维护

应用程序的支持和维护永远不是事后才考虑的事情。由于应用程序80%的声明周期都在维护上。

开发人员和支持人员拥有的技能不同，就像开发/测试环境和生产环境有截然不同的目的一样。

系统管理员会遇到的问题：

*系统管理员不能重新提交请求消息来重现问题。

*一旦投入使用，就没有调试器可以用了。

....

就会出现以下症状：

*大多数问题都需要开发人员参与。

*支持团队讨厌新的应用程序。

....

为了确保应用程序脱离开发人员之手后能成功运行，应该做到：

*理解开发人员和支持人员确实具有不同的技能

*在项目中尽早的引入支持负责人。

...

当系统管理员很开心的时候大家都会很开的。

58、有舍才有得

有时，接受某种约束或放弃某个特性，可带来更好的架构，这种架构在构建和运维上都会更加简单，而且成本更低，往往能产生富有创造性和创新性的结果。

59、先考虑原则、公理和类比，再考虑个人意见和口味

如果是单凭个人经验、意见和口味创建的架构是没有考虑原则、公理、和类比所带来的好处的。

这样做，架构文档化会更容易，从描述架构所遵循的原则开始即可。

原则清晰的架构能够把架构师解放出来，使其免于全面复审而忙得不可开交。

原则和公理确保了架构的一致性。

60、从“可行走骨架”开始开发应用

为了实现、验证和不断发展应用架构，一个非常有用的策略，便是从Alistair Cockburn所谓的“可行走骨架”开始。“可行走骨架”是对系统的最简单实现（a minimal implementation),它贯穿头尾，将所有的主要构件组件连接起来。从可工作的最小系统开始训练全部的通信路径，可以带来“正朝着正确的方向前进”的信心。

对于大型系统通常是由多名开发人员共同构成，对于大型系统而言更多的协调工作是必不可少的。

从“可行走骨架“开始，保持系统一直运行可用，递增式地进行培育，使其逐步增长。