代码大全2

软件开发中的不同活动

构建活动

构建活动是软件开发的主要组成部分

构建活动是软件开发中的核心活动

把主要精力集中于构建活动,可以大大提高程序员的生产率

构建活动的产物-源代码-往往是对软件的唯一精确描述

构建活动是唯一一项确保会完成的工作

软件构建是软件开发的核心活动:构建活动是每个项目中唯一一项必不可少的工作

软件构建的主要活动包括:详细设计,编码,调试,集成,开发者测试(单元测试和集成测试)

构建活动也常被称作"编程"和"编码"

构建活动的质量对软件的质量有实质性的影响

最后,你对"如何进行构建"的理解程度,决定了你这名程序员的优秀程度-这就是本书其余部分的主题了

软件中的书法:写作代码

软件中的耕作法:培植系统

软件的牡蛎养殖观点:系统生长

软件构建:建造软件

应用软件技术:智慧工具箱

组合各个隐喻

隐喻是启示而不是算法.因此它们往往有一点随意

隐喻把软件开发过程与其他你熟悉的活动联系在一起,帮助你更好的理解

有些隐喻比其他一起隐喻更贴切

通过把软件的构建活动比作是房屋的建设过程,我们可以发现,仔细的准备是必要的,而大型项目和小型项目之间也是有差异的

通过把软件开发中的实践比作是智慧工具箱中的工具,我们又发现,每位程序员都有许多工具,但并不存在任何一个能适用于所有工作的工具,因地制宜地选择正确工具是成为能有效编程的程序员的关键

不同的隐喻彼此并不排斥,应当使用对你最有益处的某种隐喻组合.

前期准备适用于现代软件项目吗

准备不周全的诱因

关于开始构建之前要做前期准备的绝对有力且简明的论据

"老板就绪"测试

三种常见的软件项目种类

迭代开发对前期准备的影响

在序列化开发法和迭代式开发法之间做出选择

应该用客户的语言来书写,而且应该从客户的角度来描述问题

"未能定义问题"的处罚是,你浪费了大量时间去解决错误的问题

为什么要有正式的需求

稳定需求的神话

在构建期间处理需求变更

核对表

架构的典型组成部分

核对表

构建活动的准备工作的根本目标在于降低风险.要确认你的准备活动是在降低风险,而非增加风险

如何你想开发高质量的软件,软件开发过程必须由始至终关注质量.在项目初期关注质量,对产品质量的正面影响要比在项目末期关注质量的影响要大.

程序员的一部分工作是教育老板和合作者,告诉他们软件开发过程,包括在开始编程之前进行充分准备的重要性

你所从事的软件项目的类型对构建活动的前期准备有重大影响--许多项目应该是高度迭代式的,某些应该是序列式的.

如果没有明确的问题定义,那么你可能在构建期间解决错误的问题

如果没有做完良好的需求分析工作,你可能没能察觉待解决问题的重要细节.如何需求变更发生在构建之后的阶段,其代价是"在项目早期更改需求"的20至100倍.因此在开始编程之前,你要确认"需求"已经到位了.

理解项目的前期准备所采用的方法,并相应地选择构建方法.

语言描述

"深入一种语言去编程"的例子

核对表

要点

设计是一个险恶的问题

设计是个了无章法的过程（即使它能得出清爽的成果）

设计就是确定取舍和调整顺序的过程

设计受到诸多限制

设计是不确定的

设计是一个启发式过程

设计是自然而然形成的

软件的首要技术使命：管理复杂度

理想的设计特征

设计的层次

找出现实世界中的对象

形成一致的抽象

封装实现细节

当继承能简化设计时就继承

隐藏秘密（信息隐藏）

找出容易改变的区域

保持松散耦合

查阅常用的设计模式

其他的启发式方法

使用启发式方法的原则

迭代

分而治之

自上而下和自下而上的设计方法

建立实验性原型

合作设计

要做多少设计才够

记录你的设计成果

软件设计，一般性问题

软件设计理论

设计模式

广义上的设计

标准

设计实践

1、你已经做过多次迭代，并且从众多尝试结果中选择最佳的一种，而不是简单选择第一次尝试的结果吗？

2、你尝试用多种方案来分解系统，以确定最佳方案吗？

3、你同时用自下而上和自上而下的方法来解决设计问题吗？

4、为了解决某些特定的问题，你对系统中的风险部分或者不熟悉的部分创建过原型、写出数量最少的可抛弃的代码吗？

