技术点分析

大驼峰命名法（UpperCamelCase）

小驼峰命名法（lowerCamelCase）

在蛇形命名法中，单词之间通过下划线“_”连接，比如“out_of_range”。

在蛇形命名法中，单词之间通过连字符“-”连接，比如“background-color”。

在匈牙利命名法中，标识符由一个或者多个小写字母开始，这些字母用来标识标识符的类型或者用途。标识符的剩余部分，可以采取其他形式的命名法，比如大驼峰命名法。

名字要能够准确、完整地表达出它代表的意义，可以见字知意，名副其实。

名字的可读性一定要优先考虑，一般需要注意以下几点。

区分不同行的不同级别的代码，可以使用缩进。缩进的目的是为了让我们更直观地看到缩进线，从而意识到代码之间的关系。

if (variable != null) {
    variable.doSomething();
}

基本的换行规范需要考虑以下三点。

/*
 * Copyright (c) 2018, FirstName LastName. All rights reserved.
 */

需要注意的是，如果文件有变更，记得更改版权信息的年份（比如上例中的 2018）。

这部分的作用，是用来生成独立的、不包含源代码的文档。 这些文档帮助使用者了解软件的功能和细节，主要面向的是该软件的使用者，而不是该软件的开发者。 比如 Java 的 API 规范的文档。

简化注释的风格

重写的方法，一定要加上 Override 注解。这个注解，既可以提醒代码的阅读者，也提醒代码的书写者，要谨慎对待该方法在父类定义的规范。

这类异常的命名以 Error 结尾，比如 OutOfMemoryError，NoSuchMethodError。这类异常，编译器编译时不检查，应用程序不需要处理，接口不需要声明，接口规范也不需要纪录；

这类异常的命名通常以 Exception 结尾，比如 IllegalArgumentException，NullPointerException。这类异常，编译器编译时不检查，接口不需要声明，但是应用程序可能需要处理，因此接口规范需要记录清楚；

除了运行时异常之外的其他的正常异常都是非运行时异常，比如 InterruptedException，GeneralSecurityException。和运行时异常一样，命名通常以 Exception 结尾。这类异常，编译器编译时会检查异常是否已经处理或者可以抛出，接口需要声明，应用程序需要处理，接口规范需要记录清楚。

异常类名（IllegalArgumentException， FileNotFoundException）

异常描述（“Invalid file path”）

异常堆栈（at sun.security.ssl.InputRecord.read(InputRecord.java:504)）

异常转换（Caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?）

1. 对于异常类名，我们要准确地选择异常类。

2. 对于异常描述，我们要清晰地描述异常信息。

3. 对于异常转换，我们要恰当地转换异常场景。

一个典型的规范，应该包含以下十个部分：

public/private/protected （访问控制限定词，制定访问权限）

abstract （抽象类或者抽象方法，具体实现由子类完成）

static （静态类、方法或者类属性）

final （定义不能被修改的类、方法或者类属性）

transient（定义不能被序列化的类属性）

volatile（定义使用主内存的变量）

default（声明缺省的方法）

synchronized（声明同步的方法）

native（声明本地的方法，也就是 Java 以外的语言实现的方法）

strictfp（声明使用精确浮点运算）

子主题

版权和许可声明代码块；

命名空间代码块；

外部依赖代码块

类的代码块；

类的属性与方法之间；

类的方法之间；

方法实现的信息块之间。

子主题

可以把一个组织的代码和另外一个组织的代码区隔开；

可以把一个项目的代码和另外一个项目的代码区隔开；

可以把一个模块的代码和另外一个模块的代码区隔开。

无论对于调用者，还是实现者来说，外部接口的使用都要有章可循，有规可依。

合约既然是我们协作的依靠，就一定要清晰可靠、容易遵循，不能有模棱两可的地方。如果接口规范描述不清，既误导调用者，也误导实现者。

接口规范主要用来描述接口的设计和功能，包括确认边界条件、指定参数范围以及描述极端状况。比如，参数错了会出什么错误？

