首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 来自专栏小二十七

    代码重构:类重构8 个小技巧

    就要运用一些重构的技巧,来让代码结构保持整洁,从而让后续的需求扩展更加稳定 1:合理的分配函数 说明:从 OOP 的角度来考虑,如果函数之间频繁的调用,显然适合放在一个对象当中 使用场景:在 A 对象内 _type.isPremium() 的函数调用出现,看上去更合理 总结 通过 示例一 我们可以得出总结: 如果一个对象有太多行为和另一个对象耦合,那么就要考虑帮它搬家 只要是合理的分配函数,就可以使系统结构 ,程序会跟随需求不断变化,没有任何设计是可以保持一成不变的,所以这里的重构方法,不需要等到特定的时间和特定的规划再去进行,重构应该是融入在日常开发当中,随时随地都在进行的 3:拆解大类 说明:随着需求越来越多 department; } } 总结 当需要委托的特性越多,隐藏委托模式就显得没有必要,直接调用提供人代码会更简单 如果只有简单的委托特性,建议使用隐藏委托关系 7:扩展工具类 使用场景:当系统工具库无法满足你需求的时候 arg.getDate() + 1); } 总结 通过扩展工具类,为工具类增强更多的功能,从而满足业务的需求 如果有可能(获取修改工具类的权限),那么可以考虑把扩展函数搬到工具类内部,让更多人复用 8

    1.5K20发布于 2021-10-20
  • 来自专栏服务端技术杂谈

    重构系统的套路-明确重构目的

    重构系统的套路系列: 本篇说下重构系统的套路中的,明确重构的目的。 ? 我们进行系统重构会抱着不同的目的,比如为了系统稳定性,为了系统中某些功能负载能力更强,为了系统更便于维护,或是为了系统更便于持续集成提升RD和QA的人效。 上面这个虽然是我自己在系统梳理过程中意淫出来的场景,但我不得不再我进行类似系统重构之前,在代码逻辑角度,功能业务角度,缓存集群,mq集群,DB集群等角度考虑,我这次重构可能造成的问题,只有我们在系统重构之间能够想的比黑天鹅来的更快我们才能对系统做更多的保护 如果系统重构的目的在于可维护性,和上面两点的区别在于,周期不可操之过急。 我们需要在整个业务角度去理解系统,同时对未来系统所承接的业务有所评估,这样我们才能设计出一个面向未来的系统。 基于以上四点不同的重构需求,我们采取的方案和执行的角度完全不同,系统变大了之后,稳定第一。

    2.4K30发布于 2018-09-21
  • 来自专栏Java架构师学习

    如何做系统重构

    明确当前系统的状态 决定要执行重构后,首要做的任务,并不是立刻动手执行重构,而是对当前的架构状态有清晰的了解,如果开发当前系统的同事还在本公司,一定要拉着同事好好的讨论一下,作者给大家讲讲当时的思路,比我们闷头看代码理解还是要强不少的 除此之外,通过研究当前系统,才能记录目前系统的性能基准,为未来评估重构的效果做准备。 重构中必须建立或者维护业务数据流 大家有任何想法和建议,请加我的JAVA架构进阶群:554355695 现在任何一个后台系统,都会通过日志系统建立必要的业务流转记录,比如,我这几年前后带的几支团队,都会建立各类业务埋点 在重构过程中或者重构后,我们能用数据来验证重构的效果,能不断的对系统进行优化。 5. 8. 重视重构中的非技术问题 这一点是我过去1年,理清楚的一些问题,趁这个机会分享一下: 舒缓团队的压力,给予团队更多的鼓励。说白了,重构对个人或者团队来说通常是一件费力不讨好的事情。

    1.6K50发布于 2018-05-04
  • 来自专栏杨龙飞前端

    vue重构后台管理系统调研

    Q4要来了,我来这家公司已经一个季度了,通过对公司前端框架的整体认识,对业务的一些认识,发现,这些东西也都是可以重构,无论是v2,还是v3的代码。 进入重构,首先的问题是,后端渲染,为什么要做后端渲染,因为有时候会做google统计,seo优化,之类的,必须用后端渲染才行,普通的spa就不行了,而且语言包那一块需要去服务器拉去数据后才能生成文件,必须有后端服务做支撑 但是这样搭载过之后,我发现,后台管理系统里会有一些统计数据的工具,这时候可能会引入vue的图标框架,但是我不能确定vue的图表插件能否支持ssr 纠结之中我还是放弃了,如果以后有小的项目可以试一下。

    1.8K10发布于 2018-10-11
  • 来自专栏java思维导图

    大型系统重构的步骤梳理

    作者:Yomut 原文:https://my.oschina.net/yomut/blog/714497 目前正在参与公司一个核心大系统重构工作。本文梳理一下大型系统重构的一些步骤和心得。 系统除了要应付大量的并发请求,还必须快速支持各种业务需求,必须对系统进行大重构。 备注: 下面的一些步骤和方式是根据我自己的项目的实际列出的。 数据库重构 前期的项目,由于赶进度,并没有充足的时间设计表,导致各种冗余表、大表、大量的冗余的字段、扩展性差的表。所以重构系统的时候,可以先从表开始,通过对当前业务的梳理,重新把表整理一下。 1. 数据库重构,一般由专门的数据架构师来处理。数据架构师必须和业务架构师紧密配合。 数据迁移 由于对数据库进行了重构,那么旧数据库的数据必须完整的迁移过来。 观察系统 新接口接入所有流量后,除了监控系统监控接口之外,开发人员必须经常看日志系统,观察系统是否正常工作。最好定一个任务,让开发人员轮流观察系统。 -- 完 --

    1.8K20发布于 2018-08-16
  • 来自专栏数据STUDIO

    8重构技巧使得Python代码更Pythonic

    process_standard_payment(payment) else: process_international_payment(payment) 7.用in运算符替换同一个变量的多次比较 我们甚至可以进一步重构以前的代码 process_standard_payment(payment) else: process_international_payment(payment) 8.

    45820编辑于 2023-09-18
  • 来自专栏菩提树下的杨过

    利用java8对设计模式的重构

    java8中提供的很多新特性可以用来重构传统设计模式中的写法,下面是一些示例: 一、策略模式 上图是策略模式的类图,假设我们现在要保存订单,OrderService接口定义要做什么,而NoSqlSaveOrderStragegy 比如:会员系统中,每个商家都会有一些营销活动,需要推送某种信息给会员,但是不同的商家推送的内容可能不同,有些需要推送优惠券,有些需要积分通知。 使用java8重构后,可以把上面的3个模板(包括抽象类模板)减少到1个,参考下面: public class PushTemplateLambda { public void push(int subject.registerObserver(new StockObserver()); subject.notifyAllObserver("001"); }   用java8重构后 Processor p2 = new ProcessorImpl2(p1); p2.process("something happened"); } 用java8重构

    1.4K120发布于 2018-03-28
  • 来自专栏数据STUDIO

    8重构技巧使得Python代码更Pythonic

    process_standard_payment(payment) else: process_international_payment(payment) 7.用in运算符替换同一个变量的多次比较 我们甚至可以进一步重构以前的代码 process_standard_payment(payment) else: process_international_payment(payment) 8.

    55230编辑于 2023-09-18
  • 来自专栏用户1337634的专栏

    订单交易系统代码重构

    订单交易系统随着业务的发展,逻辑也越来越多,需要进行重构,之前已经把交易模块拆分了,目前还需要再把订单系统进一步拆分 当前的问题 订单相关代码都放在一起,随着业务发展,逻辑越来越复杂 履约和查询( 导出)对系统要求不同,不方便统一优化 重构方法 分离订单履约和查询相关逻辑代码 批量查询和导出相关逻辑,不再查询业务MySQL,改为查询ElasticSearch ps: 重构时,要注意哪些业务是基本固定的 ,哪些是经常变动的,需要把变动的逻辑尽量放到一起 参考 重构:改善饿了么交易系统的设计思路

    96310发布于 2021-07-20
  • 来自专栏云计算行业

    用领域驱动设计驱动系统重构

    为什么系统功能似乎没有增加多少,但是代码却变得越来越庞大?如果系统重构是不可避免的,应该用什么样的设计思想和方法来引导我们进行系统重构。 《用领域驱动设计驱动系统重构》通过一个交通出行互联网应用的重构案例,展示随着功能不断迭代开发,系统开始腐坏变味的时候,如何利用领域驱动设计的方法驱动系统进行重构

    75530编辑于 2023-05-29
  • 来自专栏杨建荣的学习笔记

    运维系统重构的设计思路

    最近要对已有的运维平台做重构工作,为什么要做重构,主要还是因为各种各样的原因,需要对已有的问题改进,修复历史遗留包袱。这个时间迟早都会来到,还不如自己自觉一点,提前发现问题,提前修复。 整个重构的核心思路就是对已有的平台做前后端分离,方向主要是对已有的后端设计做改进。 运维前后端分离的开发流程 ? 如果把重构比作一桌子菜,那么重构需要做的具体的事情,我分为了几类: 业务重构,脚本管理,API管理,通用日志管理。 业务重构 l 对已有逻辑的梳理 l 去除已有项目中的冗余设计 l 多数据源的支持,设计DAO层 l 对于项目中的SQL语句调用,统一使用DAO层来对接 前后端分离的设计和改进 l 前后端开发流程 l 前端技术部分改进

    79120发布于 2018-07-26
  • 来自专栏服务端技术杂谈

    重构系统的套路-微服务化

    对于一个系统来说,用户的身份必须是统一的。 权限稍微复杂一点。和身份不同,权限通常分成两种类别: 功能权限和数据权限。

    57640发布于 2018-07-23
  • 来自专栏服务端技术杂谈

    重构系统的套路-提高并发能力

    提高系统并发能力,总结起来有三点:异步,缓存,并行。 对于老系统需要在业务进行梳理,如果业务场景中不关心返回值,这样完全可以做成异步。 梳理系统的代码,将很多同步的for,while的循环改成基于Future的同步模型,提升整体并行度,达到一定的性能提升。

    76420发布于 2018-07-23
  • 来自专栏phodal

    系统重构的未来:重构工具 Coca 一周年

    也因此《系统重构与迁移指南》(https://migration.ink/) 成为了系统重构不可多选的材料,Google 『系统重构』 和 『重构工具』会有惊喜。 ? ? 系统的必然之路:系统重构 or 重写 没啥说的,部分的系统都是要被重构或者重写的。那么另外一部分呢?他们被淘汰了——要么是产品,要么是公司,笑~。 系统变成了一个大泥球,需求已经越来越难以实现: ? 真相就是这么简单。如果系统不被指南,和进行频繁的代码级重构的话,那么系统被取代的速度就更快了。 系统重构的未来 在 Coca 编写完成之后,我发布了《系统重构与迁移指南》一份短小、精悍的重构手册。 但是,对于系统重构来说,基本上很少有工具可以直接能支撑现有的系统,哪怕是 Coca 也是有限的支持。主要原因就是:大部分的内部系统都绑定了组织中的模式。

    84340发布于 2020-11-05
  • 来自专栏Grace development

    老项目重构手记之用户系统

    受邀来一起重构公司的老项目 概述 重构首先要注意几个点 – 重构后功能的可扩展性 – 业务互相依赖的复杂度 – 脱离本身的业务进行重构重构后的代码可读性与可维护性 – 性能的提升 以上几点是重构注意的地方也是重构的目的 分析 本次重构的项目运营了三年之久,用户及业务量也上不来。 根据需求分表,现在所有的第三方授权都放到一个表里了 选型 前期重构要求速度要快。所以只能选择世界上最好的语言。 COLLATE=utf8mb4_unicode_ci; 队列 通过队列,可以选择laravel内置的队列或者rabbitmq都可以。 迭代 重构并不是一言一语,几行代码或者一个大佬的方案就可以解决的。实际重构也是一个开发的过程。在不断的迭代中,将重构完成的部分补回到业务中。 致谢 感谢你看到这里,希望本篇文章可以帮到你。

    83120发布于 2018-09-18
  • 重构业务系统考虑的方案】

    快速重构系统需要以下几个步骤: 分析系统:首先,对现有系统进行彻底的分析,了解现有系统的架构、代码结构、功能和性能等方面的问题。这将帮助你确定需要重构的部分和优先级。 这些目标可能包括提高系统性能、增强系统安全性、简化代码结构等。 优化设计:根据重构目标,对系统的设计进行优化。这可能包括解耦各个模块、引入新的设计模式、重构数据库结构等。 重构代码:根据重构目标和优化设计,逐步重构系统的代码。这可能包括重命名变量和函数、简化代码逻辑、提取重复的代码块为函数等。 进行测试:在重构过程中,要进行充分的测试,确保重构后的系统仍然能够正常运行,并且能够满足重构目标。 以上是快速重构系统的一般步骤,具体的重构过程可能根据系统的实际情况而有所不同。重构需要高度的技术能力和认真的执行力,同时要注意在重构过程中保持系统的稳定性和可用性。

    19110编辑于 2025-08-29
  • 来自专栏AI智韵

    YoloV8改进策略:聚焦线性注意力重构YoloV8

    本文将FLatten Transformer的线性注意力机制引入YoloV8重构YoloV8的模块。 YoloV8官方测试结果 YOLOv8l summary (fused): 268 layers, 43631280 parameters, 0 gradients, 165.0 GFLOPs p3 230 105 0.99 1 0.995 0.801 p8 0.831 Speed: 0.2ms preprocess, 3.8ms inference, 0.0ms loss, 0.8ms postprocess per image 改进一 测试结果 YOLOv8l Ultralytics YOLOv8.0.200 Python-3.11.5 torch-2.0.1 CUDA:0 (NVIDIA GeForce RTX 3090, 24576MiB) YOLOv8l

    20310编辑于 2024-10-22
  • 来自专栏我要变牛

    Java杂谈之Java8重构指南

    假设需要为Twitter这样的应用设计并实现一个定制化的通知系统。 java8后可以像引用方法一样引用构造函数。 下面就是一个引用贷款构造函数的示例: Supplier<Product> loanSupplier = Loan::new; Loan loan = loanSupplier.get(); 通过这种方式可以重构之前的代码 product " + name); } 6、小结 Lambda表达式有助于避免使用面向对象设计模式时容易出现的僵化的模板代码,函数式编程具体实践了声明式编程(“只需要使用不相互影响的表达式,描述想要做什么,由系统来选择如何实现 ”)和无副作用计算,这两个思想能帮助更容易地构建和维护系统

    62220发布于 2021-05-28
  • 来自专栏强仔仔

    8大坑】重构springboot踩坑记录手册

    blog.csdn.net/linzhiqiang0316/article/details/80946797 今天本来想和大家说一下spring中bean的创建过程和生命周期的,可是因为项目重构过程中遇到好多的问题 坑8:各个项目之间的依赖写错,导致循环依赖。 解决办法:将maven项目进行层级依赖,将关系写明白。 ? 其它更多的坑。。。。。。。。未完待续

    1.4K40发布于 2019-05-26
  • 来自专栏新亮笔记

    重构业务系统,我是这样做的

    重构,是任何一个技术团队都无法绕过和回避的话题。 重构的原因有很多,可能是伴随着业务的发展与升级,系统无法快速支持需求迭代,这时就有了重构的念头,一般情况下不建议对老系统进行重构,毕竟重构是有代价的。 我最近参与了一个重构项目,接下来给大家分享下,我在重构业务系统过程中的经验总结。 1. 了解系统 接到重构任务后,不要立刻动手执行重构,而是对当前的业务流程和架构状态有个清晰的了解,如果开发过当前系统的同事还在公司,一定要拉着同事好好讨论。 我们要知道系统一定是给人用的,是给哪些人用的? 8. 上线后复盘 这个点非常重要,总结这过程中的经验与不足,同时表扬大家做了一件很牛X的事情,团建一波 Happy 起来。 小结 以上,仅供参考。

    1.5K10发布于 2020-06-29
领券