重构代码

           
其实重构你可以从以下几个方面入手。

1、寻找代码的坏味。 见《你的代码需要重构吗？》

2、review自己的代码，如果觉得不好的地方就想想有没有更好的方法。可以拿出来和别人讨论，相信你一定有不一样的收获。

3、让别人review自己的代码。在团队开发中，难免其他队员开发的功能，会和你这边的模块有关联，当有队员来问你这个函数实现什么功能、这段代码的什么意思。

这有可能以下的原因：a、自己写的代码太烂！ b、队员的技术太菜，看不懂。 c、队员较懒，不想去看。

在给他解释时，你就要注意你们的对话，对你重构是有帮助的。

 

 队员：我不懂你这个变量是干什么的。

你就要想想，自己写变量命名不规范？

 

队员：你这段太长了，看得我头痛。

也是你的函数真的太长了，该修剪你的代码了，把这个大功能，分割为几个小功能。

 

 4、阅读别人的代码。你可以阅读一些比较经典的开源代码，这样你可以和很多人一起讨论。在阅读时，要认认真真的看，读懂它的框架，渗透理解它的各个细节。
 
 
 
 
 
 ?改善软件的性能、质量。
?使架构更加合理。
?使代码更容易被理解。
?提高软件的扩展性和可维护性。
?提高代码的重用率，通用性。
?提高软件的开发速度。
?更容易发现BUG。
?可以提高开发人员的开发水平。

 

由于重构直接关系到代码的质量，所以重构必须得到应有的重视。本文主要针对java重构，由于c#可能与java不一样，但我想思路应该差不多，可酌情看下.

      1.重构在项目中扮演什么角色？

      答：重构与代码功能编写同样重要，重构关心的是代码的质量，代码功能编写注重的是代码的功能实现，两者相辅相成。

      2.重构需要在什么时候进行,原则是什么？

      答：重构尽量不要占用功能编写的时间，即进度时间。原则就是不影响项目进度，有badsmell就可以重构了。但是有一点PL和pg需要商量清楚，该重构的还是需要抽出一定时间，当重构点比较多的时候，pg无法将功能再正常写下去，必须对有badsmell的一些代码进行处理，但这个处理时间不会很长，通常非关键重构2-4个小时足以，关键重构下面会讲到。

       3.什么是badsmell? 答: 拙劣设计的bad smells（坏味道、潜在问题、缺点）,通常是违反了设计原则才出现的。

       4.在重构这个问题上pg之间扮演什么角色？

      答：重构代码，人人有责。谁写的模块尽量让谁负责重构，这样比较效率。嗅出别人代码的smell来了，一定要提出来(重要），提醒写该模块的的pg,大家互相协调，把代码改好来，因为改好的架构对大家一起开发都有利，改好后知会下大家。

      5.如何理解关键重构和常用重构？

      答:关键重构涉及的是架构层面，而常用重构涉及的部分模块的重构，两者是总分的关系。关键重构在一次代码编写中一般只会出现一次或者两次，一般发生在项目的前三个模型（以第二个模型居多），重构的好坏直接影响全局代码质量。关键重构的产生，主要是因为第一个模型（或者第二个模型）通常是对最基本的功能进行实现，满足不了下一个模型后续的大量的代码模块的加入的需要，所以必须重构。关键重构所需要花的时间因工程和人而定，快的话半天，一般以不超过两天为宜。而常用重构主要是涉及代码小功能的修改，不会影响到全局。时间应控制在半天以内，如果只是抽出或者新增一些基本功能，1小时左右就可以了。

      6.什么架构重构最频繁？

     答：网络上没有的现成框架重构最频繁。对于c#,java web开发，网络上已经有了很多现成的框架，直接套用就可以了，重构只是小部分。而对于一些c/s模式，从无到有的重构会比较频繁，但频繁只会发生在前三个模型，一般在第二个模型后即使从无到有的模型也会趋于稳定。

      7.重构中需要注意什么？

      答:重构中主要需要注意任务的轻重，一定不要影响功能，并且较大的重构需要深思熟虑。改的时候快速干脆彻底.

 

为什么要有重构？

有些代码难以阅读的程序,难以修改；

在添加新行为时需要修改现有的代码,难以修改；

程序中带复杂条件逻辑的程序,难以修改；

诸多逻辑重复的程序,难以修改。