需要注意的是，接口规范不是我们定义术语、交代概念、提供示例的地方。这些应该在其他文档中解决，比如我们下次要聊的面向最终用户的文档。

既然是合约，意味着调用者必须依赖于现有的规范。

接口的设计和规范的制定，一定要谨慎再谨慎，小心再小心，反复推敲，反复精简。一旦接口合约制定，公布，然后投入使用，就尽最大努力保持它的稳定，即使这个接口或者合约存在很多不足。

能不变更就不变更；必须的变更，一定要反复思量该怎么做才能把影响降到最低。

在不损害代码质量的前提下，效率可以节省我们的时间和成本。这种节省不仅仅停留在编码阶段，更体现在整个软件的生命周期里。

代码的质量在于它和预期规范的一致性。一致、简单、规范的代码易于测试。相反，复杂的代码会加大测试的难度，难以达到合适的测试覆盖率。另外，代码的复用也意味着质量的复用，所以代码的问题会随着它的复用成倍地叠加，提高了软件的使用或者维护成本。

代码的维护要求代码必须能够修改，增加新功能，修复已知的问题。如果代码结构的清晰、易于阅读理解，那么问题就容易排查和定位。

要想让更多的人参与，就需要一致的编码风格，恰当地使用文档。要方便他们阅读，便于解释。

自主模式（快系统）

控制模式（慢系统）

自主模式和控制模式的分工合作是高效的，损耗最小，效果最好。快速的、习惯性的决断交给勤快省力的自主模式，复杂的、意外的决断由耗时耗力的控制模式接管。

一份好的编码规范，刚开始接受会有些困难。我们甚至会找很多借口去拒绝。但是，一旦接受下来，我们就成功地改进了我们的识别模式。

模式识别的认知是一柄双刃剑，既是福音也是祸害。它可以帮助我们毫不费力地使用经验，但习惯一旦养成就很难改变，我们不愿意打破旧模式，去学习新模式和接受新技术。

对于既定模式的识别，是通过猜测进行的。对于每一个新场景，大脑立即会把它起始部分当作一个线索，然后通过拟合所有已知模式的起始部分，来预测模式的其余部分，猜测“言外之意”。

我们掌握的信息越少，就越有可能犯错误。

感官

短期

工作

长期记忆

我们在组织代码时，不要让短期记忆超载，要使用短小的信息快，方便阅读；要适当分割需要长期记忆和短期记忆的内容，比如接口规范和代码实现，帮助读者在工作记忆和长期记忆中组织和归档信息。

有时候，我们需要反复研读一段代码。如果这段代码可以在一个页面显示，我们的眼睛就很容易反复移动，寻找需要聚焦的目标。如果这段代码跨几个页面，阅读分析就要费力得多。

当我们阅读时，我们的眼睛习惯从左到右，从上到下移动，所以靠左的信息更容易被接受，而靠右的信息更容易被忽略。

当我们快速阅读或者浏览特定内容时（比如搜索特定变量），眼睛就会只喜欢上下移动，迅速跳过。聚焦区域小，眼睛倾向于上下移动，这就是报纸版面使用窄的版面分割，而不是整幅页面的原因之一。

在编码排版时，要清晰分块，保持布局明朗，限制每行的长度，这样可以方便眼睛的聚焦和浏览。

代码的性能和算法密切相关，但是更重要的是，我们必须从架构层面来考虑性能，选择适当的技术架构和合适的算法。

为了管理代码的性能，在一定程度上，我们需要很好地了解计算机的硬件、操作系统以及依赖库的基本运行原理和工作方式。一个好的架构师，一定会认真考虑、反复权衡性能要求。

好的性能可以把 Java 垃圾管理器的效率提高 50%，或者把列表的查询速度提高 50%

成熟的解决方案就在那儿，容易理解，也容易操作。只是，我们没有想到，没有看到，也没有用到这些解决方案。我们越不重视性能，这些知识离我们就越远。

