目标
- 遵循类大小、方法大小和方法名称的最佳实践
- 了解重构的重要性
- 保持一致的编码风格和注释用法
- 使用内置日志功能
最佳编码实践
您现在已经学习了本学习路径的一半内容，已经掌握了足够多的 Java 语法来编写基本 Java 程序。在继续学习更高级的主题之前，目前是一个了解一些最佳编码实践的不错时机。阅读一些可帮助您编写更干净、更可维护的 Java 代码的必要建议。
保持类小巧
目前您已经创建了一些类。甚至为少量（根据真实 Java 类的标准）属性生成 getter/setter 对后，Person 类也有 150 行代码。对于此大小，Person 仍是一个小类。我们通常（而且不幸地）看到包含 50 或 100 个方法和数千行源代码（或更多）的类。一些类可能必须这么大，但它们很可能需要 重构。重构指的是更改现有代码的设计，而不更改它的结果。我推荐遵循以下最佳实践。
一般而言，类表示应用程序中的某个概念实体，类的大小应仅反映了执行该实体需要执行的操作的功能。它们应该高度专注于很好地执行少量的操作。
仅保留您需要的方法。如果您需要几个执行相同操作但接受不同参数的帮助器方法（比如 printAudit() 方法），这是一个不错的选择。但请确保将方法列表限制到您需要的水平，不要更多。
命名方法要小心
对于方法名称，一种不错的编码模式是 意图揭示性 方法名称模式。通过一个简单的示例会让您很容易理解此模式。只需看一眼，以下哪个方法名称更容易理解？
a()computeInterest()
答案应该很明显，但出于某种原因，程序员倾向于为方法（就这方面而言，还包括变量）提供简短的名称。当然，过长的名称可能不方便，但传达某个方法的用途的名称不需要过长。在编写大量代码 6 个月后，您可能已经不记得某个名为 compInt() 的方法的用途，但一个名为 computeInterest() 的方法的用途就会很明显，可能就是计算利息。
保持方法小巧
与小类一样，小方法更受欢迎，而且原因类似。我尝试遵循的一条原则是，将方法的大小限制为可在 一页 屏幕上看到。这种做法使应用程序类更容易维护。
跟随 Fowler 的足迹
（在我看来，而且不止我一个人这么看）业界最优秀的图书是 Martin Fowler 等编写的重构：改进现有代码的设计。这本书读起来很有趣。作者谈论了需要重构的 “代码味道”，详细介绍了修复它们的各种技术。
如果一个方法增长到超出一页，我就会重构它。Eclipse 拥有一组非常棒的重构工具。通常，一个长方法包含几个集中在一起的功能组。可将某个功能移动到另一个方法中（并相应地命名它），然后传入所需的参数。
将每个方法限制到单项工作。我发现，一个方法做好一件事所需的代码通常不超过 30 行。
重构和编写测试优先代码的能力是新程序员要学习的最重要技能。如果每个人都擅长这两种能力，业界将发生革命性变化。如果您擅长这两种能力，您最终会生成比许多同行更干净的的代码和功能更强的应用程序。
使用注释
请使用注释。长期关注您的人（或者甚至六个月后的您自己）会感谢您。您可能听过这样一句老话 如果精心编写的代码不言自明，那么谁还需要注释？ 我会给出两个原因说明为什么我认为这句老话是错误的：
- 大多数代码都没有精心编写。
- 尽管我们很努力，但我们编写的代码可能并不像我们认为的那么精美。
所以请注释您的代码。就这么简单。
采用某种一致的风格
编码风格是一种个人偏好，但我建议使用标准的 Java 括号语法：
public static void main(String[] args) {
}不要采用以下风格：
public static void main(String[] args)
{
}或这种风格：
public static void main(String[] args)
{
}为什么？因为它是标准的，所以您遇到的大部分代码（比如尚未编写，但可能付费维护的代码）很可能是以这种方式编写的。Eclipse 确实 允许您采用您喜欢的任何方式定义代码风格和格式化代码。但是，如果不熟悉 Java，您可能还没有形成自己的风格。所以我建议从一开始就采用 Java 标准。