java新手的通病_Java 新手的通病

三：缺少良好的编程习惯

★随意地命名

有些新手写程序，当需要定义某个变量名(也可能是函数名、类名、包名等)时，随意地一敲键盘，名字就起好了......若干星期后，碰到某 bug，再来看自己写的代码时，心中暗自嘀咕：“这代码是我写的吗？咋都看不懂捏？”

所以我常跟新来的菜鸟说，命名不规范害死人啊！鉴于该问题相当普遍，我整理了几种典型的作为反面教材，具体如下：使用单字母命名变量；使用一些没太大意义的变量名(例如 s1、s2、s3)；对同一个业务概念使用不同的术语/缩写(容易让读代码的人神经分裂)；使用拼音命名(如果你团队中有港台人士或者老外，就惨了)。

★习惯于代码的 copy & paste

这是一个很普遍的问题。很多新手写代码的时候，如果发现要写的某个函数和前几天写的某个函数差不多，就把原来的那个函数贴过来，然后稍微改几下，心中还暗喜：“又快速搞定了一个功能”......

同学，如果你也喜欢这么干，可要注意了。这种做法是代码臭味(借用《重构 - 改善既有代码的设计》的提法)的主要来源，导致代码可维护性大大下降。当你将来需要增加功能或修改 bug 的时候，要同时改动多个地方，而那时你估计已经想不起来这砣代码有几个克隆了。

★Magic Number 满天飞

如果你没有听说过“Magic Number”，先看“这里”了解一下。

为了说明Magic Number的问题，咱找个例子来说事儿：假设有个业务逻辑中需要进行10秒的超时等待，你会怎么写这个sleep语句？我估计大部分人不外乎下面三种写法：

1、直接写上 sleep(10*1000); 了事

2、定义一个常量 TIMEOUT_XXX = 10*1000; 然后 sleep(TIMEOUT_XXX);

3、在配制文件中加入一个超时项，然后程序读取配制文件获得超时值，然后调用 sleep。(此处提到的“配置文件”是广义的，泛指各种可用于存储配置信息的机制，如：xml 文件、ini 文件、数据库 ...)

如果你的做法类似于写法1，你多半喜欢随手硬编码。硬编码不光缺乏可读性，而且具有和“代码拷贝粘贴”类似的代码臭味(可能会存在多个 Magic Number 克隆)，不利于日后维护。

至于写法2，比写法1稍好(至少可读性好了)。但是，将来一旦发生需求变更，要求在【运行时】调整超时间隔(甚至要求让用户来配制超时间隔)，则写法2的缺点立马暴露无遗。

★代码耦合度太大

每当说到 MVC 或者设计模式，几乎每个 Java 开发人员都能说得头头是道？但是说归说，真正写代码的时候，鲜有人写出的代码是层次清楚的。至于说到代码耦合分别由哪些情况引起？什么是正交的设计？(关于耦合与正交设计，我后面会专门讨论一下)能完全搞明白的人就更少了。

所以很多 Java 新手的代码耦合度大也就不足为奇了。我曾经抽查过试用期员工的代码，各种业务逻辑纠缠在一起，代码臭味都要熏死人。想重构都无从下手，只好让他推倒重写。

★被 GC 宠坏

由于 Java 在语言层面提供了内存的垃圾回收机制，程序员只管申请内存，不需要再关心释放的问题。因此很多新手养成了坏习惯，对于其它资源(比如数据库连接)也只申请不释放(有些人甚至天真地以为 JVM 会帮你搞定资源回收)。

还有些人虽然知道资源需要释放，但是常常忘记(比如写了打开数据库连接和相关代码，【即将】写关闭数据库连接时，突然有人叫你去吃中饭，回来后就把这茬给忘了)。

这个坏习惯会导致资源的泄露，而资源泄露往往比内存泄露更要命。如果你写的程序是长时间运行的(比如运行在 Web Server 上)，时间长了会由于资源耗尽而导致整个进程出问题。

四：异常处理使用不当

★空的 catch 语句块

犯这种错误的人比较少，一般发生在刚学会 Java 或者刚参加工作不久的人身上。

所谓“空 catch 语句块”就是在 catch 语句块中没有对异常作任何处理(比如记错误日志)，导致异常信息被丢弃/忽略。一旦程序不能正确运行，由于查不到任何 log 信息，只好从头看代码，靠肉眼找 bug。

★没有使用 finally

很多人在 catch 语句之后不使用 finally 语句。由于在 try 语句中可能会涉及资源的申请和释放。如果在资源申请之后、资源释放之前抛出异常，就会发生资源泄露。

