入职第二天，老大就让我重构代码！

今天正好借助这个话题谈一下代码重构在实际工作中的重要性。

记得上次实习的时候，对一个老项目其中的一部分代码进行了重构，当时写了一篇文章，引起来不少讨论。

这么用 if-else，小鹿差点被辞退！

第二天，在 CSDN 上，引发了一波“口水”大战。

有的人支持，是因为这样扩展性好，而且符合开放封闭式原则，保证每个功能的单一性。

有的人却不支持，认为多一事不如少一事，而且重构一个老项目的代码有风险，一旦出现问题，怕担待不起。

还有的人，认为比较中立，按照原来逻辑写完，正常上线没问题，然后再进行重构。我相信每个人都站在了自己角度和以往的项目经验和经历说出了自己的想法。

直到现在，入职了一家新公司，小鹿也是闲不住呀，就主动和老大要任务，行吧。因为需求不断改动的原因，项目中有部分功能逻辑碓切比较严重，那你就重构一下这部分代码吧。

1、

说到这，对于重构以及为什么会有设计模式这个东西，小鹿觉得有必要去分享以下自己的见解，也欢迎留言区说出你们的想法。

世界上每一种事物的出现，都是有存在它的原因的，这个东西为什么会出现？它的出现解决了一个什么样的问题？那么是如何解决的？我们按照这个思路，去看看设计模式的出现给我们带来了哪些便利？

想必很多同学和小鹿一样，刚听到设计模式这个词的时候，觉得这东西好高大上，这玩意一定距离自己很远，首先就打上了一个标签，这东西不是一般人学的来的，所以就产生了一种恐惧和排斥的心理。

设计模式的出现，可以说是前辈智慧的结晶，就像是他们在开发项目中经常遇到的各种各样相同的问题进行了总结，每一种问题解决方案的类型，都成为一种设计模式。

那么什么问题需要用设计模式去解决呢？从《JavaScript 设计模式核⼼原理与应⽤实践》这本小册中，得到最终的答案，可以说作者表达了设计模式的本质是什么，就是封装变化。

项目中，总是会根据客户的需求进行不断的扩展功能，但是我们在初次开发的时候，不会想到客户会扩展哪些功能，一般我们就不断的修改业务逻辑代码，当需求一多，整个代码就变得冗余和难以维护，一旦出现问题，排查起来非常困难。所以设计模式灵活的解决了这种问题。

让项目中以后可能扩展的地方变的灵活，不变的地方变的稳定，这就是设计模式最核心解决的问题。

2、

咱们回到原来实际问题上，重构代码有风险怎么办？

说到重构风险，写代码本来就是一件有风险的事情，你写的每一行代码没有人敢保证没有 bug 的吧，重构也一样，就算不重构，bug 依然也会出，这和重不重构没有必然的联系。

小鹿在拿到实际的项目代码进行重构时，也有时出现了业务逻辑上的错误，但是我们老大还是坚持支持重构的，这对以后变化更好的扩展提供了方便。

除此之外，还有些人可能认为，重构代码就是耗费时间，别自己没事给自己找事。如果说重构是给当前的自己找麻烦的话，那么不重构是给未来的自己找更大的麻烦。

3、

之前小鹿给大家分享过二八原则，20% 的原因导致了 80% 的结果；而其它 80% 的原因只产生 20% 的结果。

而代码重构正式这 20% 的部分。虽然我们很多人认为重不重构显得不是这么重要，那么后续客户增加这部分代码的需求的话，导致代码冗余，难以维护和测试，甚至拖慢整个产品的上线。

所以我们要做的就是，把精力注重放在这些将来要频繁增加需求的功能代码上。而且要保证代码质量尽可能的好，尽可能的方便后续维护。

举一个曾经项目组中惨痛的教训，当时大二接手的第一个外包项目，并没有详细的需求分析和说明，和客户交接的老师只是口头的和我们说大体的需求是如何如何的，开发半年之后，整个 APP 除了登录和注册页面，都要重新做。

这个惨痛的教训一直提醒着我，原因就是出在需求分析。我们通常认为这部分工作不是特别重要，而且并没有专业的人员来对接，所以用户到底想要什么都没搞清楚，后边的开发、测试、维护都是白做。

看似不起眼的这 20% 部分，却影响着整个 80% 的运作，所以设计模式不是用来应付面试的，而是真能帮助我们在项目中开花结果。

更多相关文章