Java代码精进

一、代码命名规范

　　驼峰命名法（CamelCase）

　　Google 定义了以下的转换规则：

1. 从正常的表达形式开始，把短语转换成 ASCII 码，并且移除单引号。 例如，“Müller’s algorithm”转换为“Muellers algorithm”；

2. 如果上述结果含有其他标点符号，比如连字符，在该符号处，把这个结果切分成单词形式。 如果某个单词已经是驼峰形式，也相应地切分开来。 例如，“AdWords”切分成“ad words”，“non-current assets”切分成“non current assets”；

3. 将所有字母转换为小写字母，然后将每个单词的首字母大写，这样就得到了大驼峰式命名的形式； 如果第一个单词的首字母小写，就得到了小驼峰式命名的形式；

4. 将所有的单词连在一起，就是最后的标识符命名。

　　

　　Java 的命名规范

　　

 二十、简单和直观

　　大部分的优秀的程序员，早拆解、早验证，边拆解、边验证；这两件事情的确很耗费时间，从整个软件的开发时间来看，是最节省时间的。如果拆解和验证做得好，代码的逻辑就会很清晰，层次会很清楚，缺陷也少。

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

　　思维导图：在拆解问题时，思维导图帮助厘清思路，防止遗漏。

　　时序图：帮助理解关键的用例，勾画清楚各个部件之间的联系。

　　问题清单：记录下要解决和已经解决的问题，帮助记录状态、追踪进度。

二十九、编写经济代码

　　1、避免过度设计

　　    常问“什么是现在就必须做”？“什么是必须做的”？关注核心需求和核心问题。

　　2、选择简单直观

　　    设计一个简单直观的接口。把问题逐步拆解成一个个已经完全穷尽的小问题，“相互独立，完全穷尽”。

　　    一个接口应该做一件事情，如果这个情况不太理性化，尽量减少接口的依赖关系。

　　3、超越线程同步

　　    只要满足三者其一，就可不用线程同步：使用单线程；不关心共享资源的变化；没有改变共享资源的行为。

　　4、减少内存使用

　　    两个维度：一个是减少实例数量；另一个是减少实例的尺寸。

　　    减少实例数量：数据静态化的处理方式（比如枚举类）、单例模式、延迟分配技术。

　　    减少实例尺寸：减少独占空间，尽量使用共享实例。不可变（immutable）的资源和禁止修改(unmodifiable)的资源,是两类理想的共享资源。

　　5、避免性能陷阱

　　    比如字符串的操作、内存泄漏、未正确关闭资源和遗漏的hashCode等。

　　6、规模扩张能力

　　    分规模垂直扩张和规模水平扩张。

　　    规模水平扩张：状态数据。分类无状态数据、提供无状态服务、减少有状态的规模。

　　经济代码检查清单：

　　  需求评审

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

　　  设计评审　

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

　　代码评审

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