无单元测试
1
neptuno 2018-09-20 15:56:30 +08:00
读懂了重写一份。。。
|
2
nicenight 2018-09-20 15:58:58 +08:00
那就先创建单元测试
|
3
linglongll 2018-09-20 16:00:21 +08:00
我做重构就是 把方法提取出来 不管他啥样给他包装出去 然后在调用的场景里加上注释 根据原有的逻辑重新组装一份人能看懂的 至于这些方法写成啥样 只要不是跑不了我就不管 大多数情况下这么处理 不这样的话还不如重写 当然 最好的方法还是避免重构 这就需要一手开发的时候的团队是不是给力了 这辈子真的再也不想给别人擦屁股 T.T
|
4
tf2017 2018-09-20 16:04:53 +08:00 2
ctrl + a
delete ----- 然后,重新开始…… |
5
keysona 2018-09-20 16:12:19 +08:00
理清脉络。
从小入手,如:修改变量名 /函数名,提取函数,封装对象等。 同时,有空自己写下单元测试。确保自己没有改错。 最后,熟悉整个项目后,就可以大刀修改了 --> 这种时候,如果有空的话,我会选择重写。 |
6
likaka 2018-09-20 16:19:31 +08:00
ctrl+f , 谁也逃不了
|
7
micean 2018-09-20 16:21:58 +08:00 1
如果对项目没有 90%以上的了解
一点都别碰 |
8
ren2881971 2018-09-20 16:29:21 +08:00
你确定要重构? 有那时间干啥点不好。。 你确定能承担风险么。。
|
9
xiaoshenke 2018-09-20 16:51:05 +08:00
1 如果你是从第一版开始开发的。那就理清项目架构的,然后根据单元测试一个模块一个模块的慢慢迭代。
2 如果你是中途接手的。额,算了吧。重构是吃力不讨好的事,干得好没你功劳,干得不好(比如某功能出问题)是要背锅的。 |
10
v2byy OP |
11
d18 2018-09-20 17:03:38 +08:00
吃力不讨好的事情
|
12
waytoexplorewhat 2018-09-20 17:11:27 +08:00 via Android
先写单元测试,在确保功能 OK 的前提下重构。可以了解下测试驱动开发,建议看书,网上博客三言两语很难说清
|
13
ben1024 2018-09-20 17:13:55 +08:00
抽象是开始的第一步,然后在想着构建业务层,数据层,在后是服务层,仓库层
|
14
jatesun 2018-09-20 17:16:27 +08:00
最好的方法就是不重构,如果你非要重构,请叫上原来核心开发人员以及组里两三个高手先评估一天,然后从不重要的业务模块逐个重构攻破,当然单测是很有必要的
|
15
limuyan44 2018-09-20 17:16:32 +08:00 via Android
没有测试的重构都是在开玩笑
|
16
zlmdaybreak 2018-09-20 17:17:27 +08:00
看乱到什么什么程度,建议现将功能比较乱的类整理、将某个简单的业务进行整理,这些不会影响太广而且容易上手。等全部都整理完之前你的工作量应该就会上来了。
|
17
xcjx 2018-09-20 17:19:58 +08:00 2
我最喜欢干这种活儿了
楼主一定要注意: 重构前进行代码量统计,分析待重构部分的各方面性能指标,一定要做好记录,最好是找测试人员来做; 这样重构之后就能邀功了… 你不要担心没有功可邀,只要你的编码水平比之前的开发人员平均水平高那么一丢丢,各方面指标一定会有提升,因为你是一个人在架构整个模块(系统),考虑得必然比之前要全面; 到时候就拿着这些玩意儿再写个工作汇报,写出你的思路、改进点什么的。这个活儿保准比开发新功能还有改 bug 回报更高(绩效、技术等) 明明是重构,你要把它干成是性能优化,最后再来个技术分享,完美了。 如果你不这么干,你就是被欺负了…… |
18
hiluluke 2018-09-20 17:38:13 +08:00
先加测试吧
|
19
posebear1990 2018-09-20 17:42:00 +08:00
新建两个目录,一个叫 new,一个叫 old,然后把老代码丢到 old 里,以后新功能在 new 里开发,重构完毕。如果是老项目的话,你可以在比较深一点的目录里看一看,弄不好就有有某个目录有个 new,同时也有个 old。
|
20
lucky2javascript 2018-09-21 01:39:59 +08:00
@xcjx 我现在在重写整个前端,求指点啊,感觉时间不够
|
21
zhangjiabin1010 2018-09-21 10:03:56 +08:00
做好回退备份,理清全部代码。
按维度分类 先设计好新架构(要考虑到未来功能的扩展)。 代码方面的,什么命名,解耦,封装 。看情况慢慢来就好。 测试要完备,不然以后出问题都是麻烦啊~ |
22
zichen 2018-09-21 11:07:31 +08:00
重构代码我觉得最难的不是功能,而是理清业务,最近在带着组里的人将一个项目从.net 重构到 java,因为这个项目之前的负责人都走了,也没有什么像样的文档交接,所以只能扒代码看业务,然后还要求重构完的系统和老系统功能保持一致,关键是产品经理也走了,以前一些老的业务流程是啥样的,谁也不知道,只能靠猜,然后这个项目 50%的业务逻辑还是封在存储过程里的,存储过程可读性多差我就不用说了,总之现在刚重构完了一半,一堆坑,因为到现在我们还是没有一个人能 100%了解老项目的业务逻辑。
|
23
aikin 2018-09-24 22:41:42 +08:00 1
我一般都是先加测试,再重构。因为没有测试保障的重构,就是“耍流氓”。hahah
分享一个之前练习重构时,整合的所有重构手法练习的栗子和测试。https://github.com/aikin/refactoring-kata |