一个好的程序员，他编写的代码一定兼顾正确和效率的。事实上，只有兼顾正确和效率，编程才有挑战性，实现起来才有成就感。如果丢弃其中一个指标，那么大多数任务都是小菜一碟。

我们可以问自己一些简单的问题。比如说，一万个用户会同时访问吗？如果一秒钟你需要处理一万个用户的请求，这就需要有百万用户、千万用户，甚至亿万用户的架构设计。

再比如说，会有一万个用户同时访问吗？也许系统没有一万个真实用户，但是可能会有一万个请求同时发起，这就是网络安全需要防范的网络攻击。系统保护的东西越重要，提供的服务越重要，就越要防范网络攻击。而防范网络攻击，只靠防火墙等边界防卫措施，是远远不够的，代码的质量才是网络安全防护的根本。

越早考虑性能问题，我们需要支付的成本就越小，带来的价值就越大。甚至是，和不考虑性能的方案相比，考虑性能的成本可能还要更小。

扩展硬件并不是总能够线性地提高系统的性能。出现性能问题，投入更多的设备，只是提高软件性能的一个特殊方法。而且，这不是一个廉价的方法。

没有高质量的工作作为基础，敏捷开发模式就会越走越艰难，越走越不敏捷，越走成本越高。而性能问题，是最重要的质量指标之一。

性能问题，有很多是架构性问题。一旦架构性问题出现，往往意味着代码要推倒重来，这可不是我们可以接受的快速迭代。当然，也有很多性能问题，是技术性细节，是变化性的问题。对于这些问题，使用快速迭代就是一个经济的方式。

采用性能工程思维，才能确保快速交付应用程序，而不用担心因为性能耽误进度。性能工程思维通过流程“左移”，把性能问题从一个一次性的测试行为，变成一个贯穿软件开发周期的持续性行为；从被动地接受问题审查，变成主动地管理质量。

在软件研发的每一步，每一个参与人员，都要考虑性能问题。整个过程要有计划，有组织，能测量，可控制。

采用性能工程思维，架构师知道他们设计的架构支持哪些性能的要求；开发工程师清楚应该使用的基本技术，而不是选择性地忽略掉性能问题；项目管理人员能够在开发软件过程中跟踪性能状态；性能测试专家有时间进行负载和压力测试，而不会遇到重大意外。实现性能要求的风险在流程早期得到确认和解决，这样就能节省时间和金钱，减轻在预算范围内按时交付的压力。

编写有效率的代码是我们的一项基本技能。我们千万不要忽视代码的性能要求。越早考虑性能问题，需要支付的成本就越小，带来的价值就越大，不要等到出现性能问题时，才去临时抱佛脚。另外，性能问题，大部分都是意识问题和见识问题。想得多了，见得多了，用得多了，技术就只是个选择的问题，不一定会增加我们的编码难度和成本。

根据任务的响应时间，应用程序性能指数定义了三个用户满意度的区间：

一致性原则是一个非常基本的产品设计原则，它同样也适用于性能的设计和体验。

完成同一件事情，尽量使用最少的计算机资源，特别是使用最少的内存、最少的 CPU 以及最少的网络带宽。

计算机资源的使用，也是一个策略。不同的计算场景，需要匹配不同的策略。只有这样，才能最大限度地发挥计算机的整体的计算能力，甚至整个互联网的计算能力。

不是所有的应用程序设计都能够用好更多的资源。这是我们在架构设计时，就需要认真考量的问题。

所以，我们要回归到最终用户。只有从最终用户的眼里看需求，才能够识别什么是最核心的需求，什么是衍生的需求，什么是无效的需求。这样，我们才能找到一个最小的子集，那就是现在就必须满足的需求。

首先就必须满足的需求，是优先级最高的、最重要的事情，这些事情要小而精致，是我们的时间、金钱、智力投入效率最高的地方，也是回报最丰厚的地方。我们要把这些事情做到让竞争对手望尘莫及的地步。

