第一章 基础
第一节 软件架构与软件架构师
简单的说软件架构即是为客户构建一个软件系统。架构师随便软件架构应运而生，架构师是一个角色。
2000年9月ANSI和IEEE发布了《密集性软件架构建议章程》Recommended practice for architectural description of software-intensive systems
1. 软件架构的目的
2. 架构师的角色与职责
第二节 成功的设计
成功的软件项目是充分实现了软件的需求，成功的软件设计是指成功的软件项目的实践，是根据已知技术设计可重用基础架构的最佳实现。
一、 软件的大泥球
大泥球是一夜之间形成，开始不会很大，它是一个团队的产物。
1. 大泥球形成原因
-
无法捕捉用户需求
业务需求、 利益相关者的要求、 功能要求、 测试要求
- 当项目不断增长时仍然坚持使用快速开发
项目开始时可能用户或产品经理承诺需求很简单，不会有变动，这是可能会选择一个简单的架构模式来实现。但随着开发深入，新需求会被不段挖掘出来，这里面监的问题是继续还是重做！
-
Imprecision of estimates 不精确的估计
在需求规格确认之后又有新的需求扩展，无法与项目预算达成一致
- Lack of timely testing 测试的滞后
集成测试问题
2. 大泥球症状
Rigid, therefore fragile 刚性，因此脆弱
Easier to use than to reuse 可重用难
Easier to work around than to fix 变通解决比修复更简单
二、软件的力学原理
什么导致一个软件项目失败？通常会归结于商务上的过失，需求没有明确，项目管理不足、成本估算错误、沟通延时滞后，甚至是人员关系不合！你很难意示到差的软件设计和代码对项目带来的伤害。
1. 组织文化
2. 团队和成员
3. Scrum 消防员
敏捷开过程序遇到的每一个问题都需要快速解决，所以要有人专门来解决这些问题，可能是一个人或是多个人
4. 领导和老板
软件项目成本预算是一个不可回避的问题，项目成本预算包括代码实现、测试、bug fix、文档等等。项目经理管理这些事务，项目汇报对象是项目经理。通常两者都缺乏信任，项目经理认识项目组阻碍项目推进，项目组认为项目经理压缩成本，想用更新钱办更多的事。
领导是一项目技能，领导都不会双向报怨，而是达成一致。
5. 改进团队代码质量
质量差的代码会带来更高的软件成本，因为它涉及到测试，维护，扩展等……
-
使用工具来改进代码
-
如何告诉他人他的代码有问题 由于心理方面，直接指证不好，需要沟通技巧
-
让每个开发人员做的更好 针对代码，而不是针对人员，通过人员素质提升来改进代码，加强培训。
6. 变更是软件项目的一部分
三、走出困境
-
遗留代码问题
我们经常要面对已有代码，必需要维护它、与新功能集成，这些代码称之遗留代码。
-
停止新的开发
-
隔离异常
-
测试覆盖
-
持续重构
-
是否需要添加人员
-
是否需要延时
第三节 软件设计原则
SOLID原则(Single responsibility, Open/close, Liskov's , Interface segregation, and Dependency inversion).单一职责原则、开放封闭原则、里氏替换原则、接口分离原则、依赖倒置原则
一、从杂乱无章到整理有序
High Cohesion、Low Coupling 高内聚底偶合 单一职责，依赖少，可重用
Separation of concerns 关注点分离 如业务逻辑，展示，持久化。（面向方面设计）
Isolation 隔离 对外隐藏逻辑，使用接口通信
二、Object-oriented design
定义类，评估定义类的颗粒度，定义类接口和继承结构和主要关系。
三、Development and design vectors 开发和设计的方向
1. 设计原则
- Single responsibility 单一职责原则
- Open/Closed principle 开放封闭原则
通过继承来扩展
- Liskov's principle 里氏替换原则
类开基类就可以被替换，子类的行为不能受制于父类。
- Interface segregation
接口尽量单一功能，不能所以所有方法放到一个接口里
public interface IDoor
{
void Lock();
void Unlock();
Boolean IsDoorOpen { get; }
Int32 OpenTimeout { get; set; }
event EventHandler DoorOpenForTooLong;
}
应该分成两个接口
public interface IDoor
{
void Lock();
void Unlock();
Boolean IsDoorOpen { get; }
}
public interface ITimedDoor
{
Int32 OpenTimeout { get; set; }
event EventHandler DoorOpenForTooLong;
}
- Dependency inversion 依赖倒置
高层模块不应该依赖底层模块都应该依赖于抽象
2、依赖处理模式 Patterns for handling dependencies
void Copy()
{
Byte byte;
while(byte = ReadFromStream())
WriteToBuffer(byte);
}
reader和writer依赖于底层实现，强偶合，按照依赖倒置原则应该改为以下代码
void Copy()
{
Byte byte;
IReader reader;
IWriter writer;
// Still need to instantiate reader and writer variables
...
while(byte = reader.Read())
writer.Write(byte);
}
谁来实现reader和writer
- Service Locator pattern 服务定位模式
void Copy()
{
Byte byte;
var reader = ServiceLocator.GetService<IReader>();
var writer = ServiceLocator.GetService<IWriter>();
while(byte = reader.Read())
writer.Write(byte);
}
ServiceLocator返回具体类，类似工场作用，ServiceLocator可能如下实现
public class ServiceLocator
{
public Object GetService(Type typeToResolve) { ... }
public T GetService<T>() { ... }
public Object GetService(String typeNickname) { ... }
}
使用服务定位模式需要慎重考虑，很多情况下，他实际上是个反模式，因为它依赖类的具体引用。
- Dependency Injection pattern 依赖注入模式
更好的选择是使用依赖注入模式
void Copy(IReader reader, IWriter writer)
{
Byte byte;
while(byte = reader.Read())
writer.Write(byte);
}
2.编码原则
Keep It Simple, Stupid
You Ain't Gonna Need It
Don't Repeat Yourself
Tell, don't ask 接口设计应该设计为准备，不应该去问能给我什么数据
什么是设计模式？
设计模式是适用于软件过程中解决一系列问题的核心解决方案
四、Defensive programming 防御性编程