个人在重构代码中的心得体会

最近在维护客户的电子商务系统过程中对该系统的代码进行了一些简单的重构。我本来不是一个爱重构的人习惯于随意的书写代码心底里认为没有必要搞那么多花哨的东西毕竟现在的开发模式大多数是MVC已经提供了固定的代码分层和代码层级,但这次简直是忍不了了代码太庞大(1000行代码在一个方法体里面,还只是其中的一个方法),因此动手收拾一下代码。我具体做法如下:

1 对代码进行分组,分组原则是每一个小处理,每个分支代码块为单位,把相近的的代码移动到最近的位置.这样做的好处在于能够提供流畅的阅读,不用去满篇的去找某个变量或者方法,保证了阅读的连贯性,毕竟代码太长读完后面 ,前面走就还给作者了

2 新建方法把大的分组移入到新方法中。我暂且称它为拆分方法,再将大的分组移到新方法时往往会有大量广联的变量需要一起移入,虽然我们在这之前进行了一些变量移动但是还有好多全局变量。对于不能移入到新方法的,我以参数的形式传入,由于输出只有一个而新方法也有好多与原方法关联的输出,我采用out 参数传出(这个只针对了输出变量为值类型的,如果参数是引用类型就不用多此一举了)。这样做主要是为了减小方法体让文件可阅读性更高。

3 将新方法引入到原方法,并做单元测试

4 重复步骤2,3 直到原方法体变到合适的大小,至于多少代码的方法体式合适的方法体,我这里没有具体的答案,推荐在50到100行,但根据实际情况来的

5 修改方法名字,让他更贴近方法方法实际处理的业务,见文生义是我喜闻乐见的命名方式,这样其他人见到名字就能明白方法是干嘛不用再去研读方法的逻辑了,增加了又好性

6修改方法的参数。刚刚分离出来的方法,由于保留与原方法体里面的原始逻辑,所以有可能传入参数比较多,因此在有必要的时候新生成View Model类作为新的输入输出参数,将多余的参数变为新参数的属性。同时修改原方法以适应对应的变化。

7对修改进行单元测试,其实我们每做一次修改最好做一次单元测试以保证没有异常出现和功能的正常运行

8移动与当前类无关的代码到他对应的类中,这样更能满足面向对象的高内聚低耦合的原则

9 将几个类公用的逻辑放到新类或者其父类中,这样可以减少冗余逻辑和代码,减少以后在修改时遗漏导致错误

10使用了相关的设计模式,减少代码的关联比如工厂模式批量生成类实例

终于把自己这几天做了的和计划要做的步骤写出来了,经过初步的整理代码干净了不少 ,有时候就像打扫自己房间一样,做做代码的整理,既方便自己也方便后人

时间: 2024-08-08 11:00:04

个人在重构代码中的心得体会的相关文章

关于代码的一些心得体会(大神勿喷)

关于代码的一些心得体会   前  言 Lms 入行也有很久了,一直都只是忙着工作学习,却一直没能好好静下心来好好整理一下自己.时间久了,慢慢的代码越来越熟悉,敲起来也越来越顺手,自己缺总感觉有些不对.我总觉得代码不应该就是这么简单,不应该像写记叙文一样,一条一条慢慢的就罗列出来了,返回去看了看自己刚写代码的时候功能也都能够实现了.但是还是有那么多可以优化的地方.我觉得好的代码不应该只是把功能实现那么简单,我觉得好的代码应该有以下几条特点:第一,命名要规范,第二,可复用性,第三,就是注释.当然,当

工作中的心得体会

刚看了会电视,里面有一美女说“其实嘛,做生意,就是做人跟做事两个方面”,我觉得这对于工作也是这样,可叹的是,对于第二部分做人方面,我已经意识到我有这方面的问题,但怎么来修正,还在摸索当中. 第一部分 关于做事方面 开始工作之前.做好准备 如果你像我一样,遇到过很多次,加班加点做出来的东西,然而并没有被使用,我相信你也想知道,这些人,究竟想要什么?没错就是要弄清楚,到底是要干什么?还有我想说的是,不是任何一件事都需要写代码的,有的可能已经写好了啊! 工作的时候,SomeTimes,You thin

学习javascript过程中的心得体会

