郑州做网站哪个公司好,网站空间流量不够,邯郸资讯,net源码的网站建设步骤什么是重构
重构#xff08;名词#xff09;#xff1a;对软件内部结构的一种调整#xff0c;目的是在不改变软件可观察行为的前提下#xff0c;提高其可理解性#xff0c;降低其修改成本。
重构#xff08;动词#xff09;#xff1a;使用一系列重构手法#xff0…什么是重构
重构名词对软件内部结构的一种调整目的是在不改变软件可观察行为的前提下提高其可理解性降低其修改成本。
重构动词使用一系列重构手法在不改变软件可观察行为的前提下调整其结构。 重构的关键在于运用大量微小且保持软件行为的步骤一步步达成大规模的修改。每个单独的重构要么很小要么由若干小步骤组合而成。 可观察行为整体而言经过重构之后的代码所做的事应该与重构之前大致一样。
重构与性能优化有很多相似之处两者都需要修改代码并且两者都不会改变程序的整体功能。两者的差别在于其目的重构是为了让代码“更容易理解更易于修改”。这可能使程序运行得更快也可能使程序运行得更慢。在性能优化时只关心让程序运行得更快最终得到的代码有可能更难理解和维护。
两顶帽子
这是一个比喻使用重构技术开发软件时我把自己的时间分配给两种截然不同的行为添加新功能和重构。添加新功能时我们不应该修改既有代码只管添加新功能。重构时我们就不饿能添加功能只管调整代码的结构。
实际开发过程中我们可能需要经常变换帽子。如果把程序结构改一下功能的添加会容易得多新功能添加好了以后发现代码难以理解则继续重构。
为何重构
我们之所以重构因为它能让我们更快——添加功能更快修复bug更快。
重构改进软件的设计
没有重构程序的内部设计架构会逐渐腐败变质。当人们只为短期目的而修改代码时他们经常没有完全理解架构的整体设计于是代码逐渐失去了自己的结构。程序员越来越难通过阅读源码来理解原来的设计。
经常性的重构有助于代码维持自己该有的形态。
重构使软件更容易理解
写让计算机理解的代码很容易只要能编译通过并运行但写出让别人能理解的代码则需要下点功夫了。所以我们写代码要考虑以后那个修改的人而且那个人很可能是哦我们自己。
开始进行重构前代码可以正常运行但结构不够理想。在重构上花一点点时间就可以让代码更好地表达自己的意图。
重构帮助找到Bug
对代码进行重构就可以深入理解代码的所作所为并立即把新的理解反映在代码当中。搞清楚程序结构的同时也验证了所做的一些假设 更容易将Bug找出来。重构能够帮助我们更有效地写出健壮的代码。
重构提高编程速度
设计耐久性假说通过投入精力改善内部设计我们增加了软件的耐久性从而可以更长时间地保持开发的快速。 行业的陈规认为良好的设计必须在开始编程之前完成因为一旦开始编写代码设计就只会逐渐腐败。重构改变了这个图景。现在我们可以改善已有代码的设计因此我们可以先做一个设计然后不断改善它哪怕程序本身的功能也在不断发生着变化。由于预先做出良好的设计非常困难想要既体面又快速地开发功能重构必不可少。
何时重构
三次法则
第一次做某件事时只管去做第二次做类似的事会产生反感但无论如何还是可以去做第三次再做类似的事你就应该重构。
预备性重构让添加新功能更容易
重构的最佳时机就在添加新功能之前。例如有个函数提供了我们需要的大部分功能只是有几个变量跟我们需要的冲突通常我们的做法使把这个函数复制过来修改几个值。这样做会导致重复代码将来有可能需要修改两处。使用函数参数化310进行重构后只需要调用这个函数传入需要的参数。
修复bug时的情况也是一样。在寻找问题根因时可能会发现如果把3段一模一样且都会导致错误的代码合并到一处问题修复起来会容易得多。
帮助理解的重构使代码更易懂
重构带来的帮助不仅发生在将来——常常是立竿见影。先在一些小细节上使用重构来帮助理解给一两个变量改名让它们更清楚地表达意图以方便理解或是将一个长函数拆成几个小函数。当代码变得更清晰一些时就会看见之前看不见的设计问题。
捡垃圾式重构
帮助理解的重构还有一个变体已经理解代码在做什么但发现它做得不好例如逻辑不必要地迂回复杂或者两个函数几乎完全相同可以用一个参数化的函数取而代之。有两种处理方式如果垃圾很容易重构马上重构它如果重构需要花一些精力记录下来完成当下的任务再回来重构它。
有计划的重构
一般项目计划上没有专门留给重构的时间绝大多数重构都在做其他事的过程中自然发生。如果团队过去忽视了重构那么常常会需要专门花一些时间来优化代码库以便更容易添加新功能。
长久以来人们认为编写软件是一个累加的过程要添加新功能我们就应该增加新代码。但优秀的程序员知道添加新功能最快的方法往往是先修改现有的代码使新功能容易被加入。所以软件永远不应该被视为“完成”。每当需要新能力时软件就应该做出相应的改变。越是在已有代码中这样的改变就越显重要。
何时不应该重构
如果有一块凌乱的代码但并不需要修改它那么就不需要重构它。如果丑陋的代码能被隐藏在一个API之下暂时容忍它继续保持丑陋。只有当需要理解其工作原理时对其进行重构才有价值。
另一种情况是如果重写比重构还容易就别重构了。
重构的挑战
延缓新功能开发
很多人认为花在重构的时间是在拖慢新功能的开发进度。“重构会拖慢进度”这种看法仍然很普遍这可能是导致人们没有充分重构的最大阻力所在。
重构的唯一目的就是让我们开发更快用更少的工作量创造更大的价值。
有一种情况确实需要权衡取舍有时会看到一个大规模的重构很有必要进行而马上要添加的功能非常小这时可以先把新功能加上然后再做这次大规模重构。
测试
如果开发环境开发工具能很好的支持自动化重构则可以信任这些重构如果不能最好有完备的测试套件测试环境、测试代码、单元测试等。
遗留代码
遗留代码往往很复杂可能也没有充足的测试关键还是别人写的。如果不幸遇到没有什么好办法没测试就加测试、随时重构相关的代码不建议尝试一鼓作气把复杂而混乱的遗留代码重构成漂亮的代码。
重构、架构和YAGNI
YAGNI“你不需要它you aret going to need it”。YAGNI并不是“不做架构性思考”的意思不过确实有人以这种欠考虑的方式做事。
重构对架构最大的影响在于通过重构我们能得到一个设计良好的代码库使其能够优雅地应对不断变化的需求。“在编码之前先完成架构”这种做法最大的问题在于它假设了软件的需求可以预先充分理解。但经验显示这个假设很多时候甚至可以说大多数时候是不切实际的。只有真正使用了软件、看到了软件对工作的影响人们才会想明白自己到底需要什么。
重构与软件开发过程
重构是否有效与团队采用的其他软件开发实践紧密相关。
重构的第一块基石是自测试代码。
如果一支团队想要重构那么每个团队成员都需要掌握重构技能能在需要时开展重构而不会干扰其他人的工作。
自测试代码、持续集成、重构三者之间有着很强的协同效应。
重构与性能
重构可能使软件运行更慢但它也使软件的性能优化更容易。先写出可调优的软件然后调优它以求获得足够的速度。
编写构造良好的程序不对性能投以特别的关注直至进入性能优化阶段——那通常是在开发后期。一旦进入该阶段再遵循特定的流程来调优程序性能。
在性能优化阶段首先应该用一个度量工具来监控程序的运行让它告诉我程序中哪些地方大量消耗时间和空间。这样就可以找出性能热点所在的一小段代码。然后集中关注这些性能热点并使用持续关注法中的优化手段来优化它们。