有一些需求很重要，但不是现在就必须做的。这就需要另外一个方法——迭代演进。第一次我们没有办法完成的事情，就放在第二次考虑。

迭代演进不仅仅需要考虑上一次没有完成的事情，还要考虑变化促生的新需求。所以，在这一步，还要像第一次一样，先找到最小的子集，也就是现在就必须满足的需求。然后，全力以赴地做好它。

这样迭代了几轮之后，一定有一些第一次看起来很重要的需求，再看反而不重要了，根本就不需要解决。

是不是迭代的时候，就可以考虑一些不重要的需求了呢？不，永远不要考虑不重要的需求。有时候，遏制住添加新功能、新接口的渴望，是一个困难的事情。我们需要学会放手，学会休假，以及拥有空闲时间。

我们真正要的不是简单直观的代码，而是轻松快速的行动。编写简单直观的代码只是我们为了快速行动而不得不采取的手段。有一个说法，如果面条代码能够让我们行动更快，我们就会写出面条代码，不管是刀削面还是担担面。

这些对代码整洁充满热情的工程师，会对整个团队产生积极的、至关重要的影响。这种影响，不仅仅关乎到工程进展的速度，还关系到工程的质量。真正能够使得产品获得成功，甚至扭转科技公司命运的，不是关键时刻能够救火的队员，而是从一开始就消除了火灾隐患的队员。

简单直观的解决方案，有一个很大的优点，就是容易理解，易于传达。事情越简单，理解的门槛越低，理解的人越多，传达越准确。一个需要多人参与的事情，如果大家都能够清晰地理解这件事情，这就成功了一半。

软件最大的风险，来源于软件的复杂性。软件的可用性，可靠性，甚至软件的性能，归根到底，都是软件的复杂性带来的副产品。越复杂的软件，我们越难以理解，越难以实现，越难以测量，越难以实施，越难以维护，越难以推广。如果我们能够使用简单直接的解决方案，很多棘手的软件问题都会大幅地得到缓解。

做小事的一个最直观的体现，就是代码的块要小，每个代码块都要简单直接、逻辑清晰。整洁的代码读起来像好散文，赏心悦目，不费力气。

为了保持代码块的简单，给代码分块的一个重要原则就是，一个代码块只做一件事情。

把代码块做小，背后隐含一个重要的假设：这些小代码块要容易组装。不能进一步组装的代码，如同废柴，没有一点儿价值。

而能够组装的代码，接口规范一定要清晰。越简单、越规范的代码块，越容易复用。这就是我们前面反复强调的编码规范。

大部分的优秀的程序员，是这两个风格某种程度的折中，早拆解、早验证，边拆解、边验证，就像剥洋葱一样。

拆解和验证，看起来很花时间。是的，这两件事情的确很耗费时间。但是，如果我们从整个软件的开发时间来看，这种方式也是最节省时间的。如果拆解和验证做得好，代码的逻辑就会很清晰，层次会很清楚，缺陷也少。

一个优秀的程序员，可能 80% 的时间是在设计、拆解和验证，只有 20% 的时间是在写代码。但是，拿出 20% 的时间写的代码，可能要比拿出 150% 时间写的代码，还要多，还要好。这个世界真的不是线性的。

我自己最常使用的工具，就是圆珠笔和空白纸。大部分问题，一页纸以内，都可以解决掉。当然，这中间的过程，可能需要一打甚至一包纸。

现在我最喜欢的工具有思维导图、时序图和问题清单。在拆解问题时，思维导图可以帮助我厘清思路，防止遗漏。时序图可以帮助我理解关键的用例，勾画清楚各个部件之间的联系。而问题清单，可以记录下要解决和已经解决的问题，帮助我记录状态、追踪进度。

一件事就是一件事，不是两件事，也不是三件事。

这件事是独立的。

这件事是完整的。

使用两个以上的线程；

关心共享资源的变化；

