软件架构最佳实践和案例分析——笔记摘要

1.
架构不是一维的概念，要根据受众情况从多个方面解构。经典的视图包括4+1+2
2.
各种视图的实现方式（描绘方式）是没有定规的，但有些具体的实现细节可以采用标准的，如UML。
3.
逻辑视图可以用动画，开发视图中可以没有UML，而是一些框架组件的垒砌和他们之间的关系（如WebLogic，Spring等）。数据视图（数据架构）
可分为数据复制与分布，数据流的处理和安全性。
4.
架构视图的设计方式：结合实际可增加和减少视图；多视图可以组合；多个视图可以并行设计，由首席架构师领衔总体。
5.
本次架构课程所讲的架构设计所存在的软件工程模型接近于瀑布模型，需求分析阶段和架构设计阶段是并行进行的，然后才是High Level Design
—> Low Level Design
6.
架构技术要求对行业有深刻的理解（电信，银行，互联网）。架构师是一种经验工种
7.
目前瀑布模型还是有生命力的，原因包括政策因素（软件各个阶段需要验收），大型项目需要（特别是电信银行等行业）。但是可能正在趋向于迭代模型，扭曲原来
的process来尽可能的适应变化。
8. 架构设计的考虑因素：功能，质量属性，约束。后两个合称非功能性需求，非功能性需求更重要
9. 质量属性 （包括性能、可扩展性、可用性等等）驱动着架构的设计
（类似于变化驱动着敏捷软件的设计），而质量属性的各个方面经常是冲突的，此消彼长，因此需要通盘权衡。
10.
架构师必须脚踏实地，最佳实践是: 质量属性——场景——决策
11. 软件架构 <=> 程序设计 <=> 质量属性中每个因素的考虑  =》
都可以应用方法论：原则、模式、最佳实践。大师从最佳实践总结出实用的模式，再提炼出原则，而我们站在巨人肩膀上是先了解原则，再学习模式，然后再用于实
践。
12. 推荐书：软件构架实践（卡内基·梅隆大学软件工程研究所(CMU／SEI)）、面向模式的软件体系架构（卷1，2，3，4）
13.
真正做项目的时候，对技术的盲目追求反而是制约项目成功的一个因素，因为一个项目要从各个方面进行考虑，哪方面也不能过于偏重。（如易用性、可靠性、甚至
是政策法规）
14. 80% + 20%
15.
架构起码与两个东西密切相关：行业和应用类型。行业有电信，银行，互联网等，不同行业中的架构方式也是相差极大的。应用类型太多了，如联机数据处理类型，
联机数据分析类型，批处理类型等等，不同的应用类型也有不同架构设计方法。因此恪守一个行业，做精做专是王道。
16. 架构设计师的Metrix： 行业+技术+Softskill。
    行业是最重要的，需要深入而且广泛的积累（在本行业内部）；业务咨询师比较滋润，因为不怎么改变。
    技术是需要的，但不可痴迷，因为技术不可避免会抛弃你的，不断追寻新技术是疲于奔命的。
    Softskill，是什么点虚。
17.
hao123,初中生，500w；UCWeb，修改开源，1000万美元投资
18. 架构师的工作流程 （讲的太快了此处，需要进一步修炼）：

    功能分解（系统边界确定、子系统划分、接口定义） =>
逻辑视图

    立方图（分层+分区+质量属性） => 开发视图
19. 设计架构通常是分层组织的，(Application，InfraStructure,
Platform)。其中InfraStructure层是考验架构师水平的主要地方，此处提供软件所需的底层通用功能，例如进程间通信机制，持久化机
制，消息通信机制，并发控制等等
20.
架构评审：两种方式，一种是正式的，基于场景的。每一个迭代都要生成文档，这个文档可以用于追究责任或者逃避责任。另外一种是不正式的checklist
方式。
21.
架构需要强制实施。架构师的责任之一是确保自己的设计方案被执行；不同模块对底层功能的实现要保持一致性（例如实现消息通信的机制）；即使随着时间推移，
发现架构有不足之处也尽量要重构架构，而不是推倒重来，因为重来可能更垃圾。
22. 架构也敏捷，敏捷也架构 。
    架构一开始也是尽量保持简单，而且架构也需要重构。
    用敏捷来开发简单的中小规模项目时也许不需要架构，或者进行简单的架构。但是做大型项目时，在初期的几个迭代中，还是要进行架构设计的（老师原话）。自己 思考一下，如果做大型的电信、银行项目，不预先设计是不可能的。如果用敏捷来做，那么必须假设敏捷开发人员素质很高，以前有很多项目经验，可以信手拈来适 合的框架、第三方产品等，否则必须要有架构师先行架构。

来源：michael433899