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

第一章 基础

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

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

2000年9月ANSI和IEEE发布了《密集性软件架构建议章程》Recommended practice for architectural description of software-intensive systems

1.  软件架构的目的

2.  架构师的角色与职责

第二节 成功的设计

成功的软件项目是充分实现了软件的需求，成功的软件设计是指成功的软件项目的实践，是根据已知技术设计可重用基础架构的最佳实现。

1、 软件的大泥球

大泥球是一晚上之间造成，开始不会很大，它是一个团队的产物。

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 变通解决比修复更简单

 

2、软件的力学原理

什么致使一个软件项目失败？一般会归结于商务上的过失，需求没有明确，项目管理不足、成本估算错误、沟通延时滞后，甚至是人员关系不合！你很难意示到差的软件设计和代码对项目带来的伤害。

1. 组织文化

2. 团队和成员

3. Scrum 消防员

敏捷开过程序遇到的每个问题都须要快速解决，因此要有人专门来解决这些问题，多是一我的或是多我的

4. 领导和老板

软件项目成本预算是一个不可回避的问题，项目成本预算包括代码实现、测试、bug fix、文档等等。项目经理管理这些事务，项目汇报对象是项目经理。一般二者都缺少信任，项目经理认识项目组阻碍项目推动，项目组认为项目经理压缩成本，想用更新钱办更多的事。

领导是一项目技能，领导都不会双向报怨，而是达成一致。

5. 改进团队代码质量

质量差的代码会带来更高的软件成本，由于它涉及到测试，维护，扩展等……

• 使用工具来改进代码 
• 如何告诉他人他的代码有问题  因为心理方面，直接指证很差，须要沟通技巧
• 让每一个开发人员作的更好  针对代码，而不是针对人员，经过人员素质提高来改进代码，增强培训。

6. 变动是软件项目的一部分

 

3、走出困境

• 遗留代码问题

咱们常常要面对已有代码，必须要维护它、与新功能集成，这些代码称之遗留代码。

• 中止新的开发
• 隔离异常
• 测试覆盖
• 持续重构
• 是否须要添加人员
• 是否须要延时

 

第三节 软件设计原则

SOLID原则(Single responsibility, Open/close, Liskov's , Interface segregation, and Dependency inversion).单一职责原则、开放封闭原则、里氏替换原则、接口分离原则、依赖倒置原则

1、从杂乱无章到整理有序

High Cohesion、Low Coupling  高内聚底偶合 单一职责，依赖少，可重用

Separation of concerns 关注点分离  如业务逻辑，展现，持久化。（面向方面设计）

Isolation 隔离  对外隐藏逻辑，使用接口通讯

2、Object-oriented design

定义类，评估定义类的颗粒度，定义类接口和继承结构和主要关系。

3、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  接口设计应该设计为准备，不该该去问能给我什么数据

 

什么是设计模式？

设计模式是适用于软件过程当中解决一系列问题的核心解决方案

 

4、Defensive programming 防护性编程