改变共享资源的行为。

使用单线程；

不关心共享资源的变化；

没有改变共享资源的行为。

子主题

// Create an HTTP client that prefers HTTP/2.
HttpClient httpClient = HttpClient.newBuilder()
               .version(Version.HTTP_2)
               .build();

// Create a HTTP request.
HttpRequest httpRequest = HttpRequest.newBuilder()
               .uri(URI.create("https://www.example.com/"))
               .build();

// Send the request and set the HTTP response handler
httpClient.sendAsync(httpRequest, BodyHandlers.ofString())
               .thenApply(HttpResponse::body)
               .thenAccept(System.out::println);  

// next action

// Open the connection
URL url = new URL("https://www.example.com/");
HttpsURLConnection urlc = (HttpsURLConnection)url.openConnection();

// Read the response
try (InputStream is = urlc.getInputStream()) {
    while (is.read() != -1) {    // read to EOF
        // dump the response
        // snipped
    }
}

// next action

指的是提高同一个处理单元处理更多负载的能力。比如，硬件上，增加服务器的硬盘、内存和 CPU；软件上，优化算法、程序和硬件的使用等。

规模垂直扩张是传统的提高负载的方式，方式方法都比较直观，效果也立竿见影。但是，规模垂直扩张成本很高，而且是非线性的。比如说，4 倍的 CPU 可能只提高 2 倍的负载，而 8 倍的 CPU 可能只提高 2.5 倍的负载。

另外，规模垂直扩张是有上限的，一台服务器的处理能力不是可以无限扩展的。还有，硬件的规模扩张，可能要更换机器，停止软件运行。这种规模扩张方式，不太适用于可用性要求高的产品。比如我们常用的微信，出现 5 分钟的停机都是天大的事故。

指的是通过增加更多的处理单元，来处理更多的负载。我们常见的例子，就是增加服务器。分布式系统、负载均衡、集群系统这些技术，提供的就是规模水平扩张的能力。

优秀的规模水平扩张技术，可以使用很多廉价的机器，提供大规模的计算能力。一般情况下，规模水平扩张的成本要低于规模垂直扩张。而且，如果其中一个节点出了问题，只要其他节点还在正常工作，整个系统也可以照常运转。如果想要添加一个新节点，系统也不需要停顿。规模水平扩张技术的这些特点，非常适用于高可用性系统。

和规模垂直扩张相比，规模水平扩张的方式方法并不直观。支持规模水平扩张的代码要能够协调地运行在不同的机器上，也就是说要支持分布式计算。很多代码，不是天生就支持分布式计算的，而且修改起来也不容易。

把无状态数据分离出来，单独提供无状态服务；

把最基本的服务状态封装起来，利用客户端的缓存，实现无状态服务；

小心使用服务状态，编码时要考虑服务状态的规模水平扩张能力。

代码规范方面的修改，可以大胆些。比如命名规范、代码整理，这些都动不了代码的逻辑，是安全的修改。

代码结构方面的修改，则要谨慎些，不要伤及代码的逻辑。比如把嵌套太多的循环拆分成多个方法，把几百行的代码，拆分成不同的方法，把相似的代码抽象成复用的方法，这些也是相对安全的修改。

代码逻辑方面的修改，要特别小心，除了有明显的问题，我们都尽量避免修改代码的逻辑。即使像上面例子中那样的微小的调用顺序的改变，都可能有意想不到的问题。

一致性的性能体验，是软件产品赢得竞争的关键指标。复杂的，反应迟钝的软件，很难赢得用户的尊敬。

通过降低软件的复杂度，提高软件的复用，提前考虑性能问题，可以降低软件研发成本，缩短软件开发周期。

经济的代码可以降低软件的复杂度，提高计算资源的使用效率，降低运营成本。

复杂的代码和性能低下的代码，更容易成为黑客攻击的目标。如果一个服务器，需要耗费很多资源才能处理一个请求，那么数量很少的模拟请求攻击，就可以导致服务器瘫痪。

