27 | 理论一：什么情况下要重构？到底重构什么？又该如何重构？

精选留言(51)

• 

  brianhuuu

  重构最难的还是领导不支持

  作者回复: 😂

  2020-01-03

   3

   45
• 

  刘大明

  前段时间刚重构了一个功能模块。该模块可以说是祖传代码。里面堆砌着各种判断条件，就是所谓的箭头型代码。我接手这个功能重构的
  1.把代码读一遍和跑一遍，理解里面的需求。尽量画一个流程图。
  2.建立防护网。将需求拆分之后，针对每个拆分的业务点写单元测试。
  4.开始重构，解耦逻辑，设计方法的时候尽量让职业单一，类与类之间尽量符合迪米特原则，有依赖关系的类尽量只依赖类的特定方法。我觉得比较基础也是比较重要一点。不要有重复代码。命名要规范，类的各个职业要清晰。重构过程中，其实也要时不时的识别代码的坏味道。尽然是重构，那么肯定要比不重构之前肯定要更好。
  5.重构完成之后，通过防护网的测试。
  
  当天重构代码上线之后，基本上没有问题。运行了几天之后有一小段逻辑隐藏的比较深没有写这个逻辑测试，后面补上了一直都没有出过问题了。还是比较稳定的。
  我这里只是做了中小规模的重构，后面跟着小争哥继续系统的学习大规模重构，以及重构的技巧和思想。

  2020-01-03

  

   12
• 

  失火的夏天

  重构自然是要用的我们牛逼的设计模式和数据结构了。。。啊-_-||开个玩笑哈。
  
  重构这玩意嘛，其实在第一版提上去的时候就应该要重构了，也就是我们常说的，边写边重构。
  
  一个方法写的时候发现分支判断太多，工厂模式就要登场了。
  
  如果大部分代码都比较重复，这个时候就需要往底层的抽象，甚至用上策略模式。
  
  需要做一个非功能性需求，每一个接口调用都要记录的东西，我们为了避免业务侵入性，就要考虑代理模式重构之前的业务侵入性强的代码，将功能与非功能分离。
  
  说到底，重构不要等，而是马上动手，只有行动了，才不会害怕。第一版稍微辛苦一些，以后就不会那么恶心了，功在当代，利在千秋。

  2020-01-03

  

   7
• 

  辣么大

  代码中的坏味道，好比人的头疼脑热。“小病”不管的话，迟早会发展成大病，需要动大手术，甚至病入膏肓。
  实际中的一些体会：
  一、在完成一个新需求时，在时间允许的情况下，会经常改进代码，使代码更优雅。
  二、“重构不改变外部的可见行为“，引入自动化测试非常重要，国内有些团队可能做的不好。因为改动代码可能引入bug，如果没有自动化测试，测起来就会非常费劲，改动的结果不确定。如果测试不方便，谁会愿意修改之前work的代码呢？
  三、持续集成、自动化测试、持续重构都是很好的工程实践。即使工作的项目中暂时没有使用，也应该有所了解。

  2020-01-03

   3

   5
• 

  峰

  1，无单测的条件下，别说重构了，我不想以前任何代码，对，我是一个怕事的程序员～
  2，小步快走的重构方式很重要，毕其功于一役的重构总是构完了，发现和主干代码相差哈哈哈，我还是不合入了吧，留给自己欣赏自己精细雕琢的玩具。。。

  2020-01-03

  

   3
• 

  桂城老托尼

  重构的经验，1.工作中鼓励持续重构，但不赞成为了重构而重构.2.重构一定要在有比较完善的测试用例覆盖和回归用例库的情况下进行(可测试性)，否则会相当危险。3. 重构最好有AB工具灰度比对，逐步切流。4. 重构最好有资深的成员共同CR，结合大家的意见，可能本次的重构也会引入一些怪味道。
  重构的教训，出现问题的场景往往在于一个细小的点，能注意到的往往没有问题。 重构一旦出问题会面临比较大的精神压力和信心挑战，会部分挫败重构者的积极性，这时候需要TL的鼓励和支持，避免让员工感受到做多错多。

  2020-01-04

  

   2
• 

  李小四

  设计模式_27
  
  没有做过大重构，小重构倒是经常做，我发现我做需求常常比别人慢，原因是大概率我改的地方比需求涉及的多一些，可以算是小重构吧。
  
  很同意王争老师说的，大部分人都没有进行过重构，而大部分的代码又是由这大部分的人写的，所以，市面上的大部分代码可能都。。。
  
  我在创业公司呆过，见识过技术总监申请重构时被挑战的体无完肤，不欢而散，代码一直烂下去，最终谁也改不动，大量的客户流失，业务严重受损。当然，我在这个过程中，毫无作为。。。

  2020-01-03

  

   2
• 

  再见孙悟空

  庆幸自己有个好领导，日常对我的代码 review 得非常严格，平时使用 source tree ，git rebase 可以清晰地看到每一次提交，这样代码 review 起来就没什么压力了。
  
  另一方面，最好在项目的开始阶段和大家分享你的设计思路，否则等项目要准备发布上线时，拉上一堆人来 review 代码时，其实效果几乎没啥的，大家只能看看命名风格，像什么高内聚低耦合，设计模式，封装抽象等即使有问题，也会因为项目时间紧而将就放行。

  2020-01-03

  

   1
