浅谈关于代码重构与优化的问题浅谈关于代码重构与优化的问题尚学堂IT精英百家号关于代码重构与优化的问题，在做前端开发的时候也时常会遇见，在这段时间里面，可能是对自我要求比较高，不仅仅是项目能完成，功能正常使用这一层面上。还尽力的研究怎么写出优雅的代码，性能更好，维护性更强的代码，通俗一点就是重构。本文是我一个小记录，在此分享一下例子也简单，深入复杂的例子等以后有适合的实例再进行写作分享。首先需要明白什么是重构？其实，重构不是重写。重构大概的意思是在不影响项目的功能使用前提下，使用一系列的重构方式，改变项目的内部结构。提高项目内部的可读性，可维护性。无论是什么项目，都有一个从简单到复杂的一个迭代过程。在这个过程里面，在不影响项目的使用情况下，需要不断的对代码进行优化，保持或者增加代码的可读性，可维护性。这样一来，就可以避免在团队协作开发上需要大量的沟通，交流。才能加入项目的开发中。为什么需要重构？就像衣服脏了就洗，破了就补，不合穿就扔。尚学堂百战程序员陈老师指出随着业务需求的不断增加，变更，舍弃，项目的代码也难免会出现瑕疵，这就会影响代码的可读性，可维护性，甚至影响项目的性能。而重构的目的，就是为了解决这些瑕疵，保证代码质量和性能。但是前提是不能影响项目的使用。至于重构的原因，自己总结了一下，大概有以下几点：函数逻辑结构混乱，或因为没注释原因，连原代码写作者都很难理清当中的逻辑。函数无扩展性可言，遇到新的变化，不能灵活的处理。因为对象强耦合或者业务逻辑的原因，导致业务逻辑的代码巨大，维护的时候排查困难。重复代码太多，没有复用性。随着技术的发展，代码可能也需要使用新特性进行修改。随着学习的深入，对于以前的代码，是否有着更好的一个解决方案。因为代码的写法，虽然功能正常使用，但是性能消耗较多，需要换方案进行优化那么何时需要重构呢？在合适的时间，在合适的事情。在我的理解中，重构可以说是贯穿整一个项目的开发和维护周期，可以当作重构就是开发的一部分。通俗讲，在开发的任何时候，只要看到代码有别扭，激发了强迫症，就可以考虑重构了。只是，重构之前先参考下面几点。首先，重构是需要花时间去做的一件事。花的时间可能比之前的开发时间还要多。其次，重构是为了把代码优化，前提是不能影响项目的使用。最后，重构的难度大小不一，可能只是稍微改动，可能难度比之前开发还要难。基于上面的几点，需要大家去评估是否要进行重构。评估的指标，可以参考下面几点数量: 需要重构的代码是否过多。质量: 可读性，可维护性，代码逻辑复杂度，等问题，对代码的质量影响是否到了一个难以忍受的地步。时间: 是否有充裕的时间进行重构和测试。效果: 如果重构了代码，得到哪些改善，比如代码质量提高了，性能提升了，更好的支持后续功能等。本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。尚学堂IT精英百家号最近更新：简介:与广大编程爱好者分享新鲜的技术资讯作者最新文章相关文章浅谈代码重构：常用的重构方法有哪些
一、代码重构
软件开发中，代码质量与其整洁度成正比，干净的代码，既在质量上可靠，也为后期维护、升级奠定了良好基础。
实际开发中，我们经常听到&重构&二字。重构既不修正错误，又不增加新的功能性。反而它是用于提高代码的可读性或者改变代码内部结构与设计，并且移除死代码，使其在将来更容易被维护。
关于重构说明，如下图所示：
二、常用的重构方法
1.封装成员变量（Encapsulate Field）
将仅限于本类使用的变量重写成私有（private）成员变量，并提供访问方法（accessor method）。这种重构方式可以将与外部调用者无关的变量隐藏起来，减少代码的耦合性，并减少意外出错的概率。
class SomeClass {
public int memberA;
class SomeClass {
private int memberA;
public int getMemberA();
public void setMemberA(int a);
2.提取方法（Extract Method）
将大段代码中的一部分提取后，构成一个新方法。这种重构可以使整段程序的结构变得更清晰，从而增加可读性。这也对函数（Function）通用。
示例代码：
void Process(MyDataSet mds)
　// Step 1 ...
　int result = 0;
　if (mds.isReady)
　　int data1 = mds.param[0];
　　int data2 = mds.param[1];
　　// Preprocess...
　　result = data1 % data2;
　// Step 2...
void Process(MyDataSet mds)
　// Step 1 ...
　int result = 0;
　if (mds.isReady)
　　result = CalculateMDS(mds.param[0], mds.param[1]);
　// Step 2 ...
int CalculateMDS(int data1, int data2)
　　// Preprocess...
　　return data1 % data2;
3.一般化类型（Generalize Type）
将多个类/函数共用的类型抽象出可以公用的基类（base class），然后利用多态性追加每个类/函数需要的特殊函数。这种重构可以让结构更加清晰，同时可以增加代码的可维护性。
示例代码：
class Rectangle {
double Area(){
return w*h;
class Triangle {
double Area(){
return w*h/2;
class Polygon {
virtual double Area() = 0;
class Rectangle : public Polygon {
double Area(){
return w*h;
class Triangle : public Polygon {
double Area(){
return w*h/2;
4.函数归父（Pull Up）
将方法从子类移动到父类。
5.函数归子（Push Down）
将方法从父类移动到子类。
6.方法更名（Rename Method）
方法从父类移动到子类。
示例代码：
public double f(double m, double a);
public double calculateForce(double mass, double acceleration);浅谈软件重构
按照软件工程大神Martin Fowler的定义，重构就是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，进而提高软件的可扩展性和可维护性。这是重构的定义，简单来说就是不改变软件的功能，优化软件设计和代码，让软件更易于扩展和维护，当然也包括易于复用。Martin
Fowler等人总结出了一些常用的重构技术，将其写成了一本面向对象领域的经典著作——《重构：改善既有代码的设计》。
软件开发大师Robert C. Martin【Bob大叔】在《程序员的职业素养》（The Clean Coder）一书中也提到要勇于整理代码，通过整理代码让它们更易于理解，更易于修改，也更易于扩展。这样，代码的bug也会随之减少，不应该让代码劣化而视若不见。我觉得Bob大叔说的很好，这就是重构的意义。因此我常常跟学生们说，如果想成为一名合格的面向对象开发人员，设计模式和重构是你必须要学的两项基本技能。
重构和设计模式之间的关系很紧密，在Martin Fowler的《重构》一书中也提到了好几种使用设计模式来进行重构的手段。另外，还有一本书，名为《重构与模式》（Refactoring to Patterns，个人感觉翻译为“面向模式的重构”、“模式导向重构“或”重构到模式”更合适，），作者是Joshua
Kerievsky，这本书获得了第15届Jolt生产效率大奖。在这本书中提到了27种以模式为导向的重构，包括在设计中实现模式、趋向模式和去除模式。很客观地对一些设计模式进行了评价，既告诉我们如何通过设计模式来提高代码质量，又告诉我们如何在代码中去除一些不合理的模式应用。该书大部分重构方案还是实现和趋向模式的，例如将创建知识搬移到Factory、将聚集操作搬移到Visitor、用Strategy替换条件逻辑、用State替换状态改变条件语句等。每一种重构方案都提供了相应的实例，让你做一次重构的操练。当然，在读这本书之前，我建议大家还是先把设计模式好好学一下，否则里面有一些重构方案就没有办法理解了，毕竟这本书不是专门讲设计模式的。建议大家在学完设计模式之后再看这本书，既能够学到如何在实际项目中运用设计模式，又能学到如何在不同情况下选择设计模式，这本书也是我研究团队成员必读书籍之一。
在Bob大叔的《程序员的职业素养》一书中提到：当你发现修改软件不像你预想的那样简单时，你便应该改进设
计，使后续修改变简单。让软件保持固定不变是危险的，如果一直不重构代码，等到最后不得不重构时，将会发现代码已经很僵化。因此，要将重构变成一种习惯，每一次在阅读代码或者检入代码时都要考虑对代码进行改善与优化。如果你希望自己的代码灵活可变，那就应该时常修改它！我觉得这就是对重构时机最好的回答。如果你发现代码太僵硬，不易于扩展（你可以扩展一下试试），特别是那些在需求文档或者客户嘴里多次提到的需要改变的地方，一定要尽量灵活，当缺少这种灵活性时，你应该马上重构。个人觉得，衡量是否需要重构的标准就是现有设计方案或者代码是否不易扩展？复用性是否存在问题？将来是否会增加维护成本？如果存在这些问题，为了将来，应该重构，立即，马上！
很多人明知设计方案或者代码有问题，却不愿意去重构，这里面也存在很多原因，我觉得很多人之所有害怕重构，最大的问题在于担心重构之后会引入新的问题，难于测试。关于这一点，Bob大叔和我的想法不谋而合，尽量实现重构和测试的自动化。由于重构主要还是代码级的，对应的测试也主要是单元测试，单元测试的自动化程度在所有的测试中应该是最高的，因此只要我们有一套完整的测试用例，重构之后可以对应修改少许的测试代码就可以马上实施回归测试了。我个人觉得这个问题还是可以解决的，但是对于测试代码不完善或者根本没有测试代码的项目，实现起来恐怕会比较麻烦。因此，培养良好的开发习惯很重要，建议大家有空看看测试驱动开发(TDD)方面的资料，我相信对于所有一线开发人员还是挺有帮助的。
当然也有人觉得重构麻烦，不愿意重构，觉得功能都没有问题了，没有必要再进行重构，担心重构之后的功能会出现问题。有这种想法的人缺乏一种专业精神，我个人觉得要想成为一名专业的程序员，应该掌握一些常用的重构技巧并经常在项目开发中使用它们，可能开始会比较麻烦一点，但是当重构成为你开发技能一部分，就像写for、if语句一样很平常，你就不会觉得这是一种麻烦。在现在主流的IDE，例如Eclipse、Visual
Studio中，重构都已成为菜单的一部分，可见业界对于重构已达成共识，很多人把重构当做写注释一样，是一个很平常的提高代码质量的操作而已。
还有一个影响重构的因素是项目进度、成本等受到制约。明明知道要重构，但是项目工期很短，没有时间和精力来重构，各种赶工很常见，后果有时候也很严重，代码质量很差，在维护和二次开发时大量代码可能需要推倒重写。对于这个问题，只能尽量去跟客户或领导们交涉了，建议适当延长时间或者缩减功能。如果交涉失败确实很麻烦，只能想办法记录一下哪些地方需要重构，存在哪些问题，寄希望于有时间能够把这些地方重构一下或者在维护阶段再进行重构。
专家建议，将重构当做一种习惯，发现有需要时就应该考虑重构。
没有更多推荐了，
不良信息举报
举报内容：
浅谈软件重构
举报原因：
原文地址：
原因补充：
最多只允许输入30个字
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！&&& 寮}