郫县网站建设,网页微博如何退出登录,wordpress动静分离oss代码,国外wordpress主机目录
1.引言
2.重构的目的:为什么重构(why)
3.重构的对象:到底重构什么(what)
4.重构的时机:什么时候重构(when)
5.重构的方法:应该如何重构(how)
6.思考题 1.引言 一些软件工程师对为什么要重构(why)、到底重构什么(what)、什么时候重构(when)应该如何重构(how)等问题的…目录
1.引言
2.重构的目的:为什么重构(why)
3.重构的对象:到底重构什么(what)
4.重构的时机:什么时候重构(when)
5.重构的方法:应该如何重构(how)
6.思考题 1.引言 一些软件工程师对为什么要重构(why)、到底重构什么(what)、什么时候重构(when)应该如何重构(how)等问题的理解不深对重构没有系统行认识、在面对质量不佳的代码时这些软件工程师没有足够的重构技巧不能系统地进行重构、为了让读者对有清晰的认识我们先来了解一下重构的目的、对象、时机和方法。
2.重构的目的:为什么重构(why) 软件设计专家 Martin Fowler 给出的重构的定义:“重构是一种对软件内部结构的改善目的是在不改变软件对外部的可见行为的情况下使其更易理解修改成本更低。”在这个定义描述中我们需要关注一点:“重构不改变对外部的可见行为”。注意这里提到的“外部”是相对而言的。如果我们重构的是函数那么函数的定义就是对外部的可见行为;如果我们重构的是一个类库那么类库暴露的 API就是对外部的可见行为。在了解了重构的定义之后我们探讨一下为什么要进行代码重构。 首先重构是保证代码质量的有效手段可有效避免代码质量下滑。随着技术的更新、需求的变化和人员的流动代码质量可能存在下降的情况。如果此时没有人为代码的质量负责那么代码就会变得越来越混乱。当代码混乱到一定程度之后项目的维护成本高于重新开发-套新代码的成本此时再去重构就不现实了。 其次高质量的代码不是设计出来的而是迭代出来的。我们无法完全预测未来的需求也没有足够的精力和资源提前实现“未来可能需要实现的需求”这就意味着随着产品的选代、项目的推进和系统的演进重构代码是不可避免的。 最后重构是避免过度设计的有效手段可以兜底暂时不完善的设计。在代码的维护过程中当遇到问题时我们再对代码进行重构这样能有效避免前期的过度设计。 实际上重构对软件工程师的技术成长也有重要意义。重构是设计原则和设计模式以及代码规范等理论知识的重要应用场景。重构的过程能够锻炼我们熟练使用这些理论知识的能力。除此之外重构能力是衡量软件工程师编码能力的重要手段。作者听过这样一句话:“初级软件工程师开发代码高级软件工程师设计代码资深软件工程师重构代码”这句话的意思是:初级软件工程师在已有代码框架下修改、添加功能代码;高级软件工程师从零开始设计代码结构搭建代码框架;而资深软件工程师为代码质量负责能够及时发现代码中存在的间题有针对性地对代码进行重构时刻保证代码质量处于可控状态。
3.重构的对象:到底重构什么(what) 根据重构的规模我们可以将重构笼统地分为大规模高层次重构(以下简称“大型面构”)和小规模低层次重构(以下简称”小型重构”)。 大型重构是指对顶层代码设计的重构包括对系统、模块、代码结构、类之间关系等的重构大型重构的手段包括分层、模块化、解耦和抽象可复用组件等。大型重构的工具包括之前介绍的设计原则和第设计模式。大型重构涉及的代码改动较多影响因此其难度较大耗时较长引入bug的风险较高。 小型重构是指对代码细节的重构主要是针对类、函数和变量等级别的重构如规范命名、规范注释、消除超大类或函数、提取重复代码等。小型重构主要是通过之间介绍的规范来实现。小型重构需要修改之处集中过程简单可操作性较强耗时较短引入bug风险较低。读者只要熟练掌握各种代码规范就可以在小型重构时得心应手。
4.重构的时机:什么时候重构(when) 在代码“烂”到一定程度之后我们才进行重构吗?当然不是。如果代码已经出现维护难、bug频发等严重问题那么重构已为时晚矣。 因此我们不提倡平时不注重代码质量随意添加或删除代码实在维护不了了就重构甚至重写的行为。我们不要寄希望于代码“烂”到一定程度后通过重构解决所有问题。我们须探索一个可持续、可演进的重构方案。这个重构方案就是持续重构。 我们要培养持续重构的意识。我们应该像把单元测试、CodeReview(代码评审)作为开发的一部分一样把持续重构也作为开发的一部分。如果持续重构成为一种开发习惯并在队内形成共识那么代码质量就有了保障。
5.重构的方法:应该如何重构(how) 前面提到按照重构的规模我们可以将重构笼统地分为大型重构和小型重构。对于这两种不同规模的重构我们要区别对待。 大型重构涉及的代码较多如果原有代码的质量较差耦合度较高那么重构时往往牵一发而动全身程序员本来觉得可以很快完成的重构结果有可能代码越改问题越多导致短时间内无法完成重构而新业务的开发又与重构冲突最终重构只能半途而废程序员无奈地撤消之前所有的改动。 因此在进行大型重构时我们要提前制订完善的重构计划有条不素地分阶段进行。每个阶段完成一小部分代码的重构然后提交、测试和运行没有问题之后再进行下一阶段的宣构保证代码仓库中的代码一直处于可运行的状态。在大型重构的每个阶段我们都要控制重构影响的代码的范围考虑如何兼容旧的代码逻辑必要的时候提供实现兼容的过渡代码只有这样我们才能让每一个阶段的重构都不会耗时太长(最好一天就能完成)不与新功能的开发冲突。 大型重构一定是有组织的、有计划的和谨慎的需要经验丰富、业务熟练的资深工程师主导而小型重构的影响范围小改动耗时短因此只要我们愿意并且有时间随时都可以进行小型重构实际上除利用人工方式发现代码的质量问题以外我们还可以借助成熟的代码分析工具(如Checkstyle、FindBugs和PMD等)自动发现代码中存在的问题然后有针对性地进行重构。 在项目开发中;资深软件工程师、项目管理者要担负重构的责任经常重构代码保证代码的质量处于可控状态避免引发“破窗效应”(只要一个人向项目中随意添加质量不高的代码就会有更多的人往项目中添加更多质量不高的代码)。除此之外我们要在团以内都营造一种追求代码质量的氛围以此来驱动团队成员主动关注代码质量进行持续重构。
6.思考题 在重构代码时你们遇到过哪些问题?在代码重构方面读者有什么经验教训?
