* 废弃的注释；
* 冗余注释；
* 糟糕的注释；
* 注释掉的代码；-
唯一真正好的注释是你想办法不去写的注释：
-
不要有循规式注释，比如setter/getter注释；
-
不要添加日志式注释，比如修改时间等信息（git可以做的事情）；
-
注释一定是表达代码之外的东西，代码可以包含的内容，注释中一定不要出现；
-
如果有必要注释，请注释意图（why），而不要去注释实现（how)，大家都会看代码；
- 适当添加警示注释；
-
二、命名
-
尽可能使用标准命名方法，比如设计模式，通用学术名词等；
-
命名要找更有表现力的词：
-
使用更专业的词，比如不用get而使用fetch或者download；
-
避免空泛的名字，像tmp；
-
使用具体的名字来细致的描述事物；
-
给变量名带上重要的细节，比如加上单位ms等；
-
为作用域大的名字采用更长的名字，作用域小的使用短名字；
- 变量类型为布尔值表达加上is，has，can，should这样的词会更明确；
-
-
变量名称长短应该与其作用域对应；
-
别害怕长名称，长而具有描述性的名称比短而令人费解的名称好；
- 函数名称应该说明副作用，名称应该表达函数，变量或类的一切信息，请不要掩盖副作用，比如CreateAndReturnXXX；
三、方法
-
函数不应该有100行那么长，20行封顶最好：
-
if else while等控制语句其中代码块应该只有一行，也就是一个函数调用语句；
-
函数的锁进层次不应该多于两层；
- 一个函数只做一件事，一个函数不应该能抽象出另外一个函数；
-
-
某个公共函数调用的私有函数紧随其后；
-
最理想的参数是零参数，最长不要超过三个入参，尽量不要输出参数：
-
如果函数传入三个及以上参数最好将其抽象为类；
- 标识参数十分丑陋，向函数传入布尔值用于区分不同业务的做法很丑陋，应该拆分为多个函数；
-
-
别返回null值，抛出异常或者返回特殊对象，尽量避免NPE；
- 别传入null值；
四、异常与错误
-
抽离try catch包含的代码块，其中代码块抽象为一个函数；
-
抛出的每个异常，都应当提供足够的环境说明，已便判断错误的来源与处所；
- 不要将系统错误归咎于偶然事件；
五、并发
-
分离并发相关代码与其它代码；
-
严格限制对可能被共享的数据的访问；
-
避免使用一个共享对象的多个同步方法；
- 保持同步区域微小，尽可能少设计临界区；
六、单元测试
-
不要怕单元测试的方法名字太长或者繁琐，测试函数的名称就像注释；
-
不要追求太高的测试覆盖率，测试代码前面90%通常比后面10%花的时间少；
-
使用最简单的并且能够完整运用代码的测试输入；；
-
给测试函数取一个完整性的描述性名字，比如? Test _；
-
测试代码与生产代码一样重要；
-
如果测试代码不能保证整洁，你就会很快失去他们；
-
每个测试一个断言，单个测试中断言数量应该最小化也就是一个断言；
-
FIRST原则：
-
快速 Fast；
-
独立 Independent? 测试应该相互独立；
-
可重复 Repeatable? 测试应当在任何环境中重复通过；
-
自足验证 Self-Validating ? 测试应该有布尔值输出；
- 及时? Timely ? 最好的方式是TDD；
-
七、代码结构
-
代码行长度控制在100-120个字符；
-
可能用大多数为200行，最长500行的单个文件构造出色的系统；
-
关系密切的代码应该相互靠近：
-
变量声明应该靠近其使用位置；
-
若某个函数调用了另外一个，应该把他们放在一起，而且调用者应该放在被调用者上面；
- 自上向下展示函数调用依赖顺序；
-
-
应该把解释条件意图的函数抽离出来，尽可能将条件表达为肯定形式；
-
不要继承常量，比如接口中定义常量，不要使用继承欺骗编程语言的作用范围规则；
-
模块不应了解它所操作对象的内部情况；
-
DTO（Data Transfer Objects）是一个只有公共变量没有函数的类；
- 对象暴露行为，隐藏数据；
最后
2020年在匆匆忙忙慌慌乱乱中就这么度过了，我们迎来了新一年，互联网的发展如此之快，技术日新月异，更新迭代成为了这个时代的代名词，坚持下来的技术体系会越来越健壮，JVM作为如今是跳槽大厂必备的技能，如果你还没掌握，更别提之后更新的新技术了。
更多JVM面试整理：
原创文章，作者：3628473679，如若转载，请注明出处：https://blog.ytso.com/166531.html