JavaMail程序代码走查-优快云博客

代码走查，就是一群人一起，对别人写的代码进行分析。在算法上，在具体实现上，提出改进的意见。以使得程序更加健壮，更加有效率。今天对我写的一个Java Mail程序进行走查。自我感觉写得是有点丑，但是基本功能还是实现得很好的。经过走查，我收获很多。

下面是一些讨论中，可以改进的地方。

【1】多用面向对象的思想。以对象为处理的整体。

我的dao层，取得是诸如arrayList，int，这些单独的数据。这样子，没有把它封装起来成来一个对象，不利于处理。因为随着数据的增多，传单独的数据，不利于理解，也不利于操作。把它们封装成个对象，条理会清晰点。这里主要是考虑到以后扩展的需要。比如一个Bug，你现在可以简单地传一些title、id，但是如果需要传的数据量多时，就比不上传一个Bug对象了。

【2】在现有的Dao层上，再抽象出一层，用于包装逻辑操作，以及处理对象。

如果直接在Dao层上处理，比如封装对象等。也不好，因为这样就会嵌入过多的逻辑操作。与数据库操作的方法绑在一起，不符合功能独立的需求。所以，可以再进行一次的抽象，利用这些离散的数据来组合。这个可以参考公司的Utility，DBManager这些类。他们的作用就是封装底层数据库操作，获得一个完整的对象以供其他人使用。

【3】没有考虑到mail发送失败这种具体情况。

我之前的操作时，利用最后处理的action id，记为lastMailAction。如果一个action的id大于lastMailAction，说明它还未被读取过，于是为此bug发送邮件。处理完后，将lastMailAction设置为这些Bug中的最大值。

这样是方便操作。但是忽略了一个重要的因素：如果为此Bug发送邮件失败怎么办？通过一个lastMailAction，不足以表明哪些Bug成功发送，哪些失败。所以，从健壮性来讲，还是需要为Bug设置一个标记位，通过它来表示是否发送成功。这个是必要的。实际上，是会有失败的情况，不要太理想化。

【4】把经常变化的量，和不常变的量分开。

这点，与上面的理由类似。一开始，我将mail的host、userName、password、lastMailAction放在同一文件里。每次更新lastMailAction时，就要重新写这个文件。但是，host、userName、password这些一般是不变的，单独是lastMailAction变化而已。这样，如果在写lastMailAction时失败，影响到host这些怎么办。所以，不应该把他们放在一起。常变的与不常变的，应该分开。要考虑写失败这种实际情况。

【5】不要把一些配置写死到文件。

诸如host、userName、password这些，不应该写死到程序里。这样，当有变化时，自己修改程序代码，很麻烦，而且有可能会出错。应该把这些配置写到文件上。有个Properties对象，可以用于初始配置。

就是说，当有变化时，尽量可以用不修改代码的方式实现。修改代码不安全。

【6】把一些有共同处理流程的方法，抽象成一个函数。

这个理由也与上面相似。在我的程序里，有sendMail和sendMailReguraly函数。这两个都是发送邮件，一个是利用bug id发送，一个是利用bug 状态发送。但它们大部分的程序还是相同的，所以应该把它们放到一个函数里，利用标记位、参数来区别不同的操作。首先，可以省一些代码。其次，修改时，只需到一个地方修改即可，而不用在两个地方分别修改。这也是改动尽量少的代码的原则。（不要以为Copy，修改一个成为另一个函数是王道…）

【7】考虑最小消耗的方法。

循环一个arrayList时，我用的是while(!..isEmpty()){….remove(0)};的做法。但这样子，remove的操作，耗时大。如果使用一个指针i遍历数组的方式，不用改变它的结构，耗时相对会少一点。

同样的，对于多个String的合并，使用…+…+…+的方法也不好，因为，String就是一个对象，使用加号，把两个String加起，你要新建一个String，存储它们合并的结果。在利用这个String，与下一个String做加操作，又需一个新的String。所以，可以考虑使用StringBuffer，String..（忘了是什么哈…），这样处理会节省点。