code guide

第1行 已经有了有参的构造函数，就没有了默认的无参构造函数，所以根本new不了，自然就没

第7行，class使用public修饰
嗯，如果是公开的类，就要有访问权限。 如果是包内部的类，使用缺省的访问权限也可以。

第8行， final变量应该初始化，且不能在构造函数中修改serverNames的引用 final变量，在构造函数中初始化就行。空构造函数，调用add会报错 空构造函数没有声明，使用了带参的构造函数，缺省的空构造函数就没有了。

第11行，Collections.unmodifiableList()生成的List无法修改 这个真不是，在构造函数中，可以初始化final变量。不过，也依赖于你最后怎么改的这个代码。 你要是第8行初始化了，这里就不能再次初始化了。

第15行，List没有指定泛型,遍历就不是SNIServerName 类型,应该是Object 嗯，我们应该在第8行声明时，就把类型这个问题解决掉。

第19行，if条件尽量使用括号,下面的return应该缩进 是的，缩进和括号，都要有!

第23行，for循环可能会空引用。循环之前需要判断serverNamers是否是null 对的，需要检查空值。

第24，25行，builder.append追加两次可以改成一次,节省运算 嗯，可以写成一行;写两行也没什么毛病。

代码规范清单：

代码是按照编码指南编写的吗? 
代码能够按照预期工作吗? 
文件是不是在合适的位置? 
支撑文档是不是充分?
代码是不是易于阅读、易于理解?
代码是不是易于测试和调试?
有没有充分的测试，覆盖关键的逻辑和负面清单?
名字是否遵守命名规范?
名字是不是拼写正确、简单易懂?
名字是不是有准确的意义?
代码的分块是否恰当?
代码的缩进是否清晰、整洁?
有没有代码超出了每行字数的限制?
代码的换行有没有引起混淆?
每一行代码是不是只有一个行为?
变量的声明是不是容易检索和识别?
变量的初始化有没有遗漏?
括号的使用是不是一致、清晰?
源代码的组织结构是不是一致?
版权信息的日期有没有变更成最近修改日期?
限定词的使用是不是遵循既定的顺序?
有没有注释掉的代码?
有没有执行不到的代码?
有没有可以复用的冗余代码?
复杂的表达式能不能拆解成简单的代码块?
代码有没有充分的注释?
注释是不是准确、必要、清晰?
不同类型的注释内容，注释的风格是不是统一?
有没有使用废弃的接口?
能不能替换掉废弃的接口?
不再推荐使用的接口，是否可以今早废弃?
继承的方法，有没有使用 Override 注解? 
有没有使用异常机制处理正常的业务逻辑? 
异常类的使用是不是准确? 
异常的描述是不是清晰? 
是不是需要转换异常的场景? 
转换异常场景，是不是需要保留原异常信息? 
有没有不应该被吞噬的异常? 
外部接口和内部实现有没有区分隔离? 
接口规范描述是不是准确、清晰?
接口规范有没有描述返回值? 
接口规范有没有描述运行时异常?
接口规范有没有描述检查型异常? 
接口规范有没有描述指定参数范围?
接口规范有没有描述边界条件? 
接口规范有没有描述极端状况? 
接口规范的起草或者变更有没有通过审阅? 
接口规范需不需要标明起始版本号? 
产品设计是不是方便用户使用? 
用户指南能不能快速上手? 用户指南的示例是不是可操作?
用户指南和软件代码是不是保持一致? 

 

时间复杂度有三个，一个是for语句，一个是hashMap查询，一个是hashMap的 put()。空间复杂度是hashMap占用的空间。

 

代码经济清单：

需求评审

 需求是真实的客户需求吗?
 要解决的问题真实存在吗?
 需求具有普遍的意义吗?
 这个需求到底有多重要?
 需求能不能分解、简化?
 需求的最小要求是什么?
 这个需求能不能在下一个版本再实现?

设计评审

 能使用现存的接口吗?
 设计是不是简单、直观?
 一个接口是不是只表示一件事情?
 接口之间的依赖关系是不是明确?
 接口的调用方式是不是方便、皮实?
 接口的实现可以做到不可变吗?
 接口是多线程安全的吗?
 可以使用异步编程吗?
 接口需不需要频繁地拷贝数据?
 无状态数据和有状态数据需不需要分离?
 有状态数据的处理是否支持规模水平扩张?