5、你的设计方案被其他人检查了吗（无论正式与否）？

6、你一直在展开设计，直到实施细节跃然纸上了吗？

7、你用某种适当的技术——比如说Wiki、电子邮件、挂图、数据照片、UML、CRC卡或者在代码写注释——来保留设计成果吗？


设计目标

1、你的设计是否充分地处理了由系统架构层定义出并且推迟确定的事项？

2、你的设计被划分为层次吗？

3、你对把这一程序分解成为子程序、包和类的方式感到满意吗？

4、你把对这个类分解成为子程序的方法感到满意吗？

5、类与类之间的交互关系是否已设计为最小化了？

6、类和子程序是否被害人设计为能够在其他的系统中重用？

7、程序是不是易于维护？

8、设计是否精简？设计出来的每一部分都绝对必要吗？

9、设计中是否采用了标准的技术？是否避免使用怪异且难以理解的元素？

10、整体而言，你的设计是否有助于最小化偶然性的和本质性的复杂吗？

软件的首要技术使命就是管理复杂度。以简单性作为努力目标的设计方案对此最有帮助

简单性可以通过两种方式来获取

设计是一种启发式的过程。固执于某一种单一方法会损害创新能力，从而损害你的程序

好的设计都是迭代的。你尝试设计的可能性越多，你的最终设计方案就会变得越好。

信息隐藏是个非常有价值的概念。通过询问“我应该隐藏些什么？”能够解决很多困难的设计问题。

很多有用有趣的、关于设计的信息存在于本书之外。这里所给出的观点知识对这些有价值资源的一点提示而已

含义

需要用到ATD的例子

使用ATD的益处

更多的ADT示例

在非面向对象的环境中用ADT处理多分数据实例

ADT和类

好的抽象

良好的封装

包含（“有一个·····”的关系）

继承（“是一个······”关系）

成员函数和数据成员

构造函数

创建类的合理原因

应该避免的类

抽象数据类型

 你是否把程序中的类都看做是抽象数据类型了？是否从这个角度评估它们的接口了？
抽象

类是否有一个中心目的？
类的命名是否恰当？其名字是否表达了其中心目的？
类的接口是否展现了一致的抽象？
类的接口是否是否能让人清楚明白地知道该如何用它？
类的接口是否足够抽象，使你能不必顾虑这费用如何实现其服务的？你能把类看做黑盒子吗？
类提供的服务是否足够完整，能让其他类无须动用其内部数据？
是否已从类中除去无关信息？
是否考虑过把类进一步分解为组件类？是否已尽可能将其分解？
在修改类时是否维护了其接口的完整性？
封装

是否把类的成员的可访问性降到最小？
是否避免暴露类中的数据成员？
在编程语言所许可的范围内，类是否已尽可能地对其它的类隐藏了自己的实现细节？
类是否避免对其使用者，包括其派生类会如何使用它做了假设？
类是否不依赖于其他类？它是松散耦合的吗？
继承

继承是否只用来建立“是一个/is a”的关系？也就是说，派生类是否遵循了LSP(Liskov替换原则)？
类的文档中是否记述了其继承策略?
派生类是否避免了“覆盖”不可覆盖的方法？
是否把公共的接口、数据和行为都放到了尽可能高的继承层次中了？
继承层次是否很浅？
基类中所有的数据成员是否都被定义为private而非protected的了？
跟实现相关的其他问题

类中是否只有大约七个或更少的数据成员？
是否把类直接或间接调用其他类的子程序的数量减到最少？
类是否只在绝对必要时才与其他的类相互协作？
是否在构造函数中初始化了所有的数据成员?
除非拥有经过测量的、创建浅层复本的理由，类是否都被设计为当作深层复本使用？
与语言相关的问题

你是否研究过所有编程语言里和类相关的各种特有问题？

理由

似乎过于简单而没必要写成子程序的操作

内聚

描述子程序所做的所有事情

避免使用无意义的、模糊或表述不清的动词

不要仅通过数字来形成不同的子程序名字

根据需要确定子程序名字的长度

给函数命名是要对返回值有所描述

给过程起名时使用语气强烈的动词加宾语的形式

准确使用对仗词

为常用操作确立命名规则

一些可以减少接口错误的指导原则

什么时候使用函数，什么时候使用过程

设置函数的返回值

预处理器

宏子程序在使用上的限制

内联子程序

