持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第25天，点击查看活动详情

[toc]

简介

上班划水划习惯了，通过一本书来重新使自己进入状态，从家里随意拿出的一本书，一看还有很多都没读过，或者是读过了又忘记了。优秀的书值得看数次，并且，优秀的书读书效果1+1>2

银弹

指，一击毙命，效果No.1 软件开发中不存在银弹

何谓重构

作为名词理解

对代码内部调整，提升可读性、降低成本

作为动词理解

调整的方法，使用不同的重构方法

• 最好是一次只修改局部一点点

重构与性能优化的异同

• 相同
  • 都是通过修改代码来达到目的
• 不同
  • 重构可以提升可读性，不一定百分百会提升性能
  • 性能提升以性能提升为主要，不一定提升可读性

两顶帽子

添加功能 和 重构

两个任务，两个状态，应该一次只做一件事

为何重构

改进软件设计

长期的修改，会导致架构腐败 新人不理解全局 旧代码过于庞大，没有人可以理解所有模块了 难度提升，意图模糊

使软件更易理解

编程是双向对话，我与计算机，我与继承我代码的小伙伴 有时候，继承自己代码的，可能是一段时间后的自己。。。。。。

找bug

再次理解的过程，找到bug

养成好的习惯

提高编程速度

反直觉？

不重构起步可能更快，后续添加功能就gg了，后续的修改，理解，时间拉长 重构只会在前期很小的影响时间，后期却能大幅提升速度，并且延长软件的生命周期，快速构建更强大的软件，增加耐久性

何时重构

事不过三，三则重构

第一次还可以，第二次觉得犯恶心，第三次就算了吧，重构

预备性重构

如果只有很小的变动就可以这次更简单，可以 如果新的修改会增加复杂度，造成复用性差等，那干脆现在就重构吧

理解重构、使代码更易读

看代码时候好的函数名更容易理解流程，小细节慢慢积累

捡垃圾式重构

跟上面一样，小毛病直接就改了吧，小细节慢慢积累

有计划的重构和见机行事的重构

上面的都是随意做的事情、自然发生 在团队里，保持结构强度，发现轻微的不对劲就需要等一下，先把以前的shit擦干净

长期重构

等一下擦屎的时间应该很多，如果时间长，算了，下一次修改时顺便做把，现在的能用就行，压力分散开

复审代码时重构

老带新，分享思路，和重构的思路很像

怎么给老板说

懂得老板会鼓励你这样做 闲着没事了跟不懂得老板说

何时重构

看上面，想做就做，保持进度