代码评审

 有没有可以重用的代码?
 新的代码是不是可以重用?
 有没有使用不必要的实例?
 原始数据类的使用是否恰当?
 集合的操作是不是多线程安全?
 集合是不是可以禁止修改?
 实例的尺寸还有改进的空间吗?
 需要使用延迟分配方案吗?
 线程同步是不是必须的?
 线程同步的阻塞时间可以更短吗?
 多状态同步会不会引起死锁?
 是不是可以避免频繁的对象创建、销毁? 
 是不是可以减少内存的分配、拷贝和释放频率? 
 静态的集合是否会造成内存泄漏?
 长时间的缓存能不能及时清理?
 系统的资源能不能安全地释放?
 依赖哈希值的集合，储存的对象有没有实现 hashCode() 和 equals() 方法? 
 hashCode() 的实现，会不会产生撞车的哈希值? 
 代码的清理，有没有变更代码的逻辑?

上面的代码中，verify() 方法和修改日期的线程间就存在竞争关系。如果日期修改在 verify() 实现 的验证和显示之间发生，显示的日期就不是验证有效的日期。这就会给人错误的信息，从而导致 错误的决策。这个问题就是 TOCTOU(time-of-check time-of-use)竞态危害的一种常见形 式。

 

1.数据 a 是一个外部输入数据，函数 A 使用数据 a 之前，需要校验它的合法性(检查点 1)。
2.数据 b 是一个外部输入数据，函数 A 使用数据 b 之前，完全校验了它的合法性(检查点2)。函数 A 内部调用的函数 B 在使用数据 b 时，就不再需要检查它的合法性了。
3.数据 c 是一个外部输入数据，函数 A 使用数据 c 之前，部分校验了它的合法性(检查点3)。函数 A 只能使用校验了合法性的部分数据。函数 A 内部调用的函数 B 在使用数据 c时，如果需要使用未被检验部分的数据，还要检查它的未被校验部分的合法性(检查点 4)。
4.数据 d 是一个外部输入数据，函数 A 使用数据 d 之前，部分校验了它的合法性(检查点5)。函数 A 内部调用的函数 B，没有使用该数据，但是把该数据传送给了函数 C。函数 C 在 使用数据 d 时，如果需要使用未被检验部分的数据，还要检查它的未被校验部分的合法性(检 查点 6)。
5.数据 e 和 f 是一个内部数据，函数 C 使用内部数据时，不需要校验它的合法性。
6.数据 g 是一个内部数据，由函数 A 产生，并且输出到外部。这时候，不需要检验数据 g 的合法性，但是需要防护输出数据的变化对内部函数 A 状态的影响(防护点 7)。

代码安全清单

安全管理

有没有安全更新的策略和落实计划?
有没有安全漏洞的保密共识和规范?
有没有安全缺陷的评估和管理办法?
软件是不是使用最新的安全修复版?
有没有定义、归类和保护敏感信息?
有没有部署多层次的安全防御体系? 
安全防御能不能运转良好、及时反应? 
不同的安全防御机制能不能独立运转? 
系统管理、运营人员的授权是否恰当? 
有没有风险管理的预案和长短期措施?

代码评审

数值运算会不会溢出?
有没有检查数值的合理范围? 
类、接口的设计，能不能不使用可变量? 
一个类支持的是深拷贝还是浅拷贝? 
一个接口的实现，有没有拷贝可变的传入参数? 
一个接口的实现，可变的返回值有没有竞态危害? 
接口的使用有没有严格遵守接口规范?
哪些信息是敏感信息?
谁有权限获取相应的敏感信息?
有没有定义敏感信息的授权方案?
授予的权限还能不能更少?
特权代码能不能更短小、更简单?
异常信息里有没有敏感信息?
应用日志里有没有敏感信息?
对象序列化有没有排除敏感信息? 
高度敏感信息的存储有没有特殊处理?
敏感信息的使用有没有及时清零? 
一个类，有没有真实的可扩展需求，能不能使用 final 修饰符? 
一个变量，能不能对象构造时就完成赋值，能不能使用 final 修饰符? 
一个方法，子类有没有重写的必要性，能不能使用 final 修饰符? 
一个集合形式的变量，是不是可以使用不可修改的集合? 
一个方法的返回值，能不能使用不可修改的变量? 
类、方法、变量能不能使用 private 修饰符? 
类库有没有使用模块化技术? 
模块设计能不能分割内部实现和外部接口? 
有没有定义清楚内部数据、外部数据的边界? 
外部数据，有没有尽早地完成校验? 
有没有标示清楚外部数据的校验点? 
能不能跟踪未校验外部数据的传送路径? 有没有遗漏的未校验外部数据? 
公开接口的输入，有没有考虑数据的有效性?
公开接口的可变化输出，接口内部行为有没有影响?
有没有完成无法识别来源的数据的校验?
能不能不使用序列化技术?
序列化的使用场景，有没有足够的安全保障?
软件还存在什么样风险?
有没有记录潜在的风险问题?
有没有消除潜在风险的长期预案?
有没有消除潜在风险的短期措施?
潜在的风险问题如果出现，能不能快速地诊断、定位、修复?