这是一个创建于 570 天前的主题，其中的信息可能已经有所发展或是发生改变。
android 物联网项目， 原来同事（已经离职）写的太乱了，逻辑也不好。今天跟同事一起调试通了，用新的配置文件测试成功。领导说趁此机会把整个项目重构一下，画个流程图，然后整理一下逻辑，写个文档然后找时间一起开会给同事一起讲解一下。请问这种情况要如何重构，步骤是什么，有哪些可以提高效率的方法和软件？
目前在看《代码大全》和《 java 核心技术》，感觉越看越觉得不懂的太多，写的代码太垃圾，请教一下各位指条明路，谢谢！
 |
1
liununu 2023-04-19 20:19:50 +08:00 via iPhone
有单元测试吗？覆盖全吗？如果没有，那很难保证不改挂。
或许得换个思路了，绞杀模式一步步去重写，替换模块…… |
 |
2
vivivo 2023-04-19 20:59:35 +08:00
建议就是不要重构，你连业务大体逻辑可能都不知道，更不要说里面的各种妥协带来的坑，到时候就是火葬场。最好就是一楼的办法，一点一点的改，逐步替换。不过最难搞定的总是领导(:狗头
|
 |
3
zhanlanhuizhang 2023-04-19 21:36:01 +08:00  1
过来人，没有单元测试，不要重构。我们组断断续续重构了 6 个月。测试了 3 个月，因为重构的优先级对于绝大部分公司的优先级不高。最后部门经理都有点不想做了。
|
 |
4
renmu 2023-04-19 21:53:43 +08:00 via Android
没有人讲业务逻辑还是不要动了
|
 |
5
Saitama 2023-04-19 22:06:28 +08:00
不要重构！不要重构！不要重构！
要么梳理业务，直接重写，起码省 50%时间。 要是梳理不清，就屎上雕花得了。 |
 |
6
drydiy 2023-04-19 22:47:18 +08:00
我这么跟你说吧，重构完不出问题，只有你自己舒服了，然后对于下一代维护者而言，你的代码依然是屎山。
但是一旦出问题，那么你真的要好好想想你的绩效了。 对于这种老旧项目，合理的方式应该是组合的形式，就是新建一个工程，新旧并存，逐步迁移。 |
 |
7
zypy333 2023-04-19 23:27:47 +08:00
项目大吗，不大又有时间尝试下呗，实在不行把主要逻辑理解了自己重写一套，每次这种问题都会有人反对，个人感觉在不给自己挖太大坑的前提下锻炼下技术也未尝不可。
|
 |
8
simonlu9 2023-04-19 23:35:07 +08:00
学会写单元测试，但是还是不要随便重构，除非是哪些组件，不然哪些业务重构太多坑
|
 |
9
xuanbg 2023-04-20 08:19:06 +08:00
钱难赚，屎难吃。能跑的代码不要动！🤔️🤔️🤔️
|
 |
10
wu67 2023-04-20 09:12:32 +08:00
据我目前碰过的 6 个大摊子来看, 最好是一点一点的改, 不要整个项目重构
一般是遇上了业务需求要改动的, 就填多一点开发时间, 然后小范围的重构. 持续大半年之后慢慢的就好很多了, 除非是那些写完了就永远不改的模块, 那你也不用去读它. |
 |
11
yhm2046 OP 谢谢各位前辈,要学的还是很多,还是听各位的一点点改吧, 我也没来多久,确实逻辑还没太搞清楚
|
 |
12
Biluesgakki 2023-04-20 13:47:52 +08:00
@liununu 菜鸟想问下 日常开发，每个接口都要另写一个单元测试吗？
|
 |
13
artnowben 2023-04-20 20:46:28 +08:00
是一个学习的好机会，不仅能把业务弄清楚，还会对技术有较大的提高。
重构可以一步步来，不要想着一步重构到位，逐步改善。 |
|
14
liununu 2023-04-20 21:32:21 +08:00 1
@Biluesgakki #12 API 上的测试并不都是「单元测试」，也有「集成测试」之类的。一般 API 的单元测试意义并不大，因为 Controller 上都不一样有逻辑，更多的是框架的调用，注解之类的，更好的是使用「集成测试」来保证 API 的请求验证，序列化或反序列化等。
而下层的 Service / Domain / Utils 的「公开」方法，更应该用单元测试，这些方法的输入和输出就都会被轻量的自动化的测试给保护好，以后做内部实现的重构才会更安全。 |
Select Language