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

2）如果可能的话，尽可能自动生成文档：手动写文档的坏处不多说，把 Swagger 和 RAML 或者公司内部开发的文档系统快点用起来吧。
3）文档尽可能少（As much as necessary, as little as possible）：文档尽量少。无论您需要写什么文档（例如决策文档），都应尝试一次只关注一件事，并且仅包含关于这件事的必要信息。大量的文档很难阅读和理解。附加信息应放在附录中。特别是对于决策文件，讲一个有说服力的故事更为重要而不是仅仅发表大量的论证。而且，这可以为你和你的同事节省很多时间，因为他们要阅读你的文档。看看你过去输出过的一些文档（源代码，模型，决策文件等），然后问自己以下问题：“是否包含所有必要的信息才能理解它？”，“确实需要哪些信息？可以省略吗？”和“文档中是否有红线？” 。一句话，不要废话。
6、沟通
不多说，沟通很重要。
1）学习怎么和别人沟通你的观点：推荐一本书 “UZMO — Thinking With Your Pen”。作为架构师你经常参会，甚至主持会议，所以你得学会如何和人们沟通你的想法。
2）通过演讲宣贯：一开始你可以向你身边的朋友表达，然后范围慢慢扩大，最后向众多人演讲来表述你的观点。如果你对此感到不适，你需要走出舒适区来加强提高这一点。保持耐心，这个可能需要一些时日。（有时候大佬的一句鼓励，会让你释放掉过往的不自信，开始相信即使最差发挥大家都会感觉到还不错。）
3）确定沟通的人群level：不同的利益相关者有不同的兴趣和视角。不同的人群需要单独的针对某一级别的人群去定向沟通。在沟通之前，请确认你要沟通的人群，比如抽象性、内容、目标、动机等。比如开发人员关注一些解决方案的微小细节，而管理者更倾向怎么省钱。
4）经常沟通：一个再好的架构没人知道它的价值依然为零。分发对应级别的架构，然后安排会议与开发者、架构师和管理者分享未来的和已经在践行的架构。
5）要透明：定期的沟通只能部分缓解透明度问题。你需要把决策的原因透明化。特别有的人可能没有参加决策过程的情况下会很难理解决策以及其背后的原因。
6）随时准备演讲：把常见问题放在一个显眼（易找到）的地方，随时应对人们提出的问题，这样有时候会保护你。
7、估算和评估
1）知道基本的项目管理和原则：作为架构师你经常会被问到如下问题，多久完成？得花多少钱？需要几个人？用到哪些技术？等。你需要学习一些估算技能。比如敏捷中的估算法等，建议到网上查阅这部分的资料。
2）评估未知架构（Evaluate “unknown” architecture）：作为一个架构师你也要能够去评估架构的适用性，针对目前和将来的适用性。这不是一个简答的事情，但你可以准备一些问题，然后去使用，以下是一些通用的问题：
①设计实践：

这个架构用了哪个模式？有没有被正确的使用？
这个设计遵循红线（red line）了吗？这个设计有没有能够可持续（uncontrolled growth）？
有没有一个清晰的结构和各自领域的单独关注有没有分布合理？

②开发实践：

代码指引手册有没有到位？遵循了吗？
代码版本管理怎么做的？有没有版本化？
部署是怎么分布的？

③质量保障：

自动化测试覆盖率怎么样?
静态代码分析有没有做？分析结果怎么样？交叉检查有没有做？

④安全：

有哪些安全概念到位？
内置安全？
渗透测试或自动安全分析工具是否到位，经常在用吗？

8、权衡（balance）
1）质量是有代价的：早先我谈到过质量和非功能性需求。如果你过度设计架构，则会增加成本，并可能降低开发速度。你需要权衡架构和功能需求。应避免过度设计。
2）解决矛盾目标：一个典型的矛盾目标的例子就是短期和长期目标。项目往往趋向于构建一个最简单的方案来解决问题而架构师则具有长期的眼光和愿景。一般情况下，最简单的方案往往都不能满足长期目标和愿景。为了避免技术实现步入错误的方向，有两件事情需要考虑：