浅谈项目代码重构
浅谈项目代码重构
?
?????? 重构（Refactoring）就是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。
?
1 重构无法避免
重构无法避免的原因：
（1）一个大型软件，持续不变的是需求，需求的不断变化导致设计架构和代码的不断改变，重构无法避免。
（2）一个完美得可以预见未来任何变化的设计，或一个灵活得可以容纳任何扩展的设计是不存在的，导致重构无法避免。
（3）日新月异业务变更，导致功能的变化；每日业务数据量的增大，需要性能的提升；产品的深层次架构调整优化，需要革新原有代码。从而，导致设计的调整再所难免。
（4）一个IT团队中，不是所有的程序员开发风格都一样，这样就导致代码质量参差不齐，形成代码Bad Smell （代码坏味道Kent Beck），因此重构无法避免。
?
2 一个只会开发新功能代码，不会重构老功能代码的程序员，充其量只是一个合格的程序员。
?
?????? 一个大型项目难免会有人员更替，一个程序员，也就不可避免需要维护别人代码，接管别人代码。程序员如果只是单纯开发新功能，或者只偏向喜欢开发新功能。这样的程序员会固步自封，不利于个人成长。
??????
Martin Flower在《重构》中有一句经典的话："任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类容易理解的程序才是优秀的程序员。"
?
?????? 一个优秀的程序员，不仅能写出优秀的代码，更应当有能力重构别人的代码，并且敢于向质量差的代码挑战。
?
3 如果你不敢重构老功能代码，说明你对该功能还不够熟悉，对原设计思路还不清楚，或是你的技术能力还有待提升
??????
?????? 当你给某一个功能开发一个新功能点，不要急于主管臆断，片面猜测，急于开发，而应当多看，多思考，然后再把新?????? 功能代码和原代码糅合到一起，如果糅合后代码设计结构不够完美。那么需要重构原代码。
利用重构技术开发软件时会把时间分配给两种行为： [重构]与[添加新功能]，两种行为可交替进行，一会重构，一会添加新功能。
??????
?
4 项目开发过程中，风险无处不在，重构可能带来新问题，以及上线发布的问题和风险，但，这不是不重构的借口。
?
?????? 一个软件，只要改动代码，就会存在风险。重构的最终目标不是解决无法添加新功能的问题，而是提升软件本身的生命周期。
一、重构的好处：
（1）最大限度规避潜在长远风险；
（2）提升原有代码的可维护性、可阅读性(容易理解的代码很容易维护和增加新功能。代码首先是写给人看的，然后才是计算机看的)；
（3）增加该功能的可扩展性；
（4）延长整个系统项目的生命周期；
（5）学习别人的思想和学习别人的处理逻辑；
（6）有利于最快找到程序错误；（清晰的代码可以更方便的找到bug，重构可以写出更强健的代码）
（7）有利于提高编程速度，提高设计和编码水平；
?
?????? 二、重构的时间
（1）随时进行重构（重构是一种开发的习惯，需要培养自己随时随地重构）
（2）事不过三，代码重复不要超过三次（否则就要“抽”出来）
（3）添加功能时候并一一重构（添加新功能之前，分析并重构，从而更方便添加新功能）
（4）修补错误时（通过重构改善代码结构，能够帮助你找出BUG原因）
（5）code review时（有经验的开发人员Review代码时能够提出一些代码重构的建议）
?
? ??? 三、构筑自动化测试体系，最大限度降低重构风险
??? 如果你想进行重构，首先要拥有一个可靠的自动化测试环境。
(1)自动化测试代码的价值
??? 程序员代码编写只占小部分时间，大部分时间用于调试和查找BUG。自动化测试能够大幅减少由于重构代码及新增功能引人的BUG。
(2)XUnit测试框架
??? XUnit是一个单元测试框架，用于编写自动化测试用例。每次对代码重构后运行一遍测试用例，检查是否引入了Bug。
?
?????? 基于上述，因为怕重构带来问题，只是一种借口。
?
引述别人的话：【重构已经变成了我的另外一种生活方式，变成了我每天的面包与黄油，变成了我们整个团队的空气与水，以至于无须到书中寻找任何神谕。】
????????????????????????????????????????????????????????????????????????????????????????????????? ??????
?
附录：代码坏味道（Code Bad Smell）
重复的代码（这才是真正万恶之源，鄙视一切Ctrl+C/COPY）
过长函数，会导致责任不明确/难以切割/难以理解等一系列问题
过大类，职责不明确，垃圾滋生地
过长参数列（面向对象不是说说而已）
发散式变化，一个类会响应多种需求而被修改
散弹式修改（其实就是没有封装变化处，由于一个需求，多处需要被修改）
依赖情节（一个类对其他类过多的依赖）
数据泥团（如果数据有意义，就将结构数据变成对象）
type code，使用Class替代
switch，少用，考虑多态
过多平行的类，使用类继承并联起来
冗余类，去除它
夸夸其谈的未来性（过度设计）
临时值域，封装它
过度耦合的消息链，使用真正需要的函数和对象，而不要依赖于消息链
过度的deleate
过度使用其他类private值域
重复作用的类
不完美的类库，（类库老了，使用者也没办法阿）
纯数据类（类需要行为）
不纯粹的继承（拒绝父类的接口的类）
过多注释，（注释多了，就说明代码不清楚了，尤其是完全废弃的代码，就该直接删除）
