- 综合排序
- 最热优先
- 最新优先
- 来自专栏服务端技术杂谈
重构系统的套路-明确重构目的
重构系统的套路系列： 本篇说下重构系统的套路中的，明确重构的目的。 ? 我们进行系统重构会抱着不同的目的，比如为了系统稳定性，为了系统中某些功能负载能力更强，为了系统更便于维护，或是为了系统更便于持续集成提升RD和QA的人效。 上面这个虽然是我自己在系统梳理过程中意淫出来的场景，但我不得不再我进行类似系统重构之前，在代码逻辑角度，功能业务角度，缓存集群，mq集群，DB集群等角度考虑，我这次重构可能造成的问题，只有我们在系统重构之间能够想的比黑天鹅来的更快我们才能对系统做更多的保护 如果系统重构的目的在于可维护性，和上面两点的区别在于，周期不可操之过急。 我们需要在整个业务角度去理解系统，同时对未来系统所承接的业务有所评估，这样我们才能设计出一个面向未来的系统。 基于以上四点不同的重构需求，我们采取的方案和执行的角度完全不同，系统变大了之后，稳定第一。
2.3K30发布于 2018-09-21 - 来自专栏Java架构师学习
如何做系统重构
明确当前系统的状态 决定要执行重构后，首要做的任务，并不是立刻动手执行重构，而是对当前的架构状态有清晰的了解，如果开发当前系统的同事还在本公司，一定要拉着同事好好的讨论一下，作者给大家讲讲当时的思路，比我们闷头看代码理解还是要强不少的 ，能清楚理解当前系统的设计初衷。 除此之外，通过研究当前系统，才能记录目前系统的性能基准，为未来评估重构的效果做准备。 重构中必须建立或者维护业务数据流 大家有任何想法和建议，请加我的JAVA架构进阶群：554355695 现在任何一个后台系统，都会通过日志系统建立必要的业务流转记录，比如，我这几年前后带的几支团队，都会建立各类业务埋点 在重构过程中或者重构后，我们能用数据来验证重构的效果，能不断的对系统进行优化。 5.
1.5K50发布于 2018-05-04 - 来自专栏杨龙飞前端
vue重构后台管理系统调研
Q4要来了，我来这家公司已经一个季度了，通过对公司前端框架的整体认识，对业务的一些认识，发现，这些东西也都是可以重构，无论是v2，还是v3的代码。 进入重构，首先的问题是，后端渲染，为什么要做后端渲染，因为有时候会做google统计，seo优化，之类的，必须用后端渲染才行，普通的spa就不行了，而且语言包那一块需要去服务器拉去数据后才能生成文件，必须有后端服务做支撑 但是这样搭载过之后，我发现，后台管理系统里会有一些统计数据的工具，这时候可能会引入vue的图标框架，但是我不能确定vue的图表插件能否支持ssr 纠结之中我还是放弃了，如果以后有小的项目可以试一下。
1.7K10发布于 2018-10-11 - 来自专栏java思维导图
大型系统重构的步骤梳理
作者:Yomut 原文：https://my.oschina.net/yomut/blog/714497 目前正在参与公司一个核心大系统的重构工作。本文梳理一下大型系统重构的一些步骤和心得。 系统除了要应付大量的并发请求，还必须快速支持各种业务需求，必须对系统进行大重构。 备注： 下面的一些步骤和方式是根据我自己的项目的实际列出的。 数据库重构 前期的项目，由于赶进度，并没有充足的时间设计表，导致各种冗余表、大表、大量的冗余的字段、扩展性差的表。所以重构系统的时候，可以先从表开始，通过对当前业务的梳理，重新把表整理一下。 1. 数据库重构，一般由专门的数据架构师来处理。数据架构师必须和业务架构师紧密配合。 数据迁移 由于对数据库进行了重构，那么旧数据库的数据必须完整的迁移过来。 观察系统 新接口接入所有流量后，除了监控系统监控接口之外，开发人员必须经常看日志系统，观察系统是否正常工作。最好定一个任务，让开发人员轮流观察系统。 -- 完 --
1.8K20发布于 2018-08-16 - 来自专栏用户1337634的专栏
订单交易系统代码重构
订单交易系统随着业务的发展，逻辑也越来越多，需要进行重构，之前已经把交易模块拆分了，目前还需要再把订单系统进一步拆分 当前的问题 订单相关代码都放在一起，随着业务发展，逻辑越来越复杂 履约和查询（ 导出）对系统要求不同，不方便统一优化 重构方法 分离订单履约和查询相关逻辑代码 批量查询和导出相关逻辑，不再查询业务MySQL，改为查询ElasticSearch ps: 重构时，要注意哪些业务是基本固定的 ，哪些是经常变动的，需要把变动的逻辑尽量放到一起 参考 重构：改善饿了么交易系统的设计思路
89510发布于 2021-07-20 - 来自专栏phodal
系统重构的未来：重构工具 Coca 一周年
也因此《系统重构与迁移指南》（https://migration.ink/) 成为了系统重构不可多选的材料，Google 『系统重构』 和 『重构工具』会有惊喜。 ? ? 系统的必然之路：系统重构 or 重写 没啥说的，部分的系统都是要被重构或者重写的。那么另外一部分呢？他们被淘汰了——要么是产品，要么是公司，笑~。 系统变成了一个大泥球，需求已经越来越难以实现： ? 真相就是这么简单。如果系统不被指南，和进行频繁的代码级重构的话，那么系统被取代的速度就更快了。 系统重构的未来 在 Coca 编写完成之后，我发布了《系统重构与迁移指南》一份短小、精悍的重构手册。 但是，对于系统级重构来说，基本上很少有工具可以直接能支撑现有的系统，哪怕是 Coca 也是有限的支持。主要原因就是：大部分的内部系统都绑定了组织中的模式。
75040发布于 2020-11-05 - 来自专栏服务端技术杂谈
重构系统的套路-提高并发能力
提高系统并发能力，总结起来有三点：异步，缓存，并行。 对于老系统需要在业务进行梳理，如果业务场景中不关心返回值，这样完全可以做成异步。 梳理系统的代码，将很多同步的for，while的循环改成基于Future的同步模型，提升整体并行度，达到一定的性能提升。
70620发布于 2018-07-23 - 来自专栏Grace development
老项目重构手记之用户系统
受邀来一起重构公司的老项目 概述 重构首先要注意几个点 – 重构后功能的可扩展性 – 业务互相依赖的复杂度 – 脱离本身的业务进行重构 – 重构后的代码可读性与可维护性 – 性能的提升 以上几点是重构注意的地方也是重构的目的 分析 本次重构的项目运营了三年之久，用户及业务量也上不来。 至于重构的真正原因不清楚。 用户注册量:107470 日PV:1000+ 非常的惨淡 关于用户ID与其他业务绑定仅仅是单纯的存储用户ID进行绑定，类似与评论，购买等。 根据需求分表，现在所有的第三方授权都放到一个表里了 选型 前期重构要求速度要快。所以只能选择世界上最好的语言。 迭代 重构并不是一言一语，几行代码或者一个大佬的方案就可以解决的。实际重构也是一个开发的过程。在不断的迭代中，将重构完成的部分补回到业务中。 致谢 感谢你看到这里，希望本篇文章可以帮到你。
76220发布于 2018-09-18 【重构业务系统考虑的方案】
快速重构系统需要以下几个步骤： 分析系统：首先，对现有系统进行彻底的分析，了解现有系统的架构、代码结构、功能和性能等方面的问题。这将帮助你确定需要重构的部分和优先级。 这些目标可能包括提高系统性能、增强系统安全性、简化代码结构等。 优化设计：根据重构目标，对系统的设计进行优化。这可能包括解耦各个模块、引入新的设计模式、重构数据库结构等。 重构代码：根据重构目标和优化设计，逐步重构系统的代码。这可能包括重命名变量和函数、简化代码逻辑、提取重复的代码块为函数等。 进行测试：在重构过程中，要进行充分的测试，确保重构后的系统仍然能够正常运行，并且能够满足重构目标。 以上是快速重构系统的一般步骤，具体的重构过程可能根据系统的实际情况而有所不同。重构需要高度的技术能力和认真的执行力，同时要注意在重构过程中保持系统的稳定性和可用性。
9410编辑于 2025-08-29- 来自专栏杨建荣的学习笔记
运维系统重构的设计思路
最近要对已有的运维平台做重构工作，为什么要做重构，主要还是因为各种各样的原因，需要对已有的问题改进，修复历史遗留包袱。这个时间迟早都会来到，还不如自己自觉一点，提前发现问题，提前修复。 整个重构的核心思路就是对已有的平台做前后端分离，方向主要是对已有的后端设计做改进。 运维前后端分离的开发流程 ? 如果把重构比作一桌子菜，那么重构需要做的具体的事情，我分为了几类： 业务重构，脚本管理，API管理，通用日志管理。 业务重构 l 对已有逻辑的梳理 l 去除已有项目中的冗余设计 l 多数据源的支持，设计DAO层 l 对于项目中的SQL语句调用，统一使用DAO层来对接 前后端分离的设计和改进 l 前后端开发流程 l 前端技术部分改进
73620发布于 2018-07-26 - 来自专栏服务端技术杂谈
重构系统的套路-微服务化
对于一个系统来说，用户的身份必须是统一的。 权限稍微复杂一点。和身份不同，权限通常分成两种类别： 功能权限和数据权限。
50940发布于 2018-07-23 - 来自专栏云计算行业
用领域驱动设计驱动系统重构
为什么系统功能似乎没有增加多少，但是代码却变得越来越庞大？如果系统重构是不可避免的，应该用什么样的设计思想和方法来引导我们进行系统重构。 《用领域驱动设计驱动系统重构》通过一个交通出行互联网应用的重构案例，展示随着功能不断迭代开发，系统开始腐坏变味的时候，如何利用领域驱动设计的方法驱动系统进行重构。
65230编辑于 2023-05-29 - 来自专栏新亮笔记
重构业务系统，我是这样做的
重构，是任何一个技术团队都无法绕过和回避的话题。 重构的原因有很多，可能是伴随着业务的发展与升级，系统无法快速支持需求迭代，这时就有了重构的念头，一般情况下不建议对老系统进行重构，毕竟重构是有代价的。 我最近参与了一个重构项目，接下来给大家分享下，我在重构业务系统过程中的经验总结。 1. 了解系统 接到重构任务后，不要立刻动手执行重构，而是对当前的业务流程和架构状态有个清晰的了解，如果开发过当前系统的同事还在公司，一定要拉着同事好好讨论。 我们要知道系统一定是给人用的，是给哪些人用的？ 业务流程图 通过了解系统之后，清楚业务的核心流程，这时要按照理解绘制 业务核心流程图，这里面涉及到与各系统的交互，需要考虑跨系统之间的交互可否使用异步完成，尽量减少循环调用的情况，同时还要确定出当前系统的边界
1.3K10发布于 2020-06-29 - 来自专栏技术之路
重构学习-重构原则
什么是重构： 视上下文重构有两个不同的定义，第一个定义是名词形式 对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本 重构的另一人用法是动词形式 使用一系列的重构手法 强调一下，重构不会改变软件的可观察行为，也就是说重构之后功能和原来一样。 为什么要重构： 重构改进软件设计，如果没有重构，程序的设计会逐渐腐败变质。 代码的减少不会使系统运行的更快，因为这对程序的运行没有任何明显影响。然而 代码的减少将使未来可能的程序修改动作更容易。代码越多修改起来就越麻烦，因为有更多的代码需要阅读和理解。 重构的原动力是：代码设计无法帮助我轻松的添加我所需要的功能，如果用某种设计方式，添加功能会简单的多，这种情况可以用 重构来弥补。重构是一个快速流畅的过程，一旦完成重构，新特性的添加会更快速，更流畅。 如果在修改bug和审查代码时发现不合理的地方也要进行重构，这样是为了更好的阅读和理解代码 何时不重构： 如果发现代码太混乱，重构它不如重写来的简单这种情况下建议重写，不用进行重构。
1.2K50发布于 2018-01-31 - 来自专栏腾讯技术工程官方号的专栏
企业微信大型Android系统重构之路
在一个已经迭代了7年的大型Android系统中，企业微信本地版不可避免地会暴露出一些遗留系统的特点。本文将探讨我们在实践中采用的一些行之有效的重构案例，以及如何让一个大型软件系统持续保持活力。 中型重构是对多个类间的重构优化，通常的一些修改包括提取接口、超类、委托等调整。大型重构是对整个系统的架构进行重构优化，比如组件化、应用中台架构升级等，通常在做大型重构时也会伴随中小型的代码重构。 三、遗留系统重构策略 3.1 绞杀者模式 3.1.1 定义 这个模式是指我们在替换一个软件系统时，在旧系统旁边搭建一个新系统，让它缓慢增长，与旧系统同时存在，逐步地“绞杀”旧系统。 五、代码重构 5.1 过大类重构 将大型的单体遗留系统重构为组件化架构后，我们有了更加低耦合、高内聚的组件。但是回到组件内部，代码质量对开发也非常重要。 遗留系统重构的最终目标是构建一个具有可扩展性、高性能、高可用性的系统架构，提高系统的开发效率和产品的迭代速度。
62110编辑于 2024-01-26 - 来自专栏全栈程序员必看
Unity3d的Log系统重构
编者注 由于要重写Unity3d的Log系统，变更为自定义方式，按照Log4j的显示的内容方法 Unity3d的Log 一般在Unity3d中编写日志入下代码 Debug.Log("hello message MethodImplOptions.InternalCall)] private static extern void SetLogCallbackDefined(bool defined); 日志系统设计
1.6K10编辑于 2022-07-20 - 来自专栏腾讯云TVP
系统重构的智慧：用领域驱动设计的方法驱动系统重构 | TVP十日谈预告
硬核分享简介 10.29丨《用领域驱动设计驱动系统重构》 硬核大咖：李智慧 同程艺龙 交通首席架构师 硬核简介：为什么互联网应用越是发展到成熟阶段，需求变更越是困难，开发周期越是变长？ 为什么系统功能似乎没有增加多少，但是代码却变得越来越庞大？如果系统重构是不可避免的，应该用什么样的设计思想和方法来引导我们进行系统重构。 《用领域驱动设计驱动系统重构》通过一个交通出行互联网应用的重构案例，展示随着功能不断迭代开发，系统开始腐坏变味的时候，如何利用领域驱动设计的方法驱动系统进行重构。 硬核大纲： 1.为什么用领域驱动设计驱动系统重构 2.用限界上下文识别模块与微服务边界 3.一个交通出行互联网应用的领域驱动设计重构实践 报名方式 线上直播将在10月29日（周四）晚19:30-20:30
28730编辑于 2023-03-30 - 来自专栏AI机器学习与深度学习算法
机器学习入门 8-8 模型泛化与岭回归
本系列是《玩转机器学习教程》一个整理的视频笔记。本小节通过探讨模型过拟合的现象，提出岭回归这个模型正则化方式，最后通过实验对α取值与过拟合（拟合曲线）之间的关系进行探讨，随着α取值从小到大，拟合曲线从弯弯曲曲到逐渐平滑。
1.2K20发布于 2020-01-14 - 来自专栏韩曙亮的移动开发专栏
【重构】重构概要--六大重构模块
重构方法介绍： 重构改善既有代码的设计 一 重新组织函数 关于注释 ：要尽可能少的使用注释 ， 注释越多代码的可读性反而更差，注释可以使用函数名来代替 ， 不要管函数名有多长， 即使函数名比函数中的代码还要长也不要紧 能更加明确的表明函数的意义，可以将这个算法替换； 二 在对象之间搬移特性 功能模块归属类：对象设计中， 将一个功能模块放在哪个类中，是最重要的任务之一，谁也不能一开始保证设计的是完全合适的，这就需要“对象之间搬移特性”这个重构方法 搬移函数和搬移字段：这两种重构方法都可以解决大多数的问题，如果两种方法同时使用，先搬移字段，在搬移函数。
86730编辑于 2023-03-27 - 来自专栏Golang语言社区
转--我们为什么选择Golang重构Worker系统
之前发了一篇帖子，讲了暴漫用golang重构了worker系统，有好多朋友问到语言选择的问题。 其实在用Golang重写我们的worker系统之前是做过很多调研的。 Parse担心为了应对业务的增长，还要第二次重构：从JRuby到JAVA。 并且Parse的工程师团队是在不想在JVM中部署并调节各种参数。 本来在MRuby上工作很好，效率很高的库，到了JRuby上 就不好使了（说白了就是各种库不成熟，生态系统太重要！） （我们重构之前只给团队讲了一个小时的语法，然后给了一些些好的worker作为参考，然后大家都可以顺利的重构2-3个worker，在两周的时间内）。 应该是worker系统的最佳选择。 暴漫的worker系统瓶颈在高并发峰值，一旦抗不过去后面就会持续累积。 而golang在单个任务上虽然只有5倍快，但是良好的并发机制，使job的执行速度飞快。
1.3K50发布于 2018-03-20
腾讯云开发者