避免需求膨胀的方式主要有两个，第一个是识别核心需求，我们要从用户的角度出发，知道什么是核心需求，什么是衍生需求，什么是无效需求。就像建火车站一样，能够满足乘客出行需求的就是好的设计方案，其他方面再细心认真，起到的也只是锦上添花的效果。那么有一些功能现在好像用不上，但又必须做，该怎么办呢？这就用到了第二个方法：迭代演进，有所主次。

避免过度设计和避免需求膨胀一样，我们需要时刻问自己，什么是现在就必须做的？什么是必须做的？

避免需求膨胀和过度设计，是编写经济代码最需要注意的根基性问题。

设计一个简单直观的接口，首先，我们要从问题开始。把问题逐步拆解成一个个已经完全穷尽的小问题，这就是我讲到的“相互独立，完全穷尽”原则。在拆解的过程中，软件的接口与接口之间的关系会自然而然地产生。

此外我们还要注意，一个接口只应该做一件事情，如果这个情况太理想化，就要想办法减少接口的依赖关系。

一定记住这个经过实践检验的理念：选择最简单，最直观的解决方案。

只要满足这三个条件中的一个，我们就不需要线程同步了：使用单线程；不关心共享资源的变化；没有改变共享资源的行为。

减少内存的使用主要有两个方法，第一个方法是减少实例的数量，第二个办法是减小实例的尺寸。

在减小实例尺寸这一模块，我们要尽量减少独占的空间，尽量使用共享的实例。不可变（immutable）的资源和禁止修改（unmodifiable）的资源，是两类理想的共享资源。5. 规避性能陷阱

我们要学会规避一些常见的性能陷阱，比如字符串的操作、内存泄露、未正确关闭的资源和遗漏的 hashCode 等。

另外，我们还顺便使用了一个基准测试工具 JMH，并通过它分析了一些性能陷阱。我们要有意识地使用一些性能测试工具，通过测试数据来认识、积累性能问题的最佳实践。

经济的代码需要跟得上产品的规模扩张。我们要理解规模垂直扩张和规模水平扩张这两种方式，特别是支持规模水平扩张。

状态数据是影响规模水平扩张能力的最重要的因素。分离无状态数据、提供无状态服务，减少有状态服务的规模，是提升规模水平扩张能力的最佳实践。

需求是真实的客户需求吗？

要解决的问题真实存在吗？

需求具有普遍的意义吗？

这个需求到底有多重要？

需求能不能分解、简化？

需求的最小要求是什么？

这个需求能不能在下一个版本再实现？

能使用现存的接口吗？

设计是不是简单、直观？

一个接口是不是只表示一件事情？

接口之间的依赖关系是不是明确？

接口的调用方式是不是方便、皮实？

接口的实现可以做到不可变吗？

接口是多线程安全的吗？

可以使用异步编程吗？

接口需不需要频繁地拷贝数据？

无状态数据和有状态数据需不需要分离？

有状态数据的处理是否支持规模水平扩张？

有没有可以重用的代码？

新的代码是不是可以重用？

有没有使用不必要的实例？

原始数据类的使用是否恰当？

集合的操作是不是多线程安全？

集合是不是可以禁止修改？

实例的尺寸还有改进的空间吗？

需要使用延迟分配方案吗？

线程同步是不是必须的？

线程同步的阻塞时间可以更短吗？

多状态同步会不会引起死锁？

是不是可以避免频繁的对象创建、销毁？

是不是可以减少内存的分配、拷贝和释放频率？

静态的集合是否会造成内存泄漏？

长时间的缓存能不能及时清理？

系统的资源能不能安全地释放？

依赖哈希值的集合，储存的对象有没有实现 hashCode() 和 equals() 方法？

hashCode() 的实现，会不会产生撞车的哈希值？

代码的清理，有没有变更代码的逻辑？

清楚调用接口的行为；

跨界的数据不可信任。

