由重构想到性能优化

重构这个词，现在已经被很多人理解为了，系统优化的代名词。或是推到重来的口头语。那在软件开发这个领域，重构官方定义是什么呢？

重构

        重构（Refactoring）就是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。

    在软件工程学里，重构代码一词通常是指在不改变代码的外部行为情况下而修改源代码，有时非正式地称为“清理干净”。在极限编程或其他敏捷方法学中，重构常常是软件开发循环的一部分: 开发者轮流增加新的测试和功能，并重构代码来增进内部的清晰性和一致性。自动化的单元测试保证了重构不至于让代码停止工作。

    重构既不修正错误，又不增加新的功能性。反而它是用于提高代码的可读性或者改变代码内部结构与设计，并且移除死代码，使其在将来更容易被维护。重构代码可以是结构层面抑或是语意层面，不同的重构手段施行时，可能是结构的调整或是语意的转换，但前提是不影响代码在转换前后的行为。特别是，在现有的程序的结构下，给一个程序增加一个新的行为可能会非常困难，因此开发人员可能先重构这部分代码，使加入新的行为变得容易。

    由以上定义看出，重构的前提是不得改变现有功能；重构的目的是改善软件质量，提高性能的；重构的结果就是使设计更加合理，提高软件的可维护性。而现实情况是，常常有人将修改系统缺陷，增加一些功能都笼统称为重构。甚至是颠覆完全不同的设计，不同的实现方式，也说是在重构。现实是复杂的，是细致入微的。只是说者无意，听者要有心了，特别是作为管理人员，听到某个开发人员在这里讨论什么什么要重构。我们这里也要入乡随俗。将重构定义拓宽一些。

         关于重构的话题，很深也很广泛。这里不深入。只是突然想到在做性能优化时，两者的联系与对比。虽然是不同的东西，但从实施步骤上讲，却也有些大致相反的做法。当然，关于这里的性能测试与重构的话题都是在旧有的系统基础之上讨论。

重构的层次：

如果一定要说重构有个层次关系，我们可以这么认为。

1、数据级的重构

改进变量和其他数据类型的使用

2、语句级的重构

改善单个语句的使用

3、子程序级重构

改善子程序一级的代码

4、类的重构

类一级代码的改善

5、系统级重构

整个系统级的改善

6、业务级的重构

牵涉需求改动，设计需要调整等。

          这个层次也是可作为我们重构的一个指导，当我们深入到一个原有系统，发现了一些问题（这些问题也就是软件质量众多属性中的某些）。比如，不易维护，特别是新人。或者存在性能问题，在某些情况下。这些都需要我们重新审视原有的系统实现，乃至原有的设计思想。发现这些问题，那就先会有个分析报告，就是不经测试，凭职业敏感度就能发现这里面的猫腻。发现了问题，接下来如果要动手解决这些问题。怎么去做呢？面对这么多的问题。

        不急。做事情总得有个目标才对。达到一个什么样的目标？比如，这句看上去就是个死代码，好吧，删除完事。但，现实啊，现实，尼玛，现实往往不是这么简单。所以，还是那句话，既然分析出了问题，那就要制定一个目标吧，不然，你动手干什么？

比如：这次重构，希望达成，改善可读性，提高维护性。这些性与性，妹的，再某些情况下冲突啊，所以，你还得知道这些性分别代表什么含义，并且知道你需要动手改动的影响了什么性，提高了什么性的同时有没有降低某些性。除了这些，更有一些限制，比如，时间，资源协调，等。站在这个角度看重构不是你想构就能构，更不是想重就能重的。

        那好吧，既然有了目标，那接下来当然是动手了；当然特别是对于新人，对业务不是很熟的人，可以一级一级来。上学的时候见过跨级的，那是人家能力强。重构也一样啊，也可以跨级啊。但一般人都是一级一级过来的。各位，看清楚了哦，这个时候，你想起了什么？？？？、

我？标题上面写的是有性能优化的这个有木有？有。好吧。

性能优化

         性能优化，啊，好高深啊，好装13啊。恩，你去搜搜，一把把，不，一箩筐箩筐的。那话题，铺满了整个网络。每天你都能听到，或是见到有人再和你或是再和别人讨论。“恩，这块不好，要优化” “这有点问题，太慢了，赶快去优化。” “妹的，页面卡死了，赶快去优化下” 。。。。。。。。。。

在这个行业，你听到的这些优化，这个词的频率不低于你之前见过脑白金的广告，或是你每天坐公交或是地铁，上面的广告轮番轰炸么？

是的，这个词已经潜移默化的钻入到你的脑子里了，不管你是在软件行业的哪个职业位置。多少与你相关。

         好吧，性能优化，我们这里说的就是这个行业，更进一步，互联网。这个东西，你不知道点你还真不好意思说是做这一行的。有些时候吧，你还得更深入才行。我们可以先大致划分一下，互联网行业的系统性能优化，有哪些个方面。

优化的方面

1、前端优化（什么JS，CSS，HTML，FLASH，IMAGE，在线存储等）

2、应用程序（业务）比如，你使用的语言，JAVA，C，C#等，多线程，文件处理等

