代码精进之路

一行一个声明

局部变量需要时再声明

类属性要集中声明

声明时就初始化

尾随的花括号

靠紧的小括号

搜索优化的换行

识别子类的方法是不是重写方法

Override

重写方法可以不遵守父类方法的规范

第一件事情是，如果接口的设计存在不合理性，或者新方法取代了旧方法，
我们应该尽早地废弃该接口。

Deprecated

第二件事情是，如果我们在现有的代码中使用了废弃的接口，
要尽快转换、使用替换的方法。

SuppressWarnings

Java 提供了一个不推荐使用的注解，SuppressWarnings。这个注解告诉编译器，忽略特定的警告。
警告是非常有价值的信息，忽略警告永远不是一个最好的选项。

1. 重写的方法，总是使用

2. 过时的接口，尽早废弃

3. 废弃的接口，不要使用

异常状况的处理会让代码的效率变低。一个流畅的业务，它实现代码的执行路径，理想的状况就是没有任何异常状况发生。

非正常异常（Error）

可处理异常（Exception）

应用程序需要处理异常（CheckedException 和 RuntimeException），就需要我们在方法的规范描述文档中清楚地标记异常。
没有标记的异常，应用程序没有办法通过文档了解哪些异常需要处理、什么状况下会抛出异常以及该怎么处理这些异常。

异常类名（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. 命名空间（package）

3. 外部依赖（import）

1. 类的规范

2. 类的声明

3. 类的属性和方法

1. 类的属性

2. 构造方法

3. 工厂方法

4. 其他方法

1.方法的规范

2. 方法的声明

3. 方法的实现

1. 方法的简短介绍

2. 方法的详细介绍（可选项）

3. 规范的注意事项 (使用 apiNote 标签，可选项)

4. 实现方法的要求 (使用 implSpec 标签，可选项)

5. 实现的注意事项 (使用 implNote 标签，可选项)

6. 方法参数的描述

7. 返回值的描述

8. 抛出异常的描述：需要注意的是，抛出异常的描述部分，不仅要描述检查型异常，还要描述运行时异常

9. 参考接口索引（可选项）

10. 创始版本（可选项）

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

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

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

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

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

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

7. default（声明缺省的方法）

8. synchronized（声明同步的方法）

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

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

1. 版权和许可声明代码块

2. 命名空间代码块

3. 外部依赖代码块

4. 类的代码块

5. 类的属性与方法之间

6. 类的方法之间

7. 方法实现的信息块之间

提高协作效率的最高技巧不是提高沟通技巧，而是要减少沟通的数量，提高沟通的质量，尤其是要减少数量。

合约要成文

合约要清楚

合约要稳定

变更要谨慎

JavaDoc 就是一种顾及了多方利益的一种组织形式。它通过文档注释的形式，在接口声明的源代码定义和描述接口规范。
这种和源代码结合的方式，可以方便我们维护接口规范，也有利于保持接口规范和接口声明的一致性。

JavaDoc 工具可以把文档注释，转换为便于阅读为 HTML 文档。这样就方便规范的使用者阅读了。

1. 起草接口规范，或者起草提议的修订规范

2. 找相关领域的专家，审议草案，并根据评审意见，修改接口规范

3. 如果领域专家审议通过，提交兼容性和规范性审查程序；并根据审查意见，相应地修改接口规范

4. 兼容性和规范性审查通过，修改接口合约

5. 按照议定的接口规范，编写最终的实现的代码

1. 提高编码的效率

2. 提高编码的质量

3. 降低维护的成本

4. 扩大代码的影响

自主模式（快系统）

控制模式（慢系统）

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

第一点是可以减少代码错误

第二点是可以节省我思考的时间

第三点是可以节省代码阅读者的时间

好代码

坏代码

流程

参与人员

1. 代码写得又快又好，是“经济”的；代码写得快，但是错误多，不是一个“经济”的行为

2. 代码跑得又快又好，是“经济”的；代码跑得快，但是安全问题突出，不是一个“经济”的行为

3. 代码写得精简易懂，是“经济”的；代码写得精简，但是没人看得懂，不是一个“经济”的行为

优秀的代码需要具备三个特征： 经济、规范、安全

程序员间合作交流最重要的语言便是代码，换句话说，这就需要我们规范地编写代码，使用大家都接受的风格。
不规范的代码，我们可能节省了眼前的时间，但是测试、运营、维护阶段，就需要更多的时间。
而一旦问题出现，这些代码会重新返工，又回到我们手里，需要阅读、修改，再一次浪费我们自己的时间。
对于这些代码，每一点时间的付出，都意味着投入，意味着浪费，意味着我们损失了做更有意义事情的机会

第一个观点是好的程序员不会写坏的代码，要不然，就是他还不足够优秀
一个非常优秀的程序员，他主观上非常认真，能力又非常强，但他也会犯非常“低级”、“幼稚”的错误

第二个观点是同一个错误不能犯两次

第三个观点是一个人犯了错误并不可怕，怕的是不承认错误

程序猿

