6、质量属性决定了架构风格：
一种架构的风格，很大程度上与设计者如何满足质量要求的对策有关。需求的功能和非功能两方面都可能有质量要求。具体归纳如下：(1)、与功能性有关的质量属性主要包括：A、正确性：是指软件按照需求正确执行任务的能力。B、健壮性：指的是在异常情况下，软件能够正常运行的能力。正确性与健壮性的区别在于，前者是在功能需求之内描述问题，后者是在功能需求之外描述问题。健壮性一般有两层含义：首先是容错能力，其次是恢复能力。容错指的是发生异常情况不出错误的能力，而恢复指的是软件发生错误以后能恢复到没有发生错误钱的状态的能力。C、可靠性：是一个与时间相关的属性，指的是在一定的环境下，在一定的时间段，系统不出现故障的概率。通常用平均无故障时间来衡量。(2)、与非功能性有关的质量属性主要包括：A、性能：是指软件的“时间-空间”效率，而不仅仅是指软件运行速度。换句话说是速度要快而占用资源要少。性能=速度/资源。B、易用性：指的是用户使用软件的容易程度。C、清晰性：意味着工作成果易读、易理解。D、安全性：它的目的是系统应该具备防止非法入侵的能力，这既属于技术问题也属于管理问题。E、可扩展性：这反映软件适应“变化”的能力，包括需求、设计的变化、算法的改进和变化。F、可移植性：指的是软件不经修改(或者稍加修改)就可以在不同软硬件环境中使用的能力。
7、抵制前期进行庞大设计的诱惑：
(1)、架构应该具备易演化特征;(2)、项目开发周期不要超过6个月;(3)、分而治之：抓住真正的需求、分而治之(把大项目分成小项目)、设置优先级、尽快交付;(4)、增量式开发与交付：如果前期需求比较清楚，可以把一个大项目分成若干相对独立能够持续交付的部分，这样就可以把大问题分成若干小问题;(5)、迭代式开发与交付：如果前期需求不是太清楚，项目带有强烈的创新成分，可以使用具有强迭代的逐步求精的模型。
8、重构：
在不影响整体外部行为的前提下，不断地对软件进行细微的设计改进，这种渐进式的实践叫做重构。通过重构不仅能够降低维护成本，而且也为我们提供了改进代码质量的通用标准，并使我们能迅速添加新功能。从本质上说，重构根本上就是一个态度问题，而不全是技术问题。
在集中精力完成了代码逻辑以后，就需要集中精力做第二件事情，那就是重构。在对代码进行重构时，我们不会增加新功能，甚至也不会去修复bug。相反，我们会通过将代码变得更易于理解来提升代码的可读性。
重构要坚持不懈：(1)重构可以加快进度;(2)、重构应该是小步骤地进行;(3)、技术债务积累越多，重构的难度就越大。
9、对结构进行优化的基本原则：
在完成了功能逻辑之后，除了代码重构以外，很多情况下还需要重新审视一下软件结构，对结构进行重构。良好的结构设计需要遵循一些原则，而原则本身就是经验的总结。依据这些原则，我们就可以在设计中有良好的设计指向。如需求不变则不需结构。
结构的4条设计原则：(1)单一职责原则(SRP)：也被称之为内聚性原则;SRP原则的描述为：就一个类而言，应该仅有一个引起它变化的原因;(2)、开放--封闭原则(OCP)：OCP的关键是依赖于抽象。OCP原则的目的，是要求我们设计的软件实体(类、组件、函数等等)应该是可以扩展的，但是不可修改的。A、对于扩展是开放的：这意味着组件的行为是可以扩展的，当应用的需求改变时，我们可以对组件进行扩展，使其具有满足那些改变的新行为。换句话说我们可以改变组件的功能。B、对于更改是封闭的：对组件行为进行扩展时，不必改动组件的源代码，无论是动态链接库、DLL或者是Java的jar文件都无需改动。(3)、依赖倒置原则(DIP)：使用传统的结构化设计所创建出来的依赖关系结构，策略是依赖于细节的，这是糟糕的，因为这样会使策略受到细节改变的影响。面向对象的程序设计倒置了依赖关系结构，使得细节和策略都依赖于抽象，并且常常是客户拥有服务接口。事实上，这种依赖关系的倒置正是好的面向对象设计的标志所在。DIP的原则是：A、高层组件不应该依赖于低层组件。二者都应该依赖于抽象;B、抽象不应该依赖于细节，细节应该依赖于抽象。(4)、接口隔离原则(ISP)：这个原则用来处理“胖(fat)”接口所具有的缺点。类的“胖”(不内聚)接口可以分解成多组方法。每一组方法都服务于一组不同的客户程序。这样，一些客户程序可以使用一组成员函数，而其它客户程序可以使用其它组的成员函数。实际中当然也存在有一些对象，它们确实不需要内聚的接口，但是ISP建议客户程序不应该看到它们作为单一的类存在。相反，客户程序看到的应该是多个具有内聚接口的抽象基类。
10、关注变化、关注特征：
拥抱着变化而设计。让变化成为一个重要的设计要素，需求总是会发生变化。面向对象是个思维方式。基于接口进行设计。
软件复用(SoftwareReuse)：是将已有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码级复用，被复用的知识专指程序，后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。
软件重用，是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程。软件元素包括程序代码、测试用例、设计文档、设计过程、需要分析文档甚至领域知识。通常，可重用的元素也称作软构件，可重用的软构件越大，重用的粒度越大。
11、面向服务的架构(Service-OrientedArchitecture, SOA)：
面向服务的架构成功的要点是服务识别。服务识别的基本过程：(1)、了解项目的性质;(2)、业务牵头，一定不是技术牵头;(3)、明确产品的战略目标;(4)、研究企业业务流程;(5)、重用行业制品;(6)、建立契约基线;(7)、完善服务属性等级矩阵(ARMS);(8)、使用业务敏捷场景仿真(BASS)进行测试;(9)、拥抱变更。
12、架构与框架的区别：
框架是一个软件，但架构不是软件，而是关于软件如何设计的重要决策。但是在引入软件框架以后，软件架构决策往往会体现在框架设计之中。不论是架构技术还是框架技术，都是为了解决软件日益复杂所带来的困难，而采取的“分而治之”的结果。架构的思维是先大局后局部，这是一种问题在抽象层面地解决方案，首先考虑大局而忽略细节。框架的思维是先通用后专用，这是一种半成品，还需要通过后期的定制才能成为具体的软件。
框架和架构的关系可以总结为两个方面：(1)、为了尽早验证架构设计，或者出于支持产品线开发的目的，可以把通用机制甚至整个架构以框架方式实现;(2)、企业可能存在大量可重用框架，这些框架可能已经实现了架构所需的重要机制，或者对某个子系统提供了可扩展的半成品，最终软件架构可以借助这些框架来构造。
框架设计最重要的部分，其实并不在于采用何种技术方案来实现，而是对已经存在的业务过程进行深入思考，寻找它们的共性，探究其中的规律，建立恰当的模式，然后选择恰当的技术实现方案。
带团队关键因素：决心、手段(方法)、激情、信心，技术不是关键因素。
13、把经验归纳总结成理论：
总结是两方面的，(1)总结过程：归纳出良好设计必须遵循的步骤，以及每一步骤的目标、解决什么问题、应该有什么样的思考点和思考方向。(2)总结模式(设计模式)：模式是一种实践经验的总结，通过总结每个思考点的各种解决方案，并且和过程的节点装配在一起，形成能够指导他人的模式语言。
