架构师必备的37项技能清单( 二 ) _架构师

2）对模式和反模式进一步钻研：如果你已经知道了所有基础的GoF设计模式，接下来可以扩展自己的知识储备去学习更多的软件设计模式，或对你感兴趣的领域进行垂直钻研。我个人比较喜欢Gregor Hohpe写的一本书叫：Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions 。这本书主要的内容是系统之间的数据交换（应用集成方面）。
3）知道质量度量（quality measures）：确定和定义架构不是终点。你还需要让你的系统可维护、可靠、适应性好、安全、可测试、可扩展、可重用等。所有这些都满足了，才算是一个好的架构。你可以去百科上去看看有关quality measures的内容。不过理论固然重要，但实战同样重要，甚至更重要。千万不要变成“象牙塔架构师”（http://www.gitshah.com/2011/01/ivory-tower-architect.html）。
【架构师必备的37项技能清单】4）尝试并了解不同的技术栈：我认为这是非常重要的，如果你想变成一个更好的架构师的话。尝试去了解新的技术栈，然后学习下这些技术是怎么实现的。不同的新的技术一般是使用不同的设计思路和模式。简单地去看看PPT之类的你可能并不能学到什么，你只有亲自去实践了，才会感受到痛苦和甜蜜。一个架构师不能只是面广，在某些领域还要扎得深。也许hold住所有的技术栈不是最重要的，但你需要在你的某个最重要的领域要有独到和扎实的见解。同时你也学习一下不属于你领域的技术，比如你是JAVA，那么你也要学习一下JavaScript等前端语言或技术，反之亦然。
5）分析和了解框架中应用的设计模式：你可以去研究当前任何开源的或正在使用的框架，比如Angular. 你可以学习到在实践中的很多设计模式，比如Observables 。尝试去搞懂该模式在这个框架中是如何被使用的，为什么它这么做。如果你真的狂热，也可以看看源码并且搞懂它是如何实现的。
6）保持好奇并去参加各种技术聚会：在德国，我们有个Java User Group (JUG) 组织，这个组织在每个大点的城市都有。我们会讨论各种topic，从low level的编码到上层的有关架构的主题。我真的热爱这些活动，因为它可以增强你的思维能力和扩大你个人的社交网络。
2、决策（决定）
架构师需要能够做决定并且引导项目或整个组织朝着正确的方向迈进。
1）知道什么是重要的：不要浪费时间在那些不重要的决定或活动上，学会认识什么是重要的。目前看来也没什么书籍教你识别这些。我个人有个原则，每当我要评价一件事是否重要我就会考虑这两个方面：

概念完整性（Conceptional Integrity）: 如果你决定以某种方式去做，那么就干，即使有时候会有更优的方案。通常来说，这会使得你有一个直接的全局的概念，使得更容易理解和更容易维护。
统一性（Uniformity）:比如如果你有名称的一些约定，当然无论是小写还是大写，至少让每个地方都是用同样的方式，比较统一。

2）优先级：有关这方面建议去看一下Weighted Shortest Job First (WSJF) 模型，这个模型被广泛用于敏捷软件开发中。尤其是时间紧迫性（ time criticality）和降低风险（risk reduction）对于评估架构决策优先级至关重要。
3）知道自己的能力：不要对你不了解的事情做决策和决定。各级干各级的事情，要理清每一层的责任，然后对你所负责的层去做决策。如果有多个架构师，那么你应该遵循目前你所安排的架构级别。作为一个lower level架构师，如果对higher level的架构不满意，可以提建议，而不是做决定。此外，我建议始终与同伴一起检查关键决策。
4）评估多个选项：应该总是给出多种方案，这样才能进行做出决策和决定。不要只给一个方案，听着感觉就是你没有认真工作一样。另外只有一个方案的时候，也没法做出一个合理的选择，因为只有一个方案。另外就是要定义一些指标和标准，通过这个来衡量哪个方案好，哪个方案不好，最好不要去凭感觉。比如：license花费或成熟度（本文有讲到成熟度模型）。这样才能做出一个更好的决策。
3、简化（化繁为简）
记住一个解决问题的原则Occam’s Razor 。这个原则告诉你解决问题要简单。这个原则里有一句话叫：最简单的那个solution往往是最好的。我总结这个原则的核心是：如果你对某个问题有多个假定解决方案，这很有可能就是错的，或者导致没必要的复杂的解决方案。多个假定方案应该被简化到只有一个好的解决方案。别提出来一大堆解决方案，说这个也可以，那个也可以，说明是有问题的。