代码走查，就是一群人一起，对别人写的代码进行分析。在算法上，在具体实现上，提出改进的意见。以使得程序更加健壮，更加有效率。今天对我写的一个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..（忘了是什么哈…），这样处理会节省点。

　　虽然说，算法方面的优化，会很显著，这些只是小修小补。不过这就涉及到态度的问题，做到，还是做的漂亮。这些就需要在细节上做功夫。

　　【8】统计出错信息

　　一般我们遇到error Exception时，都直接e.print..，这样也不好。因为我们是隔一段时间就运行这个程序，每人监控，所以，统计的信息应该输出到文件中。可以使用log4j这种方法，也是java提供的。

　　【9】有exception时，finally的使用

　　比如一些输入输出流，有exception时，最好在finally里将它close掉。这些小的方面，就是对于程序结构的了解。不要以为exception是不会出现的….

　　暂时这么多吧。多点考虑，多些思考，积累经验。不要像在学校那样写代码...