《编程匠艺》之软件的架构与改良

第三部分: 代码的形成过程(软件的架构)

1. 崇尚设计(如何做良好的软件设计)

1. 软件设计的层次
   • 系统体系结构(整体系统和子系统,以及子系统之间的连接方式)
   • 模块于组件
   • 类和数据类型
   • 函数
2. 设计良好的特征
   • 简洁和优雅
   • 模块化(高内聚,低耦合)
   • 良好的接口(为了创建良好的接口,可以遵循下面的步骤:)
     • 确定客户端, 了解它的需求
     • 确定供应端, 了解它的能力
     • 推断所需的接口类型(函数, 类, 网络协议?)
     • 确定操作的性质(究竟需要提供什么样的功能?)
   • 可扩展性(需要仔细评估现在的功能, 以后可能有的功能, 以后一定会有的功能)
   • 避免重复
   • 可移植性(尽量减少对特定平台的依赖; 可以添加一个平台抽象层来屏蔽差异)
   • 良好的文档(主要针对顶层的设计;在代码层面实现自说明)
3. 如何做好的设计?
   • 设计方法和过程
     • 结构化设计(以分治作为主要特征,把问题不断分解为更小的问题)
     • 面向对象的设计(面向对象的焦点在于系统中的数据,结构化设计焦点在于系统执行的操作; 可以花点时间看看设计模式)
   • 设计工具
     • UML
     • 设计模式
     • 流程图
     • 伪代码
     • CASE工具
4. 你如何衡量一段代码的设计质量?
   • 设计是很难量化的, 只是对设计的审美评价.判断设计质量的唯一途径就是阅读代码.

2. 软件的体系结构(奠定软件设计的基础)

1. 什么是软件体系结构?
   • 体系结构有时候被称为高层次设计.
2. 软件蓝图
   • 蓝图的作用:
     1. 确定软件的模块,库,组件
     2. 确定组件之间是如何通信的
     3. 有助于鉴别和确定系统中的接口特性,阐明子系统的角色和职责
3. 视图
   • 在体系结构的设计中,一般会有多个系统层来看待,就如同建筑有外观图, 布线图, 管道图等.主要包含:
     1. 概念视图,也称逻辑视图,显示了系统的主要部分和他们之间的关系.
     2. 实现视图,包含了实现模块的角度.
     3. 进程视图,使用任务,进程,通信来显示动态的结构.
     4. 部署视图,显示任务在分布式系统不同物理节点上的分布.
4. 在何时何处进行体系结构设计
   • 体系结构是需求达成一致后的第一个开发步骤.
   • 体系结构设计是独立于模块设计阶段的,虽然后续的详细设计可能会反过来修正体系设计.
5. 体系结构用来做什么?
   • 验证(可以来总体验证是否可行, 是否满足需求, 是否有重复的工作)
   • 沟通(体系结构将问题域映射到解决域, 并指明了如何扩展, 应该与软件保持一致)
   • 判断优劣(来评判是否需要开发这个东西;并标识出重要的易错点)
6. 体系结构最关注的是组件和连接.
   • 组件可以是对象,进程,数据库或者第三方产品.每个组件都是一个独立的功能单元.还会有描述外部可见性的东东.
   • 连接. 连接可以是简单的函数调用,也可以是穿过管道的数据流.可以是事件处理程序,也可以是传递的消息机制.连接可以是同步的,也可以是异步的.
7. 什么是良好的体系结构?
   • 一个良好的体系结构是简洁的.是精心选择的模块和合理的通信方式组成的.
   • 体系结构设计需要平衡好组件的粒度.体系结构不规定各个模块内部的工作机制.需要是尽可能的高内聚,低耦合.
   • 体系结构会列出已做出的设计决策,并阐明为什么比别的可选策略好.
8. 体系结构风格
   • 每种结构都有不同的特征:
     • 更改数据表示法,算法和所需功能的适应能力
     • 模块分割和连接的方法
     • 全面性
     • 满足性能要求的能力
     • 组件重用的考虑
9. 常见的体系结构
   • 分层的体系结构(如OSI参考模型)
   • 管道和过滤器体系结构(数据流是串行的,每个过滤器完整自己的功能,然后向下游传递,缺点是错误处理麻烦)
   • c/s体系结构(他将功能分在客户机和服务器上两部分)
   • 基于组件的体系结构(核心就是通信的基础结构或者中间件)
   • 框架()
10. 常见的接口类型:
    • API
    • 类层次结构
    • 组件技术
    • 数据格式

3. 改良与革命(代码是如何成长的)

1. 要下面的警告信息,防止代码开始腐烂:
   • 代码中遍布着大型的类和复杂的函数
   • 函数的名称很隐晦
   • 没有任何结构(不知道去哪里寻找某个功能)
   • 内容重复(有许多相互独立的代码做着相同的事)
   • 高耦合性
   • 在数据流过系统时,它在各种表示法之间反复转换
   • API变得模糊不清
   • 代码中导出都是权宜之计:治标不治本的修改.系统的外围尽是这种修改.
   • 有些函数的参数太多了
   • 添加新功能时,没有提供任何支持文档;现有的文档过时了.
   • 代码在编译时产生了很多告警
   • 你发现注释说:‘不要动这些代码‘

原文地址：https://www.cnblogs.com/yhp-smarthome/p/11079350.html