软件架构与设计 第 19 课 People, Role, Teams

这节课我们来讲讲人在整个系统开发过程中所发挥的重要作用，或者再简单一点，就是成为一个架构师，到底需要什么特质以及在团队中扮演什么角色。

---

注：跳过了课本中我觉得部分『过时』或者『维基』上都有的常识性内容，这一章其实是本书的最后一章，但是课程其实才刚刚过半，后面的内容应该会和课程结合更紧密，我也会结合一些互联网公司的具体架构实践，来详细介绍背后的道理。

一个架构师需要什么技能呢？至少有以下几点：

• Software development expertise
• Domain expertise
• Communicator
• Strategist
• Consultant
• Leader
• Technologist
• Cost estimator
• Cheerleader
• Politician
• Salesperson

具体的能力需求，根据不同的项目和不同的领域，也会有细微的不同，下面按照不同的角色，来进行响应的介绍

作为软件开发专家

• 必须理解软件开发的细微差别
  • 准则
  • 方法和技术
  • 方法论
  • 工具
• 不一定要是世界级的软件开发者
• 应该理解不同架构选择的后果
  • 不要活在象牙塔中
  • 理解架构选择会限制实现的方式
  • 有些具体的实现技术也会限制架构选择

作为领域专家

• 只有软件工程方面的经验是不够的
• 理解问题领域的细微差别
  • 成熟度
  • 稳定性
  • 系统用户档案
• 可能会极大影响架构选择
  • 分布
  • 规模
  • 可进化性
• 需要为问题空间建模

作为交流者

• 至少一半的时间应该花在沟通上
• 听取权益相关者的意见
• 解释架构
• 协商折中实现
• 需要良好的沟通技能
  • 写作
  • 说话
  • 展示

作为策略家

• 开发优雅的架构是不够的
  • 技术只是一小部分
  • 架构必须放到更大的场景中也适用
• 架构必须满足公司的
  • 商业策略
  • 商业实践
  • 计划周期
• 也需要考虑对手的
  • 产品
  • 策略
  • 开发过程

作为咨询师

• 开发人员是首要的『客户』
• 对于开发人员来说
  • 目标和架构师不同
  • 甚至可能不关心架构本身，而是
  • 满足功能、质量和调度需求
  • 所负责的子系统
• 必须说服开发者
  • 理解和关注架构
  • 对架构相关的改动进行文档记录

作为领导

• 必须是技术领导者
  • 基于学识和成就
  • 根据想法、专业经验、学识来下达命令
  • 不要依赖于『等级权力』
• 保证大家遵守设计决定、指引和规则
• 为了保证产品质量，需要引入
  • 新的想法，解决方案和技术
  • 带领新人
• 做关键决定
• 帮助完成实现

作为技术人员

• 理解软件开发的方法
• 理解基本的技术，如
  • 操作系统
  • 网络
  • 中间件
  • 安全
  • 数据库
  • 图形用户界面
• 跟随技术潮流（不是盲从）
• 在下面领域是专家
  • 系统建模
  • 架构平衡分析
  • 把架构方案和系统需求结合在一起

作为开销评估者

• 理解不同架构选择的在经济上的影响
  • Green-field vs. Brown-field development
  • Cost of COTS adoption
  • Cost of development for reuse
  • Company's financial stability & position in marketpalce
• 技术上最优的方案可能在经济上不一定是最优的
• 简单快速的开销评估通常已经足够

作为啦啦队队长

• 在长期、大型的复杂项目中很有用
  • 不同的开发小组负责不同的子项目
  • 管理人员可能会忘记总体的项目目标
  • 顾客可能没办法接受漫长的等待
• 必须
  • 在必要的细节基础上维护高层视野
  • 说服不同的权益相关者关于架构的
    • Beauty
    • Utility
    • Adaptability
    • Technological impact
    • Financial impact
  • 让大家情绪高涨

作为政治家

• 必须找到组织中的关键人物
• 必须持续
  • 倾听
  • 维持网络
  • 善于表达
  • 兜售愿景
  • 从多个角度思考问题

作为销售人员

兜售

• 总体愿景
• 技术解决方案
• 架构的关键属性
• 系统的关键属性
• 开销计划
• 保证架构的实现

关于架构小组

• 由架构师组成
• 通常有不同的层级
• 随着进展进展人数会变动
• 架构师可能会成为
  • 子系统的开发组长
  • 调去其他的项目
• 定义软件架构
• 维护架构
• 评估技术风险
• 协调不同小组
• 辅助项目管理
• 辅助产品定义
• 确定主要设计的主要元素
• 确定系统的组织或架构
• 确定主要元素的交互方式
• 与系统工程师和开发小组合作

架构小组可能的风险

• 技能短板
  • 缺乏软件开发经验
  • 缺乏领域相关经验
• 缺乏权威
• 活在象牙塔中
• 混淆不同的工具、技术和方法
• 拖延