重构-关于整个项目的重构

常见的项目重构的方法:

  1. 梳理并且分解继承体系:继承是面向对象设计语言中一个很重要的特性,特可以减少子类的代码量。同时继承也会被误用。今天为了一个功能添加了一个小类,也许明天还会为了另外一个功能添加另外一个类。时间一长你就会发现,这个类简直就是惨不忍睹。代码会出现大量的重复,而且修改也会变得很困难。要修改这个类就要把这个类中相关的变量或者功能梳理清楚,分别给他们建立相应的父类,然后在继承下去。他们分别属于不同的功能体系,必须要有相应的继承体系。

  2. 将过程化的代码转化为对象设计:将数据记录编程对象,将大块的行为分成小块并且将行为移入相关的对象之中。常见的场景,类中有很长很长的函数和很少的数据。我们要做的是将这个很长的含糊提炼出来放到一个单独的类中来处理。

  3. 将程序分层,将数据、界面、逻辑分开:这个就要提到经典的MVC模型,这个模型的价值就在于:它想用户界面和逻辑处理分开了。即界面只包含展示所用的东西;逻辑层只包含逻辑代码而不包含界面的内容。

  4. 提炼继承体系:一个类做了很多的事情,其中有些事情是以大量的表达式来完成的,我们应该考虑为这个情况建立起相应的继承体系,使每一个子类包含一种特殊的情况。刚开始时,我们设计的时候,是一个类实现一种功能或者一个概念,但是随着时间的推移方案的改进,可能这个类添加了另外一个概念,变成了两个概念,包含两种功能,随后变成三个四个五个等。最后这个类变得就会完全陌生了,失去了原来我们设计这个类的初衷了。

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
项⽬重构⽅案设计 最近接⼿到⼀个已经成型的项⽬,然后我们的任务就是对它进⾏重构,这个项⽬是⼀个功能很齐全的WPF视频播放器(附带很多其他功 能),在仔细研究了项⽬的背景和架构以后,初步做出了⼀下的重构⽅案: ⽬前现状: 虽然整个系统做得很漂亮,代码也写得不错,但仍有以下不⾜: 1. 架构有待改善。虽然看似MVC架构,却没有遵循MVC的模式,⾥⾯逻辑和UI耦合很⾼,没有清晰的规律。 2. 没有充分⽤到WPF的特性。WPF除了给我们很多炫丽的效果外,还给我们提供了诸如Binding,command等特性,这些特性可以帮我们隔开耦合, 同时减少代码量。 3. 代码和⽂件没有组织。代码、dll、样式⽂件和资源⽂件等没有统⼀的组织,到处都有,这样看起来就会很混乱。 4. 没有建⽴公⽤代码库。没有把公⽤的代码库独⽴出来,很多地⽅都是另外在写,这样既增加了代码量,同时维护和重构也带来了⿇烦。 5. 逻辑处理不应暴露在Client端。项⽬是⼀个C/S架构的系统,没有必要把所有的逻辑都暴露在Client端,应该⽤分布式把Logic放在服务器端,这样 可以更安全同时使客户端变⼩。 6. 没有单元测试。这样⼀个庞⼤的程序,没有单元测试是⾮常危险的,我们不可能做到100%的覆盖率,但是我们可以对主要的逻辑和Function做单 元测试,这样既减少了测试⼈员的⼯作量同时整个系统的安全、稳定和可维护性得到了⼤⼤的提⾼。 7. 性能不够优化。启动项⽬,通过WPF性能⼯具Perforator和Visual Profiler分析得出,程序启动和界⾯操作都导致CPU很⾼,内存也消耗⽐较多。 解决⽅案 1. 1. 针对缺陷1的"架构问题"。做法是采⽤MVP或者MVVM模式,⽬前正在对⽐和考虑。 2. 针对缺陷2的"WPF特性"。做法是充分利⽤Binding,command等特性。 3. 针对缺陷3的"代码和⽂件没有组织"。做法是建⽴⼀些单独的⼯程或者⽂件来分类和组织这些代码,并且充分隔离 耦合。 4. 针对缺陷4的"没有建⽴公⽤代码库"。做法是把⼀些公⽤的代码和常⽤的代码做成单独的Dll,并且有完整的单元测 试,这样才能提⾼效率。 5. 针对缺陷5的"逻辑处理不应暴露在Client端"。做法是⽤WCF做为中间层,把业务逻辑全部进⾏封装,通过WCF提 供统⼀的接⼝供项⽬调⽤。 6. 针对缺陷6的"没有单元测试"。做法是不管⽤MVP还是MVVM,我们起码保证对逻辑组件的代码有充分的单元测试 覆盖,同时对⼀些公⽤的组件也要有单独的单元测试代码。 7. 针对缺陷7的"性能不够优化"。这个我会单独做⼀个性能优化列表出来,针对耗资源的操作和其他有损害性能的操 作,我们应该避免。 8. 那么我们就可以结合实际情况搭建如下的结构 9. 10. 因为使⽤了MVVM模式,所以UI结构图就做如下调整 11. 12. 由于整个项⽬客户部希望我们引⽤第三⽅的组件或者⼯具,所以很多功能都只能通过企业库实现,⽐如AOP和 IOC,log和exception对项⽬特征做了定制化,数据访问通过企业库重写实现局部ORM,对性能要求⽐较⾼的应⽤仍 然实现存储过程。对所有事务操作都转移到数据库,邮件使⽤JOB进⾏发送。⼤型数据和客户要求较⾼的实时操 作,⽤MSMQ和SSB相结合的⽅式。层次依赖关系 UI: 功能模块使⽤时候,都会⾸先通过UI层次Security模块的安全验证(验证是通过Components模块⾥⾯的⾃定义的⽤于页⾯功能以及功能 点验证的控件触发), Security模块会通过服务层获取⽤户⾝份数据,⽤于页⾯验证. 功能模块的实际功能实现,如果需要数据库⽀持,那么依然会通过服务层进⾏数据操作.整个架构基于MVVM模式。 Service:通过WCF做中间服务,使应⽤隔离开来,这样有利于扩展和维护,同事提⾼了整个应⽤程序的伸缩性。 Business Logic: 服务层内部之间的组合关系,主要体现再依赖和调⽤,由上往下调⽤,逐级依赖,最后Service底层边界Data Access模块将调 ⽤Framework中的Data模块,Data模块将调⽤MS.EntLib3中的Data,向数据服务器发送数据操作命令和数据. Framework: 该层次提供许多基础的功能模块(七⼤块),分别提供给UI,Service层⾥⾯的模块直接或者间接的调⽤,同时也可以看到 Framework层次内部各模块之间再运⾏时也有互相依赖调⽤的关系存在.该层次的部分模块会依赖和调⽤Ms.EntLib3中的模块,⼀般是按 照两个层次⾥⾯的模块名称,产⽣关系的. MS.EntLib3: 该层次的各个模块是整个系统框架中最底层的,只会在运⾏时被更⾼层次的模块依赖和调⽤,同时该层次内部各个模块之间也 存在依赖和运⾏时调⽤关系.  
Go微服务开发是利用Go语言进行微服务架构的开发方式。在这个问题中,使用了gin、grpc和etcd进行重构grpc-todolist项目。 Gin是一个轻量级的Web框架,使用它可以快速构建高性能的Web应用程序。它具有简单易用、性能出色和灵活的特点。在微服务开发中,Gin可以作为HTTP服务器框架,处理和响应客户端的HTTP请求。 gRPC是一种高性能、开源的远程过程调用(RPC)框架。它支持多种编程语言,并使用带有协议缓冲区的Google Protocol Buffers进行数据交换。在微服务架构中,gRPC可以用于服务之间的通信,通过定义接口和消息格式,实现服务间的数据传输和调用。 Etcd是一个高可靠、分布式的键值存储系统。它使用Raft一致性算法来保证数据的可靠性和一致性。在微服务开发中,Etcd可以作为服务发现和配置管理的工具,用于注册和发现各个微服务的信息。 对于重构grpc-todolist项目来说,使用gin可以将原有的HTTP接口改写为更加高性能的接口,提高整个系统的性能。通过使用gRPC,可以将原有的接口定义为gRPC接口,实现服务间的高效通信,并且易于扩展和维护。同时,借助Etcd实现服务注册和发现,提高系统的可用性和灵活性。 总而言之,通过使用gin、grpc和etcd对grpc-todolist项目进行重构,可以提高系统性能、扩展性和可维护性。这种微服务开发方式能够更好地适应大规模分布式系统的需求,使得系统更加稳定和可靠。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

wb175208

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值