关于重构的几点感悟

一、 重构，意识比技能更重要

如果问一个程序员：代码为什么会变烂？他可能会找出无数种理由：
1、代码本来就烂，我只是加了一点东西；
2、时间压得太紧，根本没有时间把代码优化，功能实现出来就不错了；
3、系统已经上线了，不敢随便去改以前的代码，不出问题还好，改出问题了谁负责；
……
但是，这都是从外部找原因推卸责任，程序员应该从自身寻找原因。其实，代码变烂，罪魁祸首就是程序员自己。
很多时候，代码一步步变烂，就是因为程序员自己没有良好的意识，没有及时地重构，刚开始的代码还是挺好的，后来需求一步步变更，就开始不断地往里面加分支，慢慢就变烂了。所以建立强烈的重构意识才是最重要的，头脑里要建立这样的意识：一旦代码变烂了，就去重构，要写出高质量同时又优美易读的代码。
重构的技能每个人都可以学得会，但建立首先这样的意识才是更重要的。
至于写出好代码却不被上级知道和认可，也有相应的措施：推行代码质量可视化。在公司或部门内部，通过sonar等系统实时地公布各项目组和成员的代码总体质量，使所有人都能看到，这样就能让领导看到代码的改善，也促使更多的人建立写出好的代码的意识。

 

二、要简洁短小职责要单一

不要在一个方法或一个类中堆砌太多的代码，不管是方法还是类，都应该短小。过长的类或方法都是坏味道，它们会导致以下种种不快：
1、 代码难以理解，难以维护。比如一个方法中包含10个逻辑，这时程序员要修改其中一个逻辑，那么他不得不把这10个逻辑全部理解了才能动手修改，而且一大堆无关代码堆砌在一起，导致程序员修改代码时很容易出错。而如果分成了10个小方法，那么程序员就可以直接聚焦于要修改的那1个小方法就行了，修改也很容易。
2、 代码难以重用，导致重复代码。一个大方法中有一部分代码，在另一个地方有同样的处理，但是由于这部分代码身处这个大方法的泥潭中，所以无法重用，那么就只能拷贝一份了，这样就导致了重复代码，而重复代码的危害是不言而喻的。
……
另外，不管是方法还是类，都应该遵循“单一职责原则”，否则不同的职责杂糅在一起，同样导致以上的种种不快。所以，这句话很重要：函数的第一原则是短小，第二原则是短小，第三原则还是短小。

三、代码是给人看的，应该写人易读懂的代码

代码是给机器去运行的，但更是给人看的，要写出机器能运行的代码很容易，但要写出人易读懂的代码则更重要。建立这样的意识之后，往往就能写出非常整洁优美的代码。
要怎样写出人易读懂的代码呢？
首先，还是上一条所说的，要简洁短小，职责要单一，逻辑要清晰的区分开。不要把一大堆代码堆砌在一起，更不要把不同职责的代码堆砌在一起，那样都必然导致可读性下降。
然后，不要写过于长的复杂表达式，那样非常难以理解。可以把表达式进行分解，可以用解释变量（只起到解释的作用，就是为了让代码更加易读）。
还有，比如一个方法中包含10个重要的步骤，人要读懂它很难。那么可以把这个10个步骤提取到10个小方法中，然后给每个小方法起一个有意义的名字，让人顾名思义一目了然，然后在原方法中依次调用这10个方法，程序员一看便知道这个方法干了什么。
提到有意义的名字，需要强调的是，在代码中，不管是类、方法还是变量，一个好的名字都非常重要，起一个有意义的名字，让人一看就知道它是干什么的，比多少注释都有效。
有时为了达到代码整洁的目的，甚至可以牺牲一点点“性能”。这一点尤其令我印象深刻，故单独列出来作为第四个方面。

 

四、别为了一丁点“性能”就牺牲掉整洁

这里加了引号，是因为这里所说的“性能“，其实只是程序员的臆测。而这种臆测经常经常发生。
比如一个循环当中干了两件完全不相关的事情，使得不同职责的代码杂糅在一起，影响了易读性又不利于重用。其实应该分两次做，即使做了两次循环也没有关系，除非有实际的测试数据证明，这样做确实影响了程序的性能。但是其实大部分情况下，这并不会对性能造成影响。
应该时刻记住大师们的教诲：

• Ÿ 别为了一丁点"性能"就牺牲掉整洁
• Ÿ "干净整洁的代码往往运行起来更快，即使不快，也很容易让他变快，让干净的程序变快，比让快速的程序变正确来得容易。"
• Ÿ "过早的优化是一切罪恶的根源。"

由此可见，写出人易读懂的整洁的代码是多么重要。

以上几种意识的无论怎么强调都不为过的重要性,我也将牢固建立这些意识,写代码的时候时刻从这些意识出发,不断地持续地重构,只写干净整洁的代码。