编译器

回归测试

代码评审

代码分析

需要能够熟练操控一门编程语言

程序员的存在不是为了写代码，而是为了解决现实问题，实现现实价值

优秀的程序员还要深入理解问题，懂得问题的最核心价值。
只有理解了问题，看到了解决问题的价值，我们才能够真正解决好问题

能够发现关键问题，是一个好程序员和优秀程序员的分水岭

可以从一个被动的做事情的程序员，升级为一个主动找事情的程序员

优秀的程序员，能够发现解决方案背后的妥协和风险。
所以，他可以预设风险防范措施，设置软件的适用边界

优秀的程序员，能够敏锐地观察到产品的关键问题，或者客户未被满足的需求。
所以，他可以推动产品持续地进步和演化

优秀的程序员，一定是懂得妥协，懂得选择，一步一步把事情沉静地朝前推动的人

我们写的每一行代码，都可能存在问题。有时候，我发现别人的代码的问题；有时候，别人发现我的代码的问题。
我们最后都会明白，要坦诚地面对别人的问题，也要坦然地面对自己的问题

优秀的程序员是他人可以依赖的伙伴

优秀的程序员，知道团队合作的重要性，是一个优秀的团队成员。
他在团队中能够快速学习、成长，变得越来越优秀，也能够帮助其他团队成员变得越来越优秀。

编程语言、花样工具、逻辑思维、解决问题这些“硬技能”可以决定我们的起点的话，
影响力、人际关系这些“软技能”通常影响着我们可以到达的高度。

优秀的程序员是高效的时间管理者。

优秀的程序员会更好地管理时间，或者提高效率，或者用好时间。

要坚持做需要做的事情。不需要的、不紧急的、价值不大的，我们可以暂时搁置起来。
一个人，能做的事情是有限的，能把最重要的事情最好，就已经很了不起了。

编码规范指的是针对特定编程语言约定的一系列规则，
通常包括文件组织、缩进、注释、声明、语句、空格、命名约定、编程实践、编程原则和最佳实践等。

一旦学会了编码规范，并且严格地遵守它们，可以让我们的工作更简单，更轻松，少犯错误。

复杂是代码质量的敌人。越复杂的代码，越容易出现问题。

在编码的时候，我们应该尽量使代码风格直观、逻辑简单、表述直接。

在代码制造的每一道关卡，规范执行得越早，问题解决得越早，整个流水线的效率也就越高。

在一个软件生命周期里，软件维护阶段花费了大约 80% 的成本

很多软件代码，其生命的旅程超越了它的创造者，超越了团队的界限，超越了组织的界限，甚至会进入我们难以预想的领域。

我们要尽早地使用编码规范，尽快地培养对代码风格的敏感度。
 良好的习惯越早形成，我们的生活越轻松。

我们要尽早地使用编码规范，尽快地培养对代码风格的敏感度。 
良好的习惯越早形成，我们的生活越轻松。

为标识符提供附加的信息，赋予标识符现实意义。
帮助我们理顺编码的逻辑，减少阅读和理解代码的工作量

使代码审核变得更有效率，专注于更重要的问题，而不是争论语法和命名规范这类小细节，提高开发效率

提高代码的清晰度、可读性以及美观程度

避免不同产品之间的命名冲突

驼峰命名法

蛇形命名法（snake_case）

串式命名法（kebab-case）

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

严格遵守命名规范

可读性优先

保持代码块的单一性，一个代码块只能有一个目标

注意代码块的完整性

代码块数量要适当。

合理利用空白空间，空白空间不仅区分代码块，还可以表示代码块之前的联系

如何利用空白空间

每行代码字符数的限制。一般情况下，每行代码不要超出 80 个字符

如果一行不足以容纳一个表达式，就需要换行

换行原则

整理代码有一个基本的思想，那就是把代码分割成大脑能够有效识别并记忆的信息块，
通过合理地使用空行、空格和缩进，把这些信息块清晰地呈现出来。
清晰的代码结构，可以帮助我们理顺编码的思路，提高编码的效率，减少编码的错误，提高代码的可读性，降低代码的维护成本。

因为注释不需要运行，所以没有常规的办法来测试它

注释难以维护，这是使用注释带来的最大的麻烦。

注释为我们提供了一个借口。使用注释来解释代码，是注释的本意。
但是，我们有时候会过度依赖解释，从而放弃了潜在的替代方案。

第一种类型，是记录源代码版权和授权的

第二种类型，是用来生成用户文档的

第三种类型，是用来解释源代码的

针对第一种注释类型，也就是固定的版权和授权信息，使用一般的星号注释符（/-/）

针对第二种注释类型，即生成用户文档的注释，使用 Javadoc 要求的格式，文档注释符（/-*/）。除了首行使用特殊的文档注释符（/）

针对第三种注释类型，也就是代码解释注释，只使用行注释符（//）

准确，错误的注释比没有注释更糟糕。

必要，多余的注释浪费阅读者的时间。

清晰，混乱的注释会把代码搞得更乱。