代码大全随笔
Published: 2024-01-22 18:06:11

本书特色：检查表？（目前还不太清楚是什么东西），例程（超脱了语言的束缚），强调了创建活动的重要性，（详细代码、编码、调试、单元测试，貌似是这样，也可能不是），

# 第一章 欢迎进入软件创建世界

## 1.1 什么是软件创建
这项工作的主要方面：
1.问题定义
2.需求分析
3.实现计划
4.总体设计
5.详细设计
6.创建及实现
7.系统集成
8.单元测试
9.系统测试
10.校正性的维护
11.功能强化

创建活动主要指编码和调试过程，亦包括详细设计和测试中的某些工作。

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/p2wu911ir75iooydhvbb.png)
创建活动包括了：编写源代码、代码审查和重构、单元测试和验证代码的正确性、集成不同的代码模块、调优和优化性能、编写文档和注释以提高代码的可读性和可维护性。
创建活动在开发软件中有着及其重要的地位、主要精力用于创建活动，可以极大地提高程序员的生产效率。 
创建活动是总体设计和系统测试之间承上启下的工作。
对于创建活动的其他称谓有：实现、编程等。

# 第二章 利用隐喻对编程进行更深刻的理解

好的隐喻就是，软件开发之创建活动和建造建筑很像。
智能工具箱隐喻也是很不错的。
对于一个很大的软件工程来说，比如750000行代码的系统，可能需要多大600页的功能定义文件，所以说**计划**对于大型软件要在更高的层次进行。

# 第三章 软件创建的先决条件

## 3.1 先决条件的重要性
测试不是控制软件高质量的最重要的部分，只是全部质量控制策略的一部分。有很多错误要在创建工作开始之前就清除掉。

如果我们在创建中间强调质量，那么我们强调的是创建活动。
如果我们在计划开始强调质量，意味着我们要设计一款高质量的产品，比如如果我们一开始设计的是菲亚特，那么在创建中间强调质量，这点如果做的再好，也无法做成劳斯莱斯。

### 3.1.1 造成准备不足的原因
对于我来说，那肯定就是项目赶得急，时间不足，就无法把控质量。

在创建工作之前一定要进行充分的准备工作

### 3.1.2 在创建工作之前必须做准备工作的论据

#### 求助于逻辑推理
从管理人员的角度来看，计划是确定一个项目所需要的时间、人力、物力和财力。从技术人员的观点看，计划是指弄清楚你想要干什么，以免做出错误的工作而徒耗精力和钱财。如果我们一开始没做好准备工作，那么可能方向歪了，浪费很多

#### 求助于类比
建房子之前画好建筑图和蓝图；圣诞树立起来之后，我们才装饰；

程序员处于软件开发食物链的最后一环。结构设计吃掉需求分析；详细设计者以结构设计者为食，而他自己又成为编码者的食物。比较软件食物链和真正的食物链，我们会发现如下事实，在一个正常的生态系统中，海鸥以沙丁鱼为食，沙丁鱼吃鲜鱼，鲜鱼吃水虱，其结果会形成一个正常的食物链。在编程工作中，如果软件食物链的每一级都可以吃到健康的食物，其结果是由一群快乐的程序员写出的正确代
码。在程序设计中, 如果需求定义遭受了污染，那么这又会影响结构设计，而这将最终影响创建活动。这将导致程序员们脾气暴躁而营养不良，同时生产出遭受严重污染而充满缺陷的软件。

一次完成是最好的选择，不必要的修改比较昂贵，在项目初期进行更改，比创建和维护阶段更改相比，成本低50-100倍数。一旦引入错误，就尽早发现并且消除，（如同屎山的危害）

## 3.2 问题定义先决条件
问题定义应该从用户的角度出发，用用户的语言进行定义。

## 3.3 需求分析先决条件
需求是由用户决定系统的功能，需求定义可以避免程序员之间的争议，可以对系统作的改动最小。我们要对需求进行分析，看看有没有错误，如果有错误的话此时改动成本最小。

### 3.3.2 需求稳定的神话
但是很多时候需求都是变动的，所以我们要一直随着需求变

### 3.3.3 在创建阶段如何对付需求变化
如果需求分析做的不好，马上停止，重新返回到需求分析阶段，这是很有必要的。

让每个人都知道变化需求所付出的代价。
确立审查更改需求的正式委员会，有一套控制更改的正式过程。

用开发的方法来容纳变动
先原型化开发，然后渐进开发，

放弃项目
如果项目比较奇怪，那就直接放弃砍掉

### 3.3.4 检查表
书中的这个表中的每一个问题并非都适用，比如一些非正式项目，但是如果正在从事一个大型的正式项目，最好还是仔细考虑每一个问题。

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8zpwqw44uugzcamr8pf9.png)

