.net架构设计读书笔记--第一章 基础

第一章 基础

第一节 软件架构与软件架构师

简单的说软件架构即是为客户构建一个软件系统。架构师随便软件架构应运而生，架构师是一个角色。

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 防御性编程