在看到这个编程练习的时候,我的第一反应是JS居然强大到可以代替JSP了.但仔细想想,其实这只是表面的删除,增加,并没有对数据库的数据产生任何影响,所以,JSP还是王道啊!233333 练习过程中遇到的问题,知识点总结 1.由于很多时候JS是写在head前面的,调用一些body里的元素ID,而此时body尚未载入,就会报错,找不到该元素,所以写成window.onload=function() {//调用一些元素..}写在head的前面,这样再调用就不会出错了

项目开发中的心得体会

1.在没有获取完整的信息之前,推迟决策,直到必须做出决策的时候.2.任何事情都要建立在有效信息的基础上,当需求变更时,要当机立断.3.要敢于提出自己的质疑.4.要时常留意可以改善的问题,善于发现现有阶段存在的缺陷.5.持续学习,从更高的角度认识问题,全面把握“改善质量”的宗旨.6.软件系统是为人设计,不是为了技术而设计.最终目标是实现客户的需求,帮助客户完成相应的工作.7.软件设计是一个不断优化的过程,具体的优化途径则千万条.8.要充分理解客户的需求,只有这样,才能设计出客户切实需要的软件系统.

自己做项目过程中的心得体会

首先我得感谢老师和这门课.如果没有这么门课,我的生活将一直是下课后回宿舍就打开电脑玩游戏或者看电影,宁愿发呆睡觉也不会看书学习的.有了这门课和老师布置的作业,我觉得自己什么都不会,就是个麻瓜.所以,这门课要做的项目使我要学习很多知识,如:html,css,javascript,数据库等.这样自学的感觉很充实,我很喜欢这种感觉.谢谢老师!

关于软件项目管理的心得体会之一

目的 软件项目管理是一项涉及面较广,但是非常必要的一项技能.相较于软件开发中的其他专业技能, 又更加依赖于实践和阅历.这里想跟各位同仁分享一下自己在过往项目中的心得体会,结合些许耳熟能详的理论,起到抛砖引玉的作用. 局限性 项目管理既然是一门实践科学,所以这里跟大家分享之前,还是要说明局限性.因为我之前是在一家提供软件服务的传统软件公司工作, 所以很多项目的经验都来源于作为乙方的外包项目,同时,大部分项目都是移动相关领域.目前我在一家国内的互联网公司,从事的电商相关的应用项目. 开篇 想跟大家分

一次项目重构的心得体会

接手一老项目,经过几个月之后,实在顶不顺原来的架构,一样事情要干两件活,代码冗余复杂,给维护工作带来很多问题和隐患,趁着前段时间新需求比较少,遂与产品负责人沟通之后暂停新需求,先进行项目重构.于是就花了近一个月的时间对其架构进行重构,首先是将接入部分和业务处理部分分离,其次是将业务处理部分集中,再次是引入内存数据库,实现业务处理部分无状态,将所有状态保持在内存数据中,从而使得业务处理进程可以多个进程并行,并且可以进行业务处理模块的无间断更新.重构完之后可以说是脱胎换骨了,其中有些心得和体会分享一

alpha 冲刺心得体会

我们小组从 5 月末开始 alpha 版本的冲刺,现在已经到了 6 月中旬,alpha 版本的冲刺基本接近尾声.我们使用 github 的 issue 功能来管理任务和进度,如下图所示 到今天为止,我们已经完成了 prototype 版本的所有 issue.为什么叫 prototype 而不是 alpha 呢?这是一种比较谦虚的叫法,因为游戏规则等需要多次迭代,所以我们称这个版本为"原型". 同上一篇博文一样,我还是分技术和管理两个方面来谈我的心得体会. 先说技术.在冲刺阶段,我们产生

AngularJS心得体会

AngularJS早些时候有过了解,知道这是一个JS的MVC框架,同类型的框架还有Backbone等.这次是由于项目需要,学习了两天的Angular后开始着手改之前的项目代码,这里大概说一下这一周学习Angular的心得体会吧. 首相,使用Angular最大的感受就是它的设计思路完全不同于Jquery,jquery更倾向于对Dom的操作:而使用Angular则需要你有一个全局的认识,你必须知道你想要做成什么样子才可以下手去做,所以我感觉ng对前端开发的要求比jquery要高一些.先来看看Angu