dulp
大型重构进行的较少，其次是中型重构。中型重构一般是代码质量不高和业务改动较大同时出现时会进行。之前一直没有思考如何度量重构的收益，这篇文章帮助很大。
作者回复：以终为始才能更好完成重构的工作🤝。
2023-03-11
布魯斯～
感谢老师的讲解，想请问一下老师，在现实生活上，许多登入是透过OAuth 2.0 去实现的，想请问一下老师，针对这种场景，要如何撰写自动化的大型测试吗？
作者回复：Hi，布魯斯。
在实际项目中，首先对于账号来说得有对应的测试账号，另外大型的测试与文中介绍的方法还是一致的，只不过需要加入一些等待及超时的机制（网络请求需要时间）。
2023-03-18
1
le bonheur
从上家公司开始要求跟学习写单元测试,开始爱上单元测试.终于看到了一篇比较综合写单元测试的文章.太高兴了
作者回复：Hi，期待一起完成专栏的学习。
2023-03-28
木头人
没经历大厂的流程，希望可以学到不一样的东西。
作者回复：你好，木头人。期待一起完成专栏的学习，也欢迎你把他分享给你的同事或者朋友🤝。
2023-03-01
Justin
怪不得大公司都要分的很细，做好一个大型app不容易
作者回复：Hi，Justin。大也是从小不断演化而来了。如果你的产品现在的规模和复杂度还没有这么高或者产品才刚刚开始，没有这么多的问题。那么更应该抓住这个时机，学习如何避免让自己的产品变成一个遗留系统。
期待一起完成专栏的学习🤝。
2023-02-21
oldjii
目前正着手于一个遗留模块的重构，给我感受最大难度是保证重构后的业务逻辑与线上保持一致，所以很期待自动化分析、自动化重构的内容。
作者回复：Hi，oldjii。非常开心收到你的留言。如何保障重构后不破坏原有的逻辑，正是专栏的重点之一。希望通过专栏的学习，你能更好完成遗留模块的重构工作。也欢迎你把专栏分享给你的同事或朋友🤝
2023-02-17
York
老师，我们在重构系统的时候，打算前后端一起重构，前端页面也做了新的设计和布局。这个时候，我们又有什么好办法保证核心业务逻辑的正确？之前想通过对比新老API返回的数据来验证，但是我们也打算对返回前端的数据结构重新设计整理，所以感觉这个也行不通。请教下老师有没有什么好的建议。谢谢
作者回复：Hi，York。非常开心收到你的留意。
从问题描述上来看，我们的产品的改进会涉及到如下2点：
1. 前端的页面会做新的UI涉及和布局
2. 接口会做新的结构调整
这里我猜测后端的接口调整，应该主要是补充一些数据，或者合并一些接口。建议任然可以通过编写自动化接口测试的方式来对比新老接口的数据差异（当然新增或者合并的数据需要编写脚本去处理）。
对于前端来说，如果之前的架构设计比较合理，主要是UI调整，那么涉及的修改主要也是在视图层，修改的风险相对比较可控。但如果之前架构耦合比较严重，那么得考虑先进行架构重构，进行分离。具体的方式和流程我们会在后续的课程中讲解，期待一起完成专栏的学习🤝。
2023-02-20
郑峰
实践中以中型重构为主。
小型重构在代码提交时已经完成。
大型重构则需要有计划进行，比如自动化重构工具的构建，和自动化保障规则的构建。
作者回复：Hi，郑峰。期待一起完成专栏的学习。
2023-02-18
1
Geek_90e087
打卡开始
作者回复：期待一起完成专栏的学习。
2023-02-16
zenk
目前整个系统
1. 缺少分层不分核心业务和运维业务，各种逻辑都在一个函数里面
2. 缺少模块化，同样的逻辑分散
3. 导致理解业务逻辑，老担心是不是还有其他地方的代码没有看
这样的系统该如何一步一步的重构
目前的思路大致是：
1. 最多是组件级别重构
2. 识别那些坏味道，小步改进
3. 模块化的时候，梳理出依赖关系，按照依赖关系，先模块化前置依赖
请教老师
1. 这个步骤靠谱不，求其他建议
2. 另外执行的时候需要和领导沟通具体的工作和厂出，按照上面的度量，领导听了感觉太有说服力，不知这方面该怎么做
作者回复：zenk，你好。感谢你分享了你目前产品的相关问题，也非常开心看到了你对目前系统改进的思考，这是一个非常好的开始。
思路里面提到了一些点，例如小步、模块化及依赖关系，这些都是非常好，但是相对来说比较零散。在分析设计篇和解耦重构篇中会有更系统 的方法及流程。相信完成专栏的学习，一定能够帮助你解决系统 的痛点。
另外关于度量，我们也会有一章专门来介绍相关的实践落地经验，希望你能坚持完成专栏的学习 ⛽️
2023-02-14
讲师
黄俊彬
Thoughtworks 资深咨询师
编辑推荐
包含这门课的学习路径
Java工程师
29门课程 154.7w人学习
架构师
28门课程 151.8w人学习
看过的人还看了
