项目优化总结

最近一个多月算是比较忙的，但是具体忙了什么却不太好说清楚，主要是因为做的事比较繁琐还不太容易量化，说简单点，就是和组内其他几个同事一起接手一个算是开发好的项目，并进行一定的优化。
说到这个项目，就需要先说一下我们公司的一些情况。
我们公司算是众多外包公司的一员，公司内的人员架构可以按两种类别来说，一种说法是本公司员工和其他公司的员工；另一种说法是，外援和厂商。

这里的外援说白了就等于是人员外包，有什么项目做什么项目；而厂商相当于是项目外包，理论上说只对合同所指明的项目和项目期限负责。
之所以说这件事，是因为我们这次所接手的就是一个由厂商负责的项目，他们的项目合同到期，然后人突然全部撤走。
也是当项目交到我手上的时候，我才知道他们走了，连交接都没有，完全是一头雾水。
更有些郁闷的是，对于一个没有交接的项目，之前的人走了，而文档几乎没有，代码中解释相关的注释也少的可怜。
这无疑大大增加了工作难度，使得大量的时间也都变成了无用功。本来可能有个人一两句话就可以解释清，或者看一下注释就能明白许多的地方，现在却需要上下推敲摸索。
基本情况大概就是这样了，那么现在就可以进入正题，具体说一说这次优化过程中总结出来的一些经验。

不管是新手还是老手，不论是我身边的还是没见过的，可能大多数程序员都喜欢写新功能而不愿意修改优化别人的代码。
因为一说到优化就容易遇到几个问题，一是一眼见到大量的代码会有种无从下手的感觉；二是优化别人的代码就必须先看懂别人的代码，这就需要转变思维，进入别人的频道，尤其是根本不熟悉业务逻辑，还需要从代码中寻找的时候；第三个就是优化往往是枯燥无味的，远不如写新功能舒服。
那么根据这次的优化经历，我觉得如果再有人遇到优化的任务而感觉一时无从下手时，不放从以下几个方面开始：

1、规范代码，去除没有被用到的变量声明以及引用。像这种情况，eclipse配置好以后都会出现警告标志，会指明是“never used”。这种代码的问题很容易找到，也很容易修改，因此可以让自己感觉已经开始了优化工作，只要开始了，那么这个过程中就总能发现其他需要优化的地方。
我们这次就遇到了不少这种没有被使用的引用和声明：

这里是一个service接口，被引用了但是却没有被使用，我猜测多半是之前被人有用到，后来实现功能的过程中改了代码，导致这里不再使用了，但是却忘了一同删掉。

这里就是一个被导入的类但是没有被使用，情况多半是和上边的情况一样。

这里就是一个被声明了却始终没有被使用的变量，具体原因就不太好说。

2、规范代码，替换过时的和不推荐使用的方法。既然是过时和不被推荐的，自然有他的道理存在，除非是实在不知道怎么替换，否则我觉得都应该替换掉。这种情况和上面的情况稍有类似，也是eclipse编译的时候便会出现警告，很容易就识别出来，只不过改起来就要稍微复杂一些。

例如这段代码就同时出现了这两个问题，cal.getTnstance（）是不被推荐使用的，因为这个正确的被推荐的用法是用Calendar.getInstance(),也就是说它本身应该是属于类的静态方法。
而后边一个cal1.getTime().getHours()，就有点多次一举还费力不讨好的意味，因为这里完全可以用cal1.get(Calendar.HOUR)，不仅是被推荐的方法，还不用get两次。

3、上边两个简单的优化搞定以后，我们就可以进行第三步了，注释优化。我个人认为，注释优化可以分成三种，一种是加和改，一种是减。
说的具体明白点，加，就是对于那些负责具体功能和业务逻辑的类以及实体类的属性，如果没有注释我们应该加上注释，这样方便后续的维护，起码让人一眼就知道这个类、这个方法、这个属性是什么作用是什么意思。

改，就是对于明显不合理的注释进行修改，有的时候可能整个类被复制过来改个名字，这种情况就极有可能出现注释完全不搭调的情况；当然，也有可能是看起来注释了，实际上跟没注释没什么区别的注释。

减，就是对于那些被注释了的代码进行删除，当然了，这里我觉得也应该包括那些没有被删除的system.out.print。当然这种情况可能要根据实际情况，像我们这次遇到的完全是之前的人注释的，压根儿不知道干嘛的代码，多半是没人会再看的，我觉得就可以完全删除，省的占用空间还碍眼。

很显然，在这个过程中，删的时候相对简单，如果要加或者改，那么久需要了解相关的大概逻辑，也能进一步了解项目。

4、这一步可能是在上一步之后，也可能就和上一步同时进行，因为很可能就是在上一步的过程中发现的问题，就是代码逻辑上的优化。例如简单的判断，如下图

这里很明显的后边equals前边是固定的字符串，那就完全没有必要还做非空判断。而下图：

这里equals前的值不确定，很明显是应该做非空判断的，或者直接用上边的写法就好。
这个例子是简单的逻辑优化，还有更进一步，例如代码重用，方法提炼等，这就需要具体情况具体对待了。

5、经过上一步之后，整个代码的业务逻辑按理说我们应该已经了解的差不多了，也就不至于像一开始一样那么麻头了。而实际上这时候回头看看会发现，原来不知不觉中我们已经优化了很多东西了。那么这时候就可以进行一个对于性能来说至关重要的优化，但是相对来说也不太容易实施的步骤，那就是数据库优化。
这里的数据库优化我觉得也可以分为两步，一个是sql语句的优化，一个就是表结构、索引相关的优化。
sql语句的优化也有简单有难，比如我们这次，首先就发现有大量的sql语句使用了date_format、str_to_date、sysdate等函数，经测试发现这些函数是很影响性能的，而且完全可以不使用。
除此之外，还可以根据实际情况组合sql语句中条件的顺序，有的时候也会有不一样的性能。
而索引优化，这也需要结合业务逻辑，是大多数人一说到优化就先想到的东西，自然也是一个优化的方向。
那么相对于上边两个，接下来的优化表结构就有可能比较伤筋动骨了，很可能把几个表整理成一个，也可能改动字段。
这个时候不仅要动数据库，也要同时动sql和代码，工作量就比较大，但是却不可否认也是一个优化的方向，我们这次其中一个模块就把之前四五张表整合成了一个。
那么还可能有一个问题，这个问题就不具备普遍性，那就是可能数据库中有完全无用的表。我们这一次经过整理后就发现，数据库中原来有41张表，结果我们只用到了19张，还有22张都不不知道干嘛的，最终被我们删掉。

好了，这一次的总结差不多就这些了，我想以后再遇到这样的事情时可能就更容易下手了，也洗完功能对其他人有所帮助。