缺陷影响的深度，软件缺陷带来的问题的严重性：软件缺陷导致的最严重的问题是什么？

缺陷影响的广度，软件缺陷带来问题的可能性：软件缺陷导致问题出现的频率是多大？

第一优先级 （P1）： 高严重性、高可能性；

第二优先级 （P2）： 高严重性、中可能性；中严重性、高可能性；

第三优先级 （P3）： 高严重性、低可能性；中严重性、中可能性；低严重性、高可能性；

第四优先级 （P4）： 中严重性、低可能性；低严重性、中可能性；

第五优先级 （P5）： 低严重性、低可能性。

如果已经存在应对办法，优先等级可以下调；

如果软件缺陷引起广泛的公开关注，优先等级应该上调；

如果软件缺陷影响了重要的客户，优先等级应该上调；

如果软件缺陷影响了重要的商业运营，优先等级应该上调。

P1 的事情需要我们立即全力以赴、必须完成；P2 的事情需要我们协调资源，尽快完成；P3 的事情需要我们密切关注，尽量完成。

只有你能够修复的 bug，你可以记到自己名下，负责修复这些缺陷。

适合别人修复的 bug，如果还没有记到别人名下，你可以琢磨下谁是最合适的人选，然后和他商量，看他有没有时间，愿不愿意负责这个缺陷。当然，别人也可能会问你愿不愿意修复另外一些缺陷。

对私密性的影响（Confidentiality）

对完整性的影响（Integrity）

对可用性的影响（Availability）

对授权范围的影响（Authorization Scope）

安全攻击的路径（Attack Vector）

安全攻击的复杂度（Attack Complexity）

安全攻击需要的授权（Privileges Required）

安全攻击是否需要用户参与（User Interaction）

我们反复强调过，软件的安全漏洞常常会导致非常严重的后果，以及恶劣的影响。最糟糕的是，我们并不能总是预料到谁可以利用这些漏洞，以及由此带来的后果有多严重。所以处理安全漏洞的态度，一定要保守。

安全漏洞不能像普通的代码缺陷那样，可以公开细节、公开讨论。相反，安全漏洞的知情人员一定要控制在一个尽可能小的范围内，知道的人越少越好。如果安全漏洞和普通缺陷共享一个代码缺陷管理系统，一定要想办法做好安全漏洞信息的权限管理。

一旦发现一个安全漏洞，不管是来源于外部情报，还是内部发现，我们都要考虑最快地修复，不要等待，更不要拖沓。即使我们全力以赴地修复，在系统修复之前，安全攻击随时都有可能发生。我们能做的，就是尽最大努力，缩短这段时间。

所以，大部分的安全漏洞问题，都是属于 P1 级别的缺陷。有一小部分深度防御的安全问题，优先级可以是 P2。安全问题，不要使用 P3 及以下优先级。另外在所有的同级缺陷中，安全问题要优先考虑。

1. 个人敏感信息

2. 商业敏感信息

敏感信息的保护，需要恰当的管理，也需要适合的技术。

敏感信息指的是未经授权不得泄漏的信息。这个概念可以拆分为三部分：

是否需要授权是敏感信息和普通信息的最关键差异。不同的人有不同的权限，不同的操作需要不同的权限

针对敏感信息的操作，需要特殊的处理和特殊的技术。

要建立主动保护敏感信息的意识；

要识别系统的敏感信息，并且对敏感信息采取必要的、特殊的处理。

大部分的信息安全事故，是由软件代码的安全缺陷引起的。没有安全质量保证的代码，建立不起有效、可信的信息系统。信息系统的安全，主要依赖的不是信息安全技术专家，而是我们每一个编写代码的工程师。

直到真实的安全问题发生之前，我们都难以预料软件的安全漏洞到底有多大的破坏性。一个小小的安全漏洞，如果被攻击者抓住了时机，就可以瞬间摧毁多年的苦心经营和良好声誉，把公司推到舆论的风口浪尖，甚至使公司面临毁灭性的风险和挑战。

