架构的级别

应用级别

架构最下层级别（lowest level）。只关注一个单一的应用。非常的关注细节，关注底层设计（ Very detailed, low level design）。沟通往往只限于开发团队内部。

解决方案级别

架构的中间级别（mid-level）。关注的是一个或多个应用，从而满足某个业务需求 (业务解决方案)。有点高，但主要还是low-level设计。沟通跨多个开发团队。

企业级别

架构最高级别。关注多个解决方案（solution）。高级（High level）, 抽象设计（abstract design）, 需要总览全局，总览多个解决方案和多个应用架构师。沟通横跨整个组织。

协作价值 — 胶水粘合

水平，不同职能之间

比如业务，开发，或者不同团队之间

垂直，开发和管理人员之间

不同技术或者项目之间的集成桥梁

几个典型的活动

架构是一个持续的活动，尤其在敏捷中，有些活动需要不断的重复。

确定和决定要使用的开发技术和平台

定义开发标准，比如编码标准，代码cr流程，测试方法，工具等

协助识别和理清业务需求

设计系统和基于需求做出决策

记录和沟通架构的定义，设计和决策

检查和评审架构和代码，比如检查确定的模式和标准

与其他架构师协作

开发人员的教练和顾问

细化高级别的设计具体到低级别的设计

需要掌握的重要技能

分类 拆解 推荐 备注
设计 基础的设计模式 基础理论书籍
对模式和反模式的一些钻研 企业级实践
质量度量 可维护，可靠，适应性好，安全，可测试，可扩展，可重用等
尝试了解不同技术栈，扩展技术面 了解怎么实现的，
实践过，
有领域深度
分析和了解框架中应用的设计模式，了解他是怎么做到的
保持好奇，参加各种技术聚会，增强自己的思维能力和扩大社交网络
决策 重要性评价 概念完整
统一性
优先级 wsjf（weighted shortest job first）模型
知道自己的能力 只做自己职责内的事情，对别人的事情可以提建议，但不要做决策
评估多个选项 多个方案要有对比，也可以降低整体的风险性
简化 矫正解决方案
不要过度复杂，超出最初的问题
问题拆解为多个小问题（分治），保证可聚合
不断迭代优化整体方案（重构）
代码 开发人员不接受你的建议
不会真实理解开发人员面临的挑战 1 参与到项目中，经验 = 所见 + 情感 + 假设
2 找到正确的事情去尝试，采用 （可以生产中使用），试验（可以在某个项目中尝试，风险可控），调研（探索下对公司有哪些影响），保留（谨慎使用）
文档 代码是最好的文档 注释和设计合理
是否可自动生成
尽可能简约
沟通 随时演讲，常见的问题放到大家能看到的地方
保持对外宣贯
学习怎么和别人沟通，要经常参加甚至主持会议 UZMO — Thinking With Your Pen
确定沟通人群的级别，不同级别的人确定不同的内容
增加沟通频率，让在一线的人也经常分享自己的经验，心得
信息拉平，让大家都知道前因后果，
估算和评估 项目管理，基本原则 可以了解下敏捷中的估算方法，比如标准的用户故事
评估未知架构 1 设计实践
2 开发实践，指引手册，代码版本管理，部署怎么分布的
3 质量保障，谁来审核
4 安全
权衡 质量和速度不可能同时满足
矛盾目标，当下还是长远
冲突管理 Schulze von Thun的四眼模型（ “Four-Ears Model” of Schulze von Thun）
顾问和教练 有远见，设立里程碑 为每个里程碑确定基本的节奏，资源
构建实践社区 在一个专题上，经常邀请一些朋友，分享想法，统一想法，头脑风暴
公开讨论 任何事情都可以公开讨论，让大家对一个事情形成充分的了解
营销 为点子或者产品说服别人
坚持自己的观点，一直努力
找到自己的同盟，比如圈子，比如同事，被谁支持
重复它，久了大家就会认可

原文