大局事项
创建子程序的理由充分吗？
一个子程序中所有适于单独提出的部分是不是已经被提出到单独的子程序中了？
过程的名字中是否使用了强烈、清晰的“动词+宾语”词组？函数的名字是否描述其返回值？
子程序的名字是否描述了它所做的全部事情？
是否给常用的操作建立了命名规则？
子程序是否具有强烈的功能上的内聚性？
子程序之间是否有较松的耦合？
子程序的长度是否由其功能和逻辑自然决定，而非遵循任何人为的编码标准？
参数传递事宜
整体来看，子程序的参数表是否表现出一种具有整体性且一致的接口抽象？
子程序参数的排列顺序是否合理？是否与类似的子程序的参数排列顺序相符？
接口假定是否已在文档中说明？
子程序的参数个数是否没超过7个？
是否用到了每一个输入参数？
是否用到了每一个输出参数？
子程序是否避免了把输入参数用作工作变量？
如果子程序是一个函数，那么它是否在所有可能的情况下都能返回一个合法的值？

创建子程序最主要的目的是提高程序的可管理性，其次是提高可读性、可靠性、可修改性，以及节省代码空间；
把一些简单的操作写成独立的子程序也非常由价值；
子程序可以按照其内聚性分为很多类，而你应该让大多数子程序具有功能上的内聚性，这是最佳的一种内聚性。
子程序的名字是他的质量指示器。
只有在某个子程序的主要目的是返回其名字所描述的特定结果时，才应该使用函数。
细心的程序员会非常谨慎地使用宏，而且只在万不得已时才用。

通常有三种方法来处理进来垃圾的情况

建立自己的断言机制

使用断言的指导建议

可用的技术

健壮性与正确性

高层次设计对错误处理方式的影响

用异常通知程序的其他部分，发生了不可忽略的错误

只在真正例外的情况下才抛出异常

不能用异常来推卸责任

避免在构造函数和析构函数中抛出异常

在恰当的抽象层次抛出异常

在异常消息中加入关于导致异常发生的全部信息

避免使用空的catch语句

了解所用函数库可能抛出的异常

考虑创建一个集中的异常报告机制

把项目中对异常的使用标准化

考虑异常的替换方案

隔离

隔栏与断言的关系

不要自动地把产品版的限制强加于开发版之上

尽早引入辅助调试的代码

采用进攻时编程

计划移除调试辅助的代码

建议

一般事宜

子程序是否保护自己免遭有害输入数据的破坏？
你用断言来说明编程假定吗？其中包括了前条件和后条件吗？
断言是否只是用来说明从不应该发生的情况？
你是否在架构或高层设计中规定了一组特定的错误处理技术？
你是否在架构或高层设计中规定了是让错误处理更倾向于健壮性还是正确性？
你是否建立了隔栏来遏制错误可能造成的破坏？是否减少了其他需要关注错误处理的代码的数量？
代码中用到的辅助调试的代码了吗？
如果需要启用或禁用添加的辅助助手的话，是否无须大动干戈？
在防御式编程时引入的代码量是否适宜——既不过多，也不过少？
你在开发阶段是否采用了进攻式编程来使错误难以被忽视？
异常

你在项目中定义了一套标准化的异常处理方案吗？
是否考虑过异常之外的其他替代方案？
如果可能的话，是否在局部处理了错误而不是把它当成一个异常抛到外部？
代码中是否避免了在构造函数和析构函数中抛出异常？
所有的异常是否都与抛出它们的子程序处于同一个抽象层次上？
每个异常是否都包含了关于异常发生的所有背景信息？
代码中是否没有使用空的catch语句？（或者如果使用空的catch语句确实很合适，那么明确说明了吗？）
安全事宜

检查有害输入数据的代码是否也检查了故意的缓冲区溢出，SQL注入、HTML注入、整数溢出以及其他恶意输入数据？
是否检查了所有的错误返回码？
是否捕获了所有异常？
出错消息中是否避免出现有助于攻击者攻入系统所需的信息
安全、断言、异常

最终产品代码中对错误的处理方式要比“垃圾进，垃圾出”复杂的多。
防御式编程技术可以让错误更容易发现、更容易修改，并减少错误对产品代码的破坏。
断言可以帮助人尽早发现错误，尤其是在大型系统和高可靠性的系统中，以及快速变化的代码中。
关于如何处理错误输入的决策是一项关键的错误处理决策，也是一项关键的高层设计决策。
异常提供了一种与代码正常流程角度不同错误处理手段。如果留心使用异常，它可以称为程序员们知识工具箱中的一项有益补充，同时也应该在异常和其他错误处理手段之间进行权衡比较。
针对产品代码的限制并不适用于开发中的软件。你可以利用这一优势在开发中添加有助于更快地排查错误的代码。