(资源泄露的严重性，上面已经聊过了)

★笼统的 catch 语句块

有些人为了省事，只在自己模块的最外层代码包一个 try 语句块，然后 catch(Exception)。不管捕获到什么异常，都作统一 log 了事。这种做法比“空 catch 语句块”稍好，但由于不能对具体的异常进行具体处理，对一些可恢复的异常(下面会提到)，丧失了恢复的机会。而且也可能导致上述提到的资源泄露的问题。

★使用函数返回值进行错误处理

有些人放着 Java 的异常机制不用，而用函数返回值来表示成功/失败(比如：返回 true 表示成功、false 表示失败)，简直是“捧着金碗要饭”。个人感觉，从 C 转到 Java 的人比较容易有此毛病。这种做法会导致如下几个问题：

1. 返回值一般用整数值或布尔值表示，传递的信息过于简陋；

2. 一旦调用者忽略了错误返回码，就会导致和“空 catch 语句块”类似的问题；

2. 对同一个函数的多处调用，都需要对返回值进行重复判断，导致代码冗余(代码冗余的坏处，上面也已经聊过了)。

★不清楚“Checked Exception”和“Runtime Exception”的区别

这个现象比较普遍，俺发现很多2年以上 Java 工作经验的人尚未完全搞明白两者的区别。看来这个问题得详细说一下。

当初Java的设计者有意区分这两种异常，是别有深意的。其中“Checked Exception”用于表示可恢复的异常(也就是你必须检查的异常)；而“Runtime Exception”表示不可恢复的异常(也就是运行时异常，主要是程序 bug 和致命错误，你【不需要】检查)。不过这种做法引来了很多争议(包括很多 Java 大牛)，鉴于本帖子主要针对新手，以后再专门来聊这个争议的话题。

为了便于理解，下面我举一个例子来说明。假设你要写一个 Download 函数，根据传入的 URL(String 参数)返回对应网页的内容文本。这时候有两种情况你需要处理：

1. 如果传入的 URL 参数是 null，这表明该函数的调用者出 bug 了，而程序本身的 bug 是很难在运行时自我恢复的。这时候 Download 函数必须抛出 Runtime Exception。并且 Download 函数的调用者【不应该】尝试去处理这个异常，必须让它【尽早】暴露出来(比如让 JVM 自己终止运行)。

2. 如果传入的 URL 参数非 null，但是它包含的字符串不是一个合法的URL格式(可能由于用户输入错误导致)。这时候 Download 函数必须抛出 Checked Exception。并且 Download 函数的调用者必须捕获该异常并进行相应的处理(比如提示用户重新输入 URL)。

五：不了解 JVM

★关于基本类型和引用类型

很多新手不理解Java的基本类型和引用类型在本质上有什么区别。请看如下的问题：

◇这两种类型在内存存储上有什么区别？

◇这两种类型在性能上有什么区别？

◇这两种类型对于 GC 有什么区别？

关于前两个问题，请看之前的帖子“Java性能优化[1]：基本类型 vs 引用类型”。

★关于垃圾回收(Garbage Collection)

很多新手不理解 GC 的实现机制。请看如下的问题：

◇GC 是如何判断哪些对象已经失效？

◇GC 对性能会有哪些影响？

◇如何通过 JVM 的参数调优 GC 的性能？

关于 GC 的问题，可以参见之前的帖子“Java性能优化[3]：关于垃圾回收(GC)”。

★关于字符串

对于 Java 提供的 String 和 StringBuilder，想必很多人都知道：String 用于常量字符串，StringBuilder 用于可变字符串。那 Java 当初为什么要这样设计捏？为啥不用一个类来统一搞定捏？

★关于范型(Generic Programming)

从 JDK 1.5开始，Java 引入了一个重量级的语法：范型。不过捏，很多新手仅仅知道范型的皮毛，而对于很多本质的东东，不甚了解。

◇GP 是在编译时实现的还是在运行时实现的？为什么要这么实现？

◇GP 的类型擦除机制是咋回事？有啥优点/缺点？

◇使用范型容器(相对于传统容器)在性能上有啥影响？为什么？

★关于多线程

另外，多线程也是大部分 Java 新手的短板。所以俺最后再来提几个关于多线程的问题。

◇synchronized 关键字是怎么起作用滴？

◇synchronized 的颗粒度(或者说作用域)如何？是针对某个类还是针对某个类对象实例？

◇synchronized 对性能有没有影响？为什么？

◇volatile 关键字又是派啥用滴？啥时候需要用这个关键字捏？