《微软架构师的工作实践》由会员分享，可在线阅读，更多相关《微软架构师的工作实践（44页珍藏版）》请在金锄头文库上搜索。
1、微软软件架构师的修炼之道黄学东 微软移动搜索与广告总架构师 演讲提纲 微软软件架构师的故事 微软语言技术架构案例 问答微软软件架构师的故事何谓架构师？ 设计师、画图员、结构设计者 与建筑类似，软件系统工程中亦然 架构师不是通过学习理论修炼来的 架构师胚胎：实干程序员 架构师幼苗：掌握了理论，软件团队开发和管理经验 软件架构师：机遇努力天赋缺一不可微软架构师概述 资深的技术专家 公司总架构师 部门总架构师 产品架构师 杰出的领导能力 影响力 技术和知识的深度和广度 战略思考的能力微软架构师的特点 重要却又没有“管人的权力” 靠战略视野去影响 靠技术能力去协调 靠对问题的理解去说服 靠经验去“征服
2、”微软架构师的工作实践 以战略问题为导向，关注战术问题 以全局为主导，指导局部实施 以经验为参考，注重技术创新 以项目启动阶段为重点，贯穿整个产品开 发周期 以高层次设计为主，参与功能模块的设计 以概念设计为核心，统筹实施和部署设计微软架构师的成长 架构师胚胎：实干程序员 架构师幼苗：掌握了理论，软件团队开发和管 理经验 软件架构师：机遇努力天赋缺一不可 工作实践的积累 技术的精湛与全面 综合能力的训练 机遇架构设计与产品开发 架构设计与产品开发周期密切相关 常见的开发周期模式 瀑布模式 分期渐进模式 敏捷模式 极限编程模式 测试驱动模式 架构设计与产品开发 软件产品开发步骤 确定需要解决的问
3、题 制定解决问题的方案计划 设计解决方案所需要的软件 实现（编程+测试）所设计的软件 出售或者部署开发的软件 产品售后支持架构设计与产品开发 微软的开发过程 高层次的指南 各组/项目有自己的理解和执行手段 采用混合周期模式 总体规划上采用瀑布模式 具体实现时采用分期渐进模式 周期可以重叠，每个周期内可以有“小周期”架构设计与产品开发 组织模型 产品单位模型（PUM） 产品单位 单位项目管理经理 项目管理组长，组员 开发经理 开发组长，组员 测试经理 测试组长，组员 架构设计与产品开发 产品单位模型的利弊 适用于比较小的项目组（200人以下） 单一的项目主管 职业发展的空间有限架构设计与产品开发
4、 功能组织模型 副总裁挂帅 项目管理总监 部门项目管理经理 项目管理组长，组员 开发总监 开发经理 开发组长，组员 测试总监 测试经理 架构设计与产品开发 “三驾马车”协力，问题直接通到副总裁 具体功能没有明确的负责主体 力量强大，适合大型复杂项目 Windows, Office, SQL Server, Live Search架构设计与产品开发 架构师的作用与影响 决定产品的技术路线/方案 决定产品的体系结构 指导构件的设计 指导界面的设计 协调设计方案的冲突架构师的典型任务 产品早期 攻坚技术和创新以提升竟争力 了解客户需求以提供最优产品 关注业界动向以制定战略战术 产品中期 大量开会以影
5、响和贯彻执行产品开发 攻坚新技术难题 调整战略战术 产品末期 总结学习以提升下一版本的竟争力 制定新的战略战术 度假或找工作架构师的“角色” 架构师主控的 产品质量 跨组协调 帮助团队成长 领导力 以身作则架构师的“角色” 工作方式 不能只考虑编程 为经理“预测”未来 从长远考虑问题 参与和鼓励分享 参与面试 面试关键人员 意见得到重视 影响面试的过程架构师的“角色”资深SDE主任SDE合伙人SDE架构设计为功能范畴设计 完整的架构为产品或复杂系 统设计可扩展的 架构主导产品线的可 扩展的架构设计风险管理识别要素范畴内 的风险并提出应 对策略引导跨组间的协 调，确保产品的 整合和按时出品在公司
6、范围内倡 导关键产品决策 ，技术决策，和 客户价值观 程序质量提倡和确保编程 标准确保程序检评， 强化标准，提高 团队的设计和编 程能力在整个产品线提 高质量客户/合作 伙伴利用客户参与去 改进功能的质量处理影响整个产 品的质量问题解决产品线的质 量问题设计与质量 设计思维 过程 以目标用户为核心 基于用户反馈的全部产品使用场景 评价过程的度量标准 对每一个使用场景，通过“头脑风暴”提出多种方案 迭代，原型，测试，迭代设计与质量 设计思维（续） 行为 通过“头脑风暴”得到可能的使用场景 简述各种想法和方案，不作评价 不强调精确和细节 创建多种原型 通过真实用户来评测想法 增强对用户的理解设计与
7、质量 设计思维（续） 心态（mindset） 我不是用户 第一个主意不一定是最佳的 最佳方案可能与现有的思维完全不同 如果沉浸与某一个想法，就会产生“隧道型视野” 从不同背景的人群中吸取长处 做好少数几件事比一般地做许多事更好设计与质量 设计思维（续） 如何避免“隧道视野” 借助团队和用户扩大自己的视野 启用“头脑风暴”，不要轻易排斥任何主意 在确定某一方案前，对其他方案反复探讨 从没有被影响的人那里听取看法 经常利用真实的用户去检测 注意：当选定某一方案后，你就处于“隧道”之中了 ！设计与质量 谁决定改进？ 工程系统 组织结构 质量标准和度量 测试策略 功能要素（feature）团队的结构和
8、实践 分支机构 建造体系（build system） 项目管理设计与质量 如何提高质量 明确什么是“完成了” 定义度量的指标 Checkin系统 工程工具 编程检评（code review） 设计检评（design review） 单元测试团队协作 影响力（无权威或有权威） 团队成员会认真对待你的意见 让团队成员认为想法是他自己的 利用一对一的会议交流想法 检评时采用成员喜欢的方式 关注长远的结果，不要拘泥于短期的决定 设想产品可能受到的最初评价团队协作 如何展现自己 奉行“开门”政策 热衷新的想法 不作过多的评价 善于聆听，乐于学习 保密 不要热衷于“曝光” 不怕被证明“出错”团队协作 委派
9、（delegate） 学会如何激励 扶持团队成员“上路” 经常查看 建立可以印证的体系 不要抢占他人的功劳 给与成员成长的时间和空间团队协作 参加新组 期望高，知识有限 找出关键的影响人 承认你不懂 了解和改进工程过程 细心决策团队协作 架构设计团队 “虚拟”的团队-产品架构设计与要素专家 经常开会 检评使用场景和需求 设计并执行产品的界面，层次，和依赖关系 主导质量，可行性和技术更新 鼓励委派 倡导架构设计“宪章”绩效思维成长与发展 保持与团队的关联 明了产品程序 了解竞争对手的情况 掌握未来的技术 为团队提供新的信息 清除团队的“历史” 成为“连接点”成长与发展 自我成长 多看(给自己留点
10、看书的时间) 参加技术会议(听众,演讲人) 读/写技术“博客” 勇于担负领导角色 鼓励他人学习新东西成长与发展 创新 分享想法 尝试新想法 发表文章 建立创新“社区” 激发兴趣 听取反馈 发表有意义的创新文章 拓展和保持联系成长与发展 时间管理 减少会议时间 少开会,开小会 只参加必须到场的会:架构设计,一对一 坚持围绕会议主题，会后发会议总结 减少干扰 将日常会议安排在同一天 限制email电话等通讯手段 不要成为或者依赖“英雄”成长与发展 架构设计的核心是整合（integration） 整合的核心是协同工作（collaboration） 协同工作的核心是交流（communication）
11、交流往往占用你整天的时间 要做的事总比能做的事多 必须确保有时间做“应该做的事”微软语言技术架构案例Command line1985 PC1990 GUIMultiple Windows Menus1995 InternetHyperlinksSearchCloud Services Smart devicesContext-aware natural languageMultimodal (speech, ink, touch)The Software EvolutionHuman Error RateHuman Error RateSpeech Recognition: Approaching Human Error RateMicrosoft licensed CMU Sphinx-IISAPI 1.0SAPI 4.0SAPI 5.0SAPI 6.0The New Frontier43