创建一个类的步骤

创建子程序的步骤

设计子程序

编写子程序的代码

检查代码

收尾工作

根据需要重复上述步骤

测试先行开发

重构

契约式设计

东拼西凑

隐式声明

避免产生初始化错误的建议

使变量引用局部化

尽可能缩短变量的“存活”时间

减少作用域的一般原则

有关缩小变量作用域的说明

三种类型的数据和相应控制结构之间的关系

每个变量只用于单一用途

避免让代码具有隐含含义

确保使用了所有已声明的变量

最重要的命名注意事项

以问题为导向

最适当的名字长度

变量名对作用域的影响

变量命中的计算值限定词

变量名中的常用对仗词

为循环下标命名

为状态变量命名

为临时变量命名

为布尔变量命名

为枚举类型命名

为常量命名

为什么要有规则

何时采用命名规则

正式程度

与语言无关的命名规则的指导原则

与语言相关的命名规则的指导原则

混合语言编程的注意事项

命名规则示例

用户自定义类型缩写

语义前缀

标准前缀的优点

缩写的一般指导原则

语音缩写

有关缩写的评论

避免使用令人误解的名字或缩写

避免使用具有相似含义的名字

避免使用具有不同含义但却有相似名字的变量

避免使用发音近似的名字

避免在名字中使用数字

避免在名字中拼错单词

避免使用英语中常常拼错的单词

不要仅靠大小写来区分变量名

避免使用多种自然语言

避免使用标准类型、变量和子程序的名字

不要使用与变量含义完全无关的名字

避免在名字中包含易混淆的字符

建议

注意事项

指导原则

技巧

C 语言中的字符串

仔细运用

指导原则

如果你的语言里没有枚举类型

使用数组的一些建议

创建自己类型的原因

为什么创建自己的类型的示例使用 Pascal 和 Ada 写的

创建自定义数据类型的指导原则

一些使用结构体的理由

用来理解指针的范例

与全局数据有关的常见问题

使用全局数据的理由

只有万不得已时才使用全局变量

用访问器子程序来取代全局数据

如何降低使用全局数据的风险

组织语句的简单原则

使代码易于自上而下地阅读

把相关的语句组织在一起

简单 if-then 语句

if-then-else 语句串

为 case 选择最有效的排列顺序

使用 case 语句的诀窍

什么时候使用 while 循环

什么时候用带退出的循环

何时使用 for 循环

何时使用 foreach 循环

进入循环

处理好循环体

退出循环

检查端点

使用循环变量

循环应该有多长

一些 return 语句的指导原则

递归的例子

使用递归的技巧

反对 goto 的论点

支持 goto 的观点

关于 goto 的虚假辩论

错误处理和 goto

goto 和在 else 子句中的共享代码

goto 使用原则总结

使用表驱动法的两个问题

示例：一个月中的天数

示例：保险费率

例子：灵活的消息格式

构造查询键值

需要注意的一些细节

用 true 和 false 做布尔判断

简化复杂的表达式

编写肯定形式的布尔表达式

把括号对一起写出

用括号来把条件表达清楚

小心使用空语句

为空语句创建一个 DoNothing() 预处理宏或者内联函数

考虑如果换一个非空的循环体，是否会让代码更清晰

一些避免深层嵌套的方法

对减少嵌套层次的技术的总结

结构化编程的三个组成部分

复杂度的重要性

降低复杂度的一般原则

其他类型的复杂度

外在的质量特性

内在的质量特性

软件质量中的某些要素

开发过程

设置目标

缺陷检测率

找出缺陷的成本

修正缺陷的成本

改善质量以降低开发成本

协同构建是其他质量保证技术的补充

协同构建有利于传授公司文化以及编程专业知识

集体所有权适用于所有形式的协同构建

在构建前后都应保持协作

成功运用结对编程的关键

结对编程的好处

核对表

你期望详查能够带来什么结果

详查中的人员角色

详查的一般步骤

对详查进行细调

详查中的自尊心

详查和《代码大全》

详查总结

核对表

走查

代码的阅读

公开演示

协同构建技术的比较

单元测试

组建测试

集成测试

回归测试

系统测试

构建中测试