• 

  Calvin

  在农村长大的孩子应该多少见过盖房子的情形，一般师傅会用砖挂一根线在不断的盖房子的过程中观察整个房子是否出现歪斜的情况，这个过程是持续的，要时刻保证一砖一瓦的建上去的房子是笔直的。写代码就是如此，团队应该有这样的"一根线"来保证产品的正常开发，不至于整个项目出现问题，而重构就像是发现了房子有点歪需要重新进行改正，高手是发现绳子偏移的时候就开始纠错了，大部分团队只能等到明显发现房子歪了才开始修正。

  2020-01-03

  

   1
• 

  安静的boy

  我现在负责的项目是我从零就参与的，到现在大大小小已经迭代了十几个版本。我发现随着版本的迭代，会出现很多相似的重复代码，这个时候我就会去想办法重构代码，做一些抽象啊，利用一些设计模式，不过我现在只用到了模板设计模式。如果不重构我觉着以后需求再变化改动的地方太多了，而且还很有可能出错。另外，我发现重构了以后代码的可读性也会比较好。

  2020-01-03

  

   1
• 

  阿卡牛

  品味很重要，能品味出代码的味道

  2020-01-03

  

   1
• 

  黄林晴

  打卡✔
  心得体会吧，哈哈哈哈哈
  我被频繁改动的需求压的喘不过气，再牛逼的架构怕是也抵不住😒

  2020-01-03

   1

   1
• 

  Jackie

  终于把落下的课都不上来了，后面要实时跟进老师的脚步了。
  
  重构的意义还是很大，有重构的习惯对于自己提升技术实力很重要，有些看似在存在面试题里面的设计模式完全可以在重构的时候派上用场。
  
  同时，部门有重构的习惯，也会形成比较好的技术氛围。看到好味道的代码，大家都会争相效仿，不会也不好意思在整洁的代码丢下“老鼠屎”。反之，看到坏味道的代码，大家就有可能群体性破罐子破摔。

  2020-01-05

  

  
• 

  奔跑的小孩

  1.要具有重构意识，阶段性重构代码，重构分为大重构（模块重新划分、类与类之间关系重构等）和小重构（通过设计模式或者代码优化程序等 ）
  2.重构情况下最好不要改变外部的代码调用规则，兼容之前的代码
  3.小跑试错，快速迭代，不要上来就是大而全的迭代

  2020-01-05

  

  
• 

  Frank

  以前在写代码时只偏重于代码是否能跑通，而对代码质量关心的比较少。而团队没有强调这种意识，即时有，给出的概念也比较抽象，很难落地。比较幸运的是换了好的平台，解除到了更多的东西，这些东西自己也在慢慢接触。知道了除了写代码之外，还要思考如何写出“好代码”。持续重构是一个在实际开发中不断提升代码质量的好方法。体会最深的应该是在前1个月自己从零开发的一个模块中就使用到了这种方式来提升代码质量（主要是提高可维护性，可读性）。当时有个类代码写的很多，逻辑很复杂。大约超过了1000了，写了很多大函数（其实在一开始就应该尽量避免写大函数），在实现完基本功能后，一有时间，自己就重新去读自己写的代码，看到不好的地方（如命名规范，超大函数等）就进行修改，重构。通过这样的实践，深刻体会到了“时刻具有持续重构意识，才能避免开发初期就过度设计，避免代码维护的过程中质量的下降”。

  2020-01-05

  

  
• 

  L🚲🐱

  如楼上所说 重构最大问题是领导不支持，做的政府项目， 要求稳定就行，代码质量差的不行，很无奈😂

  2020-01-05

  

  
• 

  yang

  事实上对代码的平时的优化与改进还好，大的重构要考虑清楚，目标是什么。这个目标不好把。是提升了多少稳定性？交付效率？还是提升了连接效率？要考虑清楚，否则投入很多人力，重构完成，也不一定是没有bug,还有很多技术的重构最好和产品的重构一起。如果是小的技术功能改进，好的办法是ab测试，慢点切流量.

  2020-01-05

  

  
• 

  荀麒睿

  就拿我们公司的系统来说，之前两个团队开发整合，就是因为没有进行好的规范，并且没有进行持续重构，再加上人员的走动，导致之后的人在接手的时候碰到新的需求，也不知道是否有可复用的代码，就直接再写新的接口，最终导致整个系统变得异常笨重，重复的接口越来越多。后来因为要迁移部署环境，进行了一次大型的重构，公司安排了新来的员工来负责，结果业务不熟悉，也就只能按照新部署要求，做了一些简单的调整，代码依旧越来越复杂，所以我觉得持续重构的意识真的很重要，看了争哥的专栏之后，赶紧对以前的代码重新再优化一遍

  2020-01-04

  

  
• 

  张迪

  现在我们代码乱的一塌糊涂，这个项目是后来接手的，项目开发人员变了好几轮，里面堆得一大堆代码。现在做个设计改动，得动用一个团队的力量一个月的时间

  2020-01-04

  

  
• 

  leon

  新入职某大厂的时候做了一次大规模重构，把一个核心系统的逻辑迁移到另一个系统。最大的困难是 1. 看不懂代码，到处if else ， 代码层次混乱，业务逻辑复杂。 2. 没有单元测试，没有检验重构正确与否的标准。做了2个月，十分痛苦。
  
  抱怨一下，ppt写的一个比一个好，代码写的一个比一个烂

  2020-01-04

  

  