概述
提升编程效率的大致可以分三类:任务拆解(Tasking To Action)、使用高效的开发工具/框架、关注高效的工程实践。
其中任务拆解,我们在【实战TDD(2):Tasking To Action】(视频版) 中介绍了过了。
开发效率的工具/框架也才不但涌现,例如:Spring Boot、Spring Cloud、Elasticsearch 、Intellij IDEA 等为开发提供了不同领域的高效工具。
工程实践的也涉及到很多,比如:TDD、重构、Clean Code 等。
在过往的工作经历中,发现很多开发仅仅关注工具对开发效率的提升,当谈及如何写好代码时却没有像工具/框架那样能够侃侃而谈,究其原因是没有关注这方面的内容。
本文将聊聊提升编程效率的一个利器:重构。
为什么重构能够提升开发效率?
主要是以下五方面原因:
- 重构能够持续守护代码结构,避免了设计的腐败。
- 重构能帮助代码更容易被理解
- 重构能够提升编程速度
- 重构能够降低 Bug 修复时间。
- 重构能够提供的更快的应对变化的能力。
01 重构能够持续守护代码结构,避免了设计的腐败。
代码结构的流失是累积导致的,越难看懂代码要表达的意图,就越难保护代码中的设计,原本的设计也就流失的越快,设计就会腐败的越快。
小步重构能够持续不断的改善代码重点问题,将“大泥球”的代码通过一个个小的重构动作,让原本的设计而已维护,或者所设重构结构的清晰,让原本没有什么设计的代码,能够更清晰的表达短期意图。
日常工作让重构不能持续的一个原因就是短期目的。短期目的很重要,让我们始终聚焦在重要且紧急的任务上,但是问题是“只是关注短期目的,而忽视长期目的”。我们可以通过技术债来让 ROI 更高,但是同样也需要关注长期的 ROI。因此日常工作中,我们可以借助可视化等手段,维持重构的习惯,避免让原本花过心思的代码变得别人嘴中腐败的代码。
02 重构能够帮助代码更容易的被理解
就如同重构的定义:在不改其行为的情况下,改善其内部结构,从而提高可理解性、降低维护成本。
我们都知道,重构的结果产生的代码,具有良好的可读性,并且与业务上下文相呼应。
其实,重构的过程,也能够让代码更容易被理解,也更容易理解原本的泥球代码的意图。一边读代码,一边讲发现的代码的坏味道消除掉,读完了代码也有了更加清晰的代码的结果。
《重构》一书中有这样一句话:
Ralph Johnson 把"早期重构" 描述为”擦玻璃窗户上的污垢,是你能够看的更远”。
03 重构能够提升编程速度
一个人 / 团队并不是只写一个方法,一个类,一个接口就结束了。而是要在一个项目中经历几周、几个月、甚至几年。项目过程中持续的重构能够持续不断的改善代码的设计,并使之干净。团队中并不会因为某段代码晦涩难懂而不敢修改、不愿修改(因为需要花费大量的时间去做一件产出很低的事情,但是很难做)。
相信很多团队都遇到遗留的代码,而那些到处散布着坏味道的代码,正是因为这样的代码让开发效率低下,甚至停步不前。
重构能够提升编程速度,并不难证明。通过几个迭代的产出的结果就可以轻松的证明,对比一下没有重构的团队、有部分重构的团队、持续重构的团队在几个迭代后的产出结果,就会发现,持续重构的团队产出的内容每个迭代的结果都是相对稳定的,而没有重构的产出结构会越来越少,甚至无法响应业务提出的需求。
在遇到的开发者中有的人甚至对重构持反对看法,甚至更加偏激。问题往往是出现不清楚重构的技巧、重构的手法、重构工具的使用,和重构的实际。了解这些知识能够让重构事半功倍。
重构也不提倡偏激的“纯重构,为了重构而重构”,面对现实工作中任务的轻重缓急,重构也有自己的原则,例如“事不过三,三则重构“。
04 重构能够降低 Bug 修复时间
试想一下在一大坨代码中找一个bug并修复容易,还是在结构清晰,意图明确的代码中定位bug 并修复的成本高。
相信绝大部分情况都是后者。重构的结果就可能是生成一些小的方法,职责单一的类,层次结构相同的代码,在这样的代码中不用的担心不了解而不敢改动,看懂了代码即可修改。每个 bug 的上下文范围都小,修改后的代码影响范围也小。总的修复时间当然小。
05 重构能够提供的更快的应对变化的能力
现在工作中经常听到的一句话就是”拥抱变化“。开发者如何拥抱变化?加班加点?只能说是精神可嘉,但是方法不对。
重构产出了持续演进的代码设计,并消除日常代码中的坏味道,那么当新的需求到来,或者原油的需求需要进行更新调整,原来重构的结构能够帮助团队提升需求的变化的响应能力。
也是复杂的业务,清晰的代码设计所带来的复用和响应的能力的表现也就越强。
最后
以上就是笑点低皮皮虾为你收集整理的提升编程效率:重构的全部内容,希望文章能够帮你解决提升编程效率:重构所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复