总览

质量

软件分为外在和内在两种质量特性。

外在特性指的是用户能够感受到的，

• 正确性

• 可用性

• 健壮性

• 可靠性

• …

质量的外在特性是用户关心的唯一软件特性。

程序员除了关心外在之外，还要关心它的内在特性：

• 可维护性

• 可读性

• 灵活性

• …..

让所有的特性都表现的尽善尽美绝无可能。根据一组互相竞争的目标找出一套解决方案，正是这种情况让软件成为一个真正的工程学科。

如何改善

一种强有力的方法是根据各种外在和内在特性，明确定义出软件质量的目标！程序员们会向明确的目标进发，必须有人告诉他们目标是什么，不同目标之间是有冲突的，软件通常不会在很多方面做的很好。

导演：我们要积极参与目标的制定，去思考，而不是等待别人告诉你目标！

组织本身必须向程序员们说明，质量应该是第一位的。

对变更进行控制。有效的管理变更是实现高质量的一个关键。

融合多种检错手段才能保证错误的检出率。单侧只能保证 30%，设计检查可以做到 55%，代码检查可以做到 60%，小规模 beta 测试 35%，大规模 beta 测试(1000 人以上)75%…等等，多种检错手段并行才能做到 95%以上的检错率。
不仅如此，还有根据错误的修复速度来看成本，比如代码检查可能只需要 3 个小时就能修复，到了测试阶段，耗费的额工时就变成了 15 个小时。

质量的普遍原理

绝大多数项目最大规模活动就是调试和修正那些无法正常工作的代码。调试和因此产生的重构可能要消耗 50%的时间。最明显的缩短开发周期的办法就是改善产品的质量。

类似于我们的几轮大重构，耗时很长。

我们应该吧投入到调试和重构的资源投入到前期的质量保证中，想明白了再动手。

性能

首先我们要区分好，很多时候用户对于性能的要求相比，更关注软件的外在特性。在花时间处理一个性能问题之前，想清楚你的确在解决一个确实需要解决的问题。

很多情况下我们的优化并不是优化代码能做到的，都是在软件的设计层面就已经错误了。或者有时，我们是可以修改需求来提高性能的。

80/20 法则对于性能也很适用，我们要衡量性能的各个部分，找到最需要关注的点。很多时候，只有 4%的代码造成了 50%的性能瓶颈。

在讨论性能的时候，没有“可能”这个词。很多时候性能问题都是违反直觉的。

程序的运行速度和正确性相比，正确性才是最重要的。

本章举了些例子来优化代码的运行速度，不过都是非常非常细节的点，实在没有想法的时候或者非常大规模计算的时候可以参考。优化真的对可读性是一个挑战。

软件工艺

布局与风格

好的布局凸显程序的逻辑结构。让好代码美观，差代码难看的技术，比让所有代码都好看的技术使用。

编程工作量的一小部分是在写让机器读的程序，大部分工作是写能让人看懂的程序。

高手是因为具备某种知识结构，有助于让他们记住特定种类。

空行可以将相关语句各自划分成段落，分开各子程序，突出注释部分。最佳比例为 8%~16%。

括号的好处在于你在写代码的不需要去思考执行顺序，你可以不用去思考，这就是好处。

自说明代码

注释不是为了重复代码，而是能在更高抽象上解释你想干什么。应该解释代码的意图。

我们要写业务注释而不是实现的注释。

如果注释困难，要么因为代码差劲，要么就是没有理解透彻代码。

只允许存在的 3 中注释：

• 代码无法表述的信息

• 目的性注释

• 概述性注释

当代码的可读性到了一定程度，注释的作用就受到了动摇。注释的出路是，可以变成概括的标题，毕竟人们读标题的速度更快。

不要注释糟糕的代码，应该重写。

个人性格

软件工程师研究其工具和原材料的本质的时候，会发现其实在研究人的智力，性格。

找一些一流的程序员评论你的代码。

力图理解编译器的所有警告信息。

在非关键的地方建立规范，而在关键的地方发挥你的创造性。

有效编程最重要的是思考，人思考的时候通常看上去不会很忙。

以新习惯代替老习惯比戒除老习惯更容易。

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 981909093@qq.com