代码大全（读书笔记）

2021.06.27 开始阅读此书，这篇文章记录了一些读此书或者这款时间工作生活的一些心路，希望自己能持续从此受益。

2021.08.05 此次阅读的关注点在第 3/5/6/7/12/13 章

我虽然是计算机行业从业者，但本身不是计算机专业出身，很惭愧没能更早的耳濡目染更多基础但不可忽略的知识，虽此行业已被很多其他行业从业者开始逐步进入，但私以为最基本的素养不应该被降低，也因此不断提醒和鞭策自己，学习是一件不得不做且应该去做的事。—2021.06.27

2021.08.13 理想的设计特征

2021.08.20 设计的层次

文章目录

代码大全（读书笔记）
- welcome to software construction
- - 软件开发的过程
  - 需求的先决条件
  - 架构的先决条件
- Key design concepts 关键设计概念
- - desirable characteristics of design 理想设计特征
  - levels of design 设计的层次

welcome to software construction

软件开发的过程

定义问题
需求分析
规划构建
软件架构或 high-level design
详细设计
编码与测试
单元测试
集成测试
集成
系统测试
保障维护

大部分公司其实都是「序列开发法」和「迭代式开发法」的混合，而绝大多数更侧重于前者。

references:

敏捷开发学习总结(1)：传统序列式软件开发方法的缺点，以及迭代开发方法的选择

需求的先决条件

一个 Objective 不够明确，看起来非常高大上，但实际上没有可量化的指标，回头想跟这里需求分析一样，需要明确的需求其实是一个项目良好的开端。

关于需求变更：不管是 toB 还是 toC 都无法避免需求变更，该书提醒我们有必要在变更频繁时：建立变更控制程序，使用能够适应变更的开发方法，当然有必要时也要放弃一个不合理的项目。

适应变更的开发方法更详细的是什么？

架构的先决条件

最终方案确定时，一个关键步骤是记录下摒弃其他方案的理由是什么，而最终方案不可替代的原因又是什么。

架构的典型组成成分如下：

部分顺序没有遵循原书中的设计，我自己也加入了一些个人观点，并对一些方面进行了合并和删减

program organization

架构应该定义程序的主要构造块，根据程序规模不同，各个 building block 可能是单个类也可能是许多类组成的子系统。同时应该提前考虑好构造块直接如何进行通信。

major classes

指明每个类的责任、继承体系、状态转换、对象持久化的描述
类和其他类怎么交互

个人觉得这是一个很重要的步骤，有利于对项目抽丝剥茧

data design

这里很关键的一步是：

数据通常只应该由一个子系统或者一个类直接访问：以受控且抽象的方式来访问数据。

business rules 业务规则
resource management

资源管理在 backend 架构设计中是经常需要考虑的一个方面，包括数据库连接、线程、Redis 等。
6. security

这也是一个很重要的方面，涉及到用户输入数据的安全性，怎么防御 xss、csrf 等，以及 sql 注入等常见的安全隐患

input/output 输入与输出 error processing 统一的错误处理 fault tolerance 容错性

在错误处理中需考虑到向用户吐露哪些错误信息是清晰的，同时需要考虑暴露错误栈的合理性。
7. user interface design 用户界面设计与 internationalization 即 i18n 国际化
8. scalability 可伸缩性 interoperability 互用性 Reuse Decisions 复用决策 change strategy 灵活变更的策略

目前的开发经验中，对于这几点除非在做架构设计之前已经有类似的需求背景，那么在复用性上的考虑可能会相对局限，但注意这仅仅针对整体架构。对于子结构而言考虑 interoperability 是很有意义且必须做的一件事。

Key design concepts 关键设计概念

desirable characteristics of design 理想设计特征

最小的复杂度：简单易于理解
易于维护
松散耦合：设计出相互关联尽可能最少的类。
可扩展性：增强系统功能但不破坏底层结构
可重用性
高扇入 high fan-in：大量的类使用某个给定的类，utils
低扇出 low fan-oout：让一个类少使用其他的类
可移植性、精简性、层次性、标准技术

levels of design 设计的层次

关于子系统：

为了让子系统之间的连接简单易懂且易于维护，应该尽量简化子系统之间的交互关系。（就是不要牵一发而动全身）

最简单的交互关系是：让一个子系统去调用另一个子系统中的子程序。

稍复杂的交互关系是：在一个子系统中包含另一个子系统的类；

最复杂的交互关系是让一个子系统中的类继承自另一个子系统中的类。