## 3.4 结构设计先决条件
较高层级的软件设计，是详细设计的框架，和需求定义一样，变动结构设计的成本也是昂贵的，书中的这部分主要是**如何确定一个现存结构的质量**。

### 3.4.1 典型的结构要素

#### 程序的组织形式
要是模块化的，我们要清楚的知道自己所开发的这一个模块对系统有什么贡献，一个模块并不是子程序，而是能完成某一高级功能的子程序的组合。每一个模块做什么应当作出明确的定义。一个模块应该只完成一项任务。如果两个模块覆盖了同一项功能，那么他们应该是互补的而不是冲突的。对于模块间的关系也应该明确定义，哪些模块可以被哪些模块调用，哪些不能调用。

#### 变动策略
由于在创建过程中作出变动是不可避免地，所以结构设计应该能清晰的描述系统应付变动的策略。
建议使用表驱动技术而不是硬编码技术。这样可以不必重新编译就能对程序作出调整。

#### 购买而不是建造的决定
用老程序，用别人写好的，开发成本是极其昂贵的

#### 主要的数据结构
1.数据结构很重要，当我们更换数据结构，就一定要解释为什么它优于其他类型的数据结构
2.结构设计应详细说明使用的主要文件、表和数据结构。包括组织形式和内容。
3.不应允许多个模块直接访问相同的数据结构，保证信息隐藏，降低系统复杂性提高可维护性。
4.如果程序使用数据库，结构设计中应规定数据库的组织形式和内容
5.每一个输入的数据都应该有相应的输出

#### 关键算法
对于关键算法的选择和数据结构一样，也要指出原因是什么

#### 主要对象
对于面向对象的系统中，指出对象之间的责任并指出对象之间是如何相互作用的。包括对于排序层次、状态转换和对象一致性的描述。

#### 通用功能
有些功能是几乎所有软件都应该有的通用功能

##### 用户界面
应当在在结构设计中作出规定，把这部分直接模块化，这样新的代替旧的的时候，就不影响处理和输出的部分，而且要做好批处理接口，这样的话测试起来比较容易，这部分可以写一本书，但本书中未涉及。

##### 输入/输出
通过在不同的层次上进行错误检查，可以更有效地识别和处理数据问题，从而提高系统的健壮性和数据的准确性。

##### 内存管理

##### 字符串存储
在交互式系统中，字符串占用的内存，有时候可能是很大的，所以有些时候，我们要考虑字符串是应该放在代码、还是文件中，结构涉及应指明采用哪种方法

#### 错误处理
是当代CS中最棘手的问题，有90%代码是为了应付例外的错误编写的。
错误处理是纠正还是测试错误？如果是纠正，可以尝试从错误状态下回复，但总归要提醒用户。
错误是主动还是被动的?系统可以积极预防，比如检测用户的输入是否合法。
也要有一套处理错误信息的约定。
哪一个层次处理错误也要着手考虑，是在发现的地方处理，还是交给错误处理子程序处理，还是交给更高层次子程序处理。
需要分配是各自的模块自己检验自己的数据，还是有一个专门的模块负责，分工明确能效率更高。

#### 坚固性
指发现错误后，一个系统继续运行的能力，

##### 裕度设计
裕度：系统设计中故意加入的额外能力或资源，用于保证在出现意外情况或超出正常操作范围时系统仍能正常运行。
软件坚固是由最薄弱一环决定的，所以裕度级一定要弄清楚。

##### 断言

##### 容错性

##### 性能
包括速度和内存使用

#### 通用的设计质量设计准则
好的结构设计的特征包括对于模块的讨论，每个模块中隐含的信息，选用和不选用某方案的原因是什么。
一个以可变性为首要目标的结构设计可能与一个以性能为首
要目标的结构设计差之千里，虽然二者的功能可能是完全一样的。
结构设计的每一次变动都应该与总体设计概念相符。
设计者不能以牺牲某一部分为代价来重视另一部分。

### 3.4.2 检查表

#### 结构设计

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ckyizijbf1e1jj8ovu42.png)


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8f9jyjc7u0e7axrvtmjq.png)

## 3.5 选择编程语言先决条件

# 3.5.1语言描述

## 3.6 编程约定
低层次实现和结构设计的概念完整性一致。约定说明一定要详细，使得编程中无法对其改动。

## 3.7 应花在先决条件上的时间
大约应占20%-30%，不包括详细设计的时间，详细设计是创建活动的一部分。
如果是正式项目，需求不稳定，我们要跟需求分析员解决定义需求问题，让需求定义更适合项目需要。