由于安全攻击技术的快速发展，安全编码涉及到的细节纷繁复杂，安全问题的解决甚至需要大规模、大范围的协作。编写安全的代码不是一件轻而易举的事情。但是，安全编码的规则和经验，却是可以学习和积累的。使用必要的安全管理工具，开展代码评审和交流，也可以加速我们的学习和积累，减少编写代码的安全漏洞。

使用不恰当的接口，是代码安全风险的主要来源之一。我们一定要了解、掌握每一个调用接口的行为规范，然后在接口规范许可的范围内使用它们。不要去猜测接口的行为方式，没有明文规定的行为，都是不可靠、不可信的行为。

跨界的数据面临两大问题：一个问题是数据发送是否可信？另一个问题是数据传递过程是否可靠？这两个有任何一个问题不能解决，跨界的数据都可能被攻击者利用。因此使用跨界的数据之前，要进行校验。

信息和资源，尤其是敏感数据，需经授权，方可使用。所授予的权力，能够让应用程序完成对应的任务就行，不要授予多余的权力。

减小、简化公开接口，缩小可以被攻击者利用的攻击界面。比如，设计更简单直观的公开接口，使用加密的数据传输通道，只对授权用户开放服务等等，这些措施，都可以减少安全攻击面。

使用纵深防御体系防范安全威胁。要提供深度的防御能力，不能仅仅依靠边界的安全。编写代码，要采用谨慎保守的原则，要解决疑似可能出现的安全问题，要校验来源不确定的数据，要记录不规范的行为，要提供安全的应急预案。

有没有安全更新的策略和落实计划？

有没有安全漏洞的保密共识和规范？

有没有安全缺陷的评估和管理办法？

软件是不是使用最新的安全修复版？

有没有定义、归类和保护敏感信息？

有没有部署多层次的安全防御体系？

安全防御能不能运转良好、及时反应？

不同的安全防御机制能不能独立运转？

系统管理、运营人员的授权是否恰当？

有没有风险管理的预案和长短期措施？

数值运算会不会溢出？

有没有检查数值的合理范围？

类、接口的设计，能不能不使用可变量？

一个类支持的是深拷贝还是浅拷贝？

一个接口的实现，有没有拷贝可变的传入参数？

一个接口的实现，可变的返回值有没有竞态危害？

接口的使用有没有严格遵守接口规范？

哪些信息是敏感信息？

谁有权限获取相应的敏感信息？

有没有定义敏感信息的授权方案？

授予的权限还能不能更少？

特权代码能不能更短小、更简单？

异常信息里有没有敏感信息？

应用日志里有没有敏感信息？

对象序列化有没有排除敏感信息？

高度敏感信息的存储有没有特殊处理？

敏感信息的使用有没有及时清零？

一个类，有没有真实的可扩展需求，能不能使用 final 修饰符？

一个变量，能不能对象构造时就完成赋值，能不能使用 final 修饰符？

一个方法，子类有没有重写的必要性，能不能使用 final 修饰符？

一个方法的返回值，能不能使用不可修改的变量？

类、方法、变量能不能使用 private 修饰符？

类库有没有使用模块化技术？

模块设计能不能分割内部实现和外部接口？

有没有定义清楚内部数据、外部数据的边界？

外部数据，有没有尽早地完成校验？

有没有标示清楚外部数据的校验点？

能不能跟踪未校验外部数据的传送路径？

有没有遗漏的未校验外部数据？

公开接口的输入，有没有考虑数据的有效性？

公开接口的可变化输出，接口内部行为有没有影响？

有没有完成无法识别来源的数据的校验？

能不能不使用序列化技术？

序列化的使用场景，有没有足够的安全保障？

软件还存在什么样风险？

有没有记录潜在的风险问题？

有没有消除潜在风险的长期预案？

有没有消除潜在风险的短期措施？

潜在的风险问题如果出现，能不能快速地诊断、定位、修复？