测试先行还是测试后行

开发者测试的局限性

不完整的测试

结构化的基础测试

数据流测试

等阶类划分

猜测错误

边界值分析

复合边界值

几类坏数据

几类好数据

采用容易手工检查的测试用例

哪些类包含最多的错误

错误的分类

不完善的构建过程引发错误所占的比例

你期望能发现多少错误

测试本身的错误

为测试各个类构造脚手架

Diff 工具

测试数据生成器

覆盖率监视器

数据记录器/日志记录器

符号调试器

系统干扰器

错误数据库

有计划的测试

重新测试（回归测试）

自动化测试

个人测试记录

调试在软件中所扮演的角色

调试效率的巨大差异

让你有所收获的缺陷

一种效率低下的调试方法

科学的调试方法

寻找缺陷的一些小建议

蛮力调试

语法错误

在动手之前先要理解问题

理解程序本身，而不仅仅是问题

验证对错误的分析

放松一下

保存最初的源代码

治本，而不是治标

修改代码时一定要有恰当的理由

一次只做一个改动

检查自己的改动

增加能暴露问题的单元测试

搜索类似的缺陷

心理取向如何导致调试时的盲目

“心理距离”在调试中的作用

源代码比较工具

编译器的警告消息

增强的语法检查和逻辑检查

执行性能剖测器

测试框架/脚手架

调试器

软件演化的哲学

重构的理由

核对表

拒绝重构的理由

数据级的重构

语句级的重构

子程序级重构

类实现的重构

类接口的重构

系统级重构

建议

不宜重构的情况

建议

质量特性和性能

性能和代码调整

Pareto 法则

一些无稽之谈

何时调整代码

编译器优化

常见的低效率之源

常见操作的相对效率

性能测量应当精确

在知道答案后停止判断

按照出现频率来调整判断顺序

相似逻辑结构之间的性能比较

用查询表替代复杂表达式

使用惰性求值

将判断外提

合并

展开

尽可能减少在循环内部做的工作

哨兵值

把最忙的循环放在最内层

削减强度

使用整型数而不是浮点数

数组维度尽可能少

尽可能减少数组引用

使用辅助索引

使用缓存机制

利用代数恒等式

削减运算强度

编译期初始化

小心系统函数

使用正确的常量类型

预先算出结果

删除公共子表达式

将子程序重写为内联

活动比例和项目规模

程序、产品、系统和系统产品

方法论和规模

设定标准的考虑事项

鼓励良好的编码实践的技术

什么是配置管理

需求变更和设计变更

软件代码变更

工具版本

机器配置

备份计划

核对表

评估的方法

评估构建的工作量

对进度的影响

评估与控制

如果你落后了该怎么办

程序员们怎么花费时间

性能差异与质量差异

信仰问题

物理环境

阶段式集成

增量集成

增量集成的益处

自顶向下集成

自底向上集成

三明治集成

风险导向的集成

功能导向的集成

T-型集成

集成开发环境（IDE）

针对多个文件的字符串查找和替换

diff 工具

Merge 工具

源代码美化工具

生成接口文档的工具

分析代码质量

重构源代码

Version Control

数据字典

产生目标码

调试

测试

代码调整

项目特有的工具

脚本

布局的极端情况

格式化的基本原理

人和计算机对程序的解读

好布局有什么用

把布局作为一种信仰

布局良好的目标

空白

括号

纯块结构

模仿纯块结构

使用 begin-end 对（花括号）指定块边界

行尾布局

哪种风格最优

格式化控制结构块的要点

其他考虑

语句长度

用空格使语句显得清楚

格式化续行

每行仅写一条语句

数据声明的布局

注释的缩进要与相应代码一致

每行注释用至少一个空行分开

用空行分隔子程序的各部分

将子程序参数按标准缩进

类接口的布局

类实现的布局

文件和程序布局

单元开发文件夹

详细设计文档

注释种类

高效注释

最佳注释量

注释单行

注释数据声明

注释控制结构

注释子程序

注释类、文件和程序

程序注释以书本为范例

软件开发标准

软件质量保证标准

管理标准

标准综述

在开发过程中建立自我意识

试验

阅读解决问题的有关方法

在行动之前做分析和计划

学习成功项目的开发经验

阅读文档

阅读其他书本期刊

同专业人士交往

向专业开发看齐

坚持

经验

编程狂人

将程序划分为不同层次的抽象

问题域的低层技术

软件先知

折中主义

试验