如何重构项目代码

[yhm2046]

android 物联网项目， 原来同事（已经离职）写的太乱了，逻辑也不好。今天跟同事一起调试通了，用新的配置文件测试成功。领导说趁此机会把整个项目重构一下，画个流程图，然后整理一下逻辑，写个文档然后找时间一起开会给同事一起讲解一下。请问这种情况要如何重构，步骤是什么，有哪些可以提高效率的方法和软件？

目前在看《代码大全》和《 java 核心技术》，感觉越看越觉得不懂的太多，写的代码太垃圾，请教一下各位指条明路，谢谢！

[liununu]

有单元测试吗？覆盖全吗？如果没有，那很难保证不改挂。
或许得换个思路了，绞杀模式一步步去重写，替换模块……

[vivivo]

建议就是不要重构，你连业务大体逻辑可能都不知道，更不要说里面的各种妥协带来的坑，到时候就是火葬场。最好就是一楼的办法，一点一点的改，逐步替换。不过最难搞定的总是领导(:狗头

[zhanlanhuizhang]

过来人，没有单元测试，不要重构。我们组断断续续重构了 6 个月。测试了 3 个月，因为重构的优先级对于绝大部分公司的优先级不高。最后部门经理都有点不想做了。

[renmu]

没有人讲业务逻辑还是不要动了

[Saitama]

不要重构！不要重构！不要重构！
要么梳理业务，直接重写，起码省 50%时间。
要是梳理不清，就屎上雕花得了。

[drydiy]

我这么跟你说吧，重构完不出问题，只有你自己舒服了，然后对于下一代维护者而言，你的代码依然是屎山。
但是一旦出问题，那么你真的要好好想想你的绩效了。
对于这种老旧项目，合理的方式应该是组合的形式，就是新建一个工程，新旧并存，逐步迁移。

[zypy333]

项目大吗，不大又有时间尝试下呗，实在不行把主要逻辑理解了自己重写一套，每次这种问题都会有人反对，个人感觉在不给自己挖太大坑的前提下锻炼下技术也未尝不可。

[simonlu9]

学会写单元测试，但是还是不要随便重构，除非是哪些组件，不然哪些业务重构太多坑

[xuanbg]

钱难赚，屎难吃。能跑的代码不要动！🤔️🤔️🤔️

[wu67]

据我目前碰过的 6 个大摊子来看, 最好是一点一点的改, 不要整个项目重构

一般是遇上了业务需求要改动的, 就填多一点开发时间, 然后小范围的重构. 持续大半年之后慢慢的就好很多了, 除非是那些写完了就永远不改的模块, 那你也不用去读它.

[yhm2046]

谢谢各位前辈,要学的还是很多,还是听各位的一点点改吧, 我也没来多久,确实逻辑还没太搞清楚

[Biluesgakki]

@liununu 菜鸟想问下 日常开发，每个接口都要另写一个单元测试吗？

[artnowben]

是一个学习的好机会，不仅能把业务弄清楚，还会对技术有较大的提高。
重构可以一步步来，不要想着一步重构到位，逐步改善。

[liununu]

@Biluesgakki #12 API 上的测试并不都是「单元测试」，也有「集成测试」之类的。一般 API 的单元测试意义并不大，因为 Controller 上都不一样有逻辑，更多的是框架的调用，注解之类的，更好的是使用「集成测试」来保证 API 的请求验证，序列化或反序列化等。
而下层的 Service / Domain / Utils 的「公开」方法，更应该用单元测试，这些方法的输入和输出就都会被轻量的自动化的测试给保护好，以后做内部实现的重构才会更安全。