构架与架构师44.ppt

架构师 ◇软件架构师——多领域知识（6） 架构师：要成为百科全书式的智者 1.架构师学习更多跨领域知识，也是为了在接受一个项目时，能更快更准确的找到解决问题的命门 2.好的架构师必须参与更大的项目 如果多学习跨领域、跨学科的东西，会不会成为什么都懂，但什么都不精的人？ 第0章 构架与架构师 架构师 ◇软件架构师——权衡取舍（7） 架构师：每天要在鱼和熊掌之间做选择 1.没有一个人可以建造一个没有缺陷的架构。这个项目可能缺乏时间，缺乏金钱，缺乏人手，或者缺乏合适的技术。 2.系统能够承受的范围内做出一些“权衡妥协”（哪些内容是必要的、不可丢弃的;哪些是暂时可以不予考虑的。） “在一个理想的世界中，只存在唯一一个一致模型：在实施一次升级之后，所有观察者都能够看到这个升级。” -- Werner Vogels “对于一个共享数据的系统而言，数据持续性、系统可用性、对网络划分的耐受性这三个属性（property）是不可调和的，任何时候只能同时达成两个。” --加州大学的Eric Brewer教授提出了CAP理论 第0章 构架与架构师 架构师 ◇软件架构师——沟通能力（8） 架构师的沟通主要在于开发团队内部，一种纯技术上的沟通。 第0章 构架与架构师 ◇软件架构师——管控能力（9） 架构师所需要的管理与控制，其实是从技术的角度，对一些问题的控制，特别是开发过程中的监控，而不是普通意义上的纯粹管理。 ◇软件架构师——艺术气质（10） 系统应当是优美的，而这优美体现在系统的伸缩性、安全性、可维护性、可靠性和可移植性等健康因素。 一个优美的系统则是可以像有机的生命一样成长的，这是因为从系统开始架构的那一刻起，架构师就考虑到这个系统以后将会面临的挑战，为系统的成长预留好空间。 架构师 ◇软件架构师——跟踪生命周期 分析：好的架构师会考虑非技术影响，以便了解需求和将在其中进行开发的环境。架构师可为风险评估任务带来广泛的软件经验供参考。 设计：在高级设计期间，好的架构师会收集问题空间的各个抽象元素，并就其进行沟通，将需求谨慎地映射到所得到的系统体系结构的功能。在详细设计期间，对特定模块的元素进行审查。 实现：架构师对项目进行引导，以确保其符合系统体系结构。架构师还要密切了解开发人员的进度，特别要跟踪系统中模块间的集成点的状态。 测试：架构师对系统集成和用户接受度测试进行指导，并负责评估进度的正确沟通的持续测试结果。寻找理解错误模式且善于将测试复查结果转换为行动计划的开发人员。 维护：在维护期间，架构师将发起关于系统集成的讨论。 第0章 构架与架构师 架构师 ◇软件架构师——成长路线 第0章 构架与架构师 软件开发团队和管理层之间的联系始终是 IT 中的一个关键所在。二者都倾向于以完全不同的方式考虑给定的问题。大部分相关技术都是讨论项目经理应如何跟踪和解释开发人员的进度和问题。但沟通不足的情况仍然非常普遍，而且这是项目失败的首要原因。好的架构师是解决这个问题的最有效办法。架构师的主要责任是提供开发人员和项目经理之间的共用沟通媒体。他们负责让业务规则及需求与工程实践及限制相适应，以确保成功。 * 系统的各个部分是互相关联的，因此为每一个变动考虑权衡（trade-off）是必要的，有意义的。 * 第0章 构架与架构师 构架 起因：17世纪20年代，瑞典和波兰交战。瑞典国王下令建造巨型战舰—瓦萨战舰。 要求：舰长70m，载员300人，两层甲板装载64门重炮 设计师：henrik大师 考虑因素：工期、性能、功能、安全性、可靠性、造价等。 实现方法：先按单层炮舰设计，在扩充为双层。 结果：试航礼炮未放完，就翻入水中。 分析原因：比例严重失调（构架存在问题） 说明问题：？ ◇软件构架 第0章 构架与架构师 构架 软件构架师技术、商业好社会等诸多因素作用的结果，而软件构架的存在反过来又会影响技术、商业和社会环境，从而影响到未来的构架。这种相互影响的周期称为构架商业周期 ◇软件构架商业周期 办公室里的争论 办公室里，关于什么是软件架构，争论正酣。 程序员说，软件架构就是要决定需要编写哪些类，使用哪些现成框架。程序经理笑了； 程序经理说，软件架构就是模块的划分和接口的定义。系统分析员笑了； 系统分析员说，软件架构就是为业务领域对象的关系建模。配置管理员笑了； 配置管理员说，软件架构就是开发出来的以及编译过后的软件到底是个啥结构。数据库工程师笑了； 数据库工程师说，软件架构规定了持久化数据的结构，其他一切只不过是对数据的操作而已。部署工程师笑了； 部署工程师说，软件架构规定了软件部署到硬件的策略。用户笑了； 用户说，软件架构就是决定一个个子系统如何划分。程序员又笑了； 大家想