3、中间件（WEB服务器，应用服务器）什么IIS，Apache，Tomcat，Jboss，Memcached等等

4、数据库（Sql，存储过程，事务，索引，分区，分表等等）Oracle，Mysql，Sqlserver

5、操作系统，WIN，Linux等内核参数调整等

6、网络（网络拓扑结构，使用的协议，HTTP，TCP/IP等）

其他：数据协议选择JSON,XML等，是否启用压缩，缓存啊，策略啊，等等。

         上面这些方面，除了第六点里部分属于不可控因素之外（路由选择算法，网络传输时间延迟，网络错误，等等），其他都是在可以在比较基准测试的范围内优化测试你的系统。

         对了，说了这么多，尼玛到底什么是性能啊。这个不知何谈优化啊。好吧，性能，就是-------------还是性能。哈，科普一下：

科技名词定义
中文名称：性能          英文名称：performance

定义：测量仪器仪表实现预期功能的能力的特性。

         好吧。这个就是这样定义的，我们要关注的是系统性能的两个方面：

1、有多快  （时间度量）（Latency）

2、有多少  （某类数据度量）（Throughput ）

如果你接触过性能测试方面的人员或是关注过性能测试方面的书籍，资料；那至少听过多少多少用户在线，系统TPS多少，等等这些最基本的话语吧。

其他什么更为详细的术语不再一一论述了。基本上，都是围绕上述两个方面定义的。只需要先记住上面两个方面。

        问题来了，现在让你接手一个项目，老板在在催，业务在那骂，市场在那等，什么鸟系统，完全是一个DEMO！！！！如果你需要最快的完成立即可见的结果，很有可能是发现系统存在的性能瓶颈。当然，你首先想的应该是熟悉了解业务，熟悉现有系统。接下来，你要重构么？还是要重新来过？你的着眼点在哪里？需要从哪个地方发力？这些除了经验之外，也更大程度上来自你的直觉。。。。。直觉？有没搞错？妹的，直觉是不靠谱的，又不是写诗。是的，需要直觉，再强调一遍，这里说的直觉是你首先对现状了解，对要达成的目标很清晰，同时，你拥有丰富的实战经验。这些都构成你在面对如何处理这些问题的直觉。

这个和你上面说的重构有什么鸟关系？

重构与性能优化关系

        重构与性能优化有毛关系？没有关系。这里讨论的是一个共性的话题。那就是首先要做的就是定位目标。目标是否清晰？是否可以具体操作实现？目标是个奢侈品了，变得。因为你发现，在你工作，生活中，一切都变得那么朦胧了，你对工作有目标么？对你的家庭有目标么？同时，越来越倾向于遇到某个问题，立马就是一堆逻辑上来了，开始找各种原因，抑或各种借口了。抑或是你有目标，只是这些目标是孙悟空身上的毛，你只抓住了毛目标。。。。。

       心伤了。妹的，做个事情有这么难么？

       好吧，扯的太远了。

       不管是重构也好，性能优化也好。第一步要做的就是

       1、定位一个清晰的目标。比如，增进可读性。CPU利用率达到60%。

       2、分析。很可能是分析某个语句，某段代码，抑或是系统架构。

       3、度量。各种规则的定义，比如，什么才算是可读性提供了，换行？每行限制？抑或是事务通过率。

       4、执行。什么也不说了，那就做吧。

       5、调整。还要及时啊。

       然后可以一圈一圈地由浅入深地跑啊跑。

      这些思路，可以很好指导我们做上述两种工作，重构，性能优化。

经验鸟谈

          如果还想说下去，那就是经验鸟谈了。如果要做重构，怎么来，虽然步骤有了。同样性能优化呢？当然，之前的系统不可能是傻子做的吧。妹的，至少人家还是程序猿抑或架构师啊，设计师啊。那就说说一般的情况。

          如果需要效果立杆见影。就是你所做的工作有目共睹。重构需要由小到大，有细增粗，由低级别上升到高级别。比如，你先搞数据，语句级别的，随着你对系统的理解，同时对业务系统的加深，慢慢上升啊。

         那性能优化呢？那就反着来呗。先从大处着手。比如所要说的几个面。既然网络部分，应该是没啥问题吧。那就看看操作系统，这些资源是否够用？

         然后是数据库，说到数据库，整个性能优化做下来，你会发现，这里面至少会占整个优化工作的60%到70%的点。当然这说的是一般情况，为什么呢？因为大多公司，大多的开发人员具备的数据库知识有限。也很少有公司请专职的DBA。所以开发出的代码，特别是与数据库交互部分。性能可想而知。再者说，数据库本身就是一门完整的学科。里面很是精深啊。想去浑水摸鱼，搞的会是一身泥。

        接下来才是那些个中间件参数的调整。你不要以为人家是傻子，是的。这些参数可能是已经被优化过的。那你还跳整啥玩意。

好吧。你知道你的系统是IO密集型的还是，计算密集型的？还是混合型的？你知道线程池模型不？L/F领导者与跟随者模式还是HS/HA半同步/半异步模式？ IO处理模型呢？内存分配，回收？文件系统？等等。

你只有了解这些才能调整啊。

        由大体到详细。算是对性能优化的一个大致操刀手法。