16,749
社区成员
发帖
与我相关
我的任务
分享delphi项目重构思路，不差钱，闲分少可以另开贴。
大家说说自己的想法，
我暂时打算先从命名规范开始
1.去掉垃圾变量和注释
2.修改变量和函数名
3.拆分函数
4.形成新的单元文件，重新安排函数应该在的单元
5.整理成类，然后调整类与类的关系等
我觉得，即使123点看似简单，但是实际操作起来还有难度。
比如，怎么入手去修改代码，按照什么顺序去修改，业务
复杂程度，等等。
欢迎大家说出想法，这是我实际的工作，希望大家能给我有效的建议。
希望大家不要三言两语以蔽之，请详细分析和讨论。
可以介绍重构的工具
最好能形成一套完整的 具体的重构方案，步骤。
我暂时打算先从命名规范开始
1.去掉垃圾变量和注释
2.修改变量和函数名
3.拆分函数
4.形成新的单元文件，重新安排函数应该在的单元
5.整理成类，然后调整类与类的关系等
我觉得，即使123点看似简单，但是实际操作起来还有难度。
比如，怎么入手去修改代码，按照什么顺序去修改，业务
复杂程度，等等。
欢迎大家说出想法，这是我实际的工作，希望大家能给我有效的建议。
希望大家不要三言两语以蔽之，请详细分析和讨论。
可以介绍重构的工具
最好能形成一套完整的 具体的重构方案，步骤。
...全文
请发表友善的回复…
发表回复
lshlin 2010-03-11
- 打赏
- 举报
我也是来学习的。。。。
dj2437 2010-03-06
- 打赏
- 举报
意义不大,一味优化只会让他的成本加倍,如果你是把客户圈起来能养大,那么慢慢自已玩吧,别问人
灰太狼A 2010-03-02
- 打赏
- 举报
关注~~~！！！！！！！！学习
foodztf 2010-03-01
- 打赏
- 举报
还是有新项目再开始，事情太多了，没有外在驱动坚持下去难呀。我反正没那毅力。程序就那么回事。为市场服务的。讨论就行了，别真做
fenshm 2010-02-24
- 打赏
- 举报
关注~~~！！！！！！！！学习
cuixd2020 2010-02-24
- 打赏
- 举报
楼上说的很好。尤其这句
我觉得重构不是替别人檫屁股，对自己的帮助非常大，提高也是非常有好处的
我觉得重构不是替别人檫屁股，对自己的帮助非常大，提高也是非常有好处的
SQLDebug_Fan 2010-02-23
- 打赏
- 举报
我的重构经验是：
1、画出数据流程图（可简单画，只要自己能看明白）；
2、重新拆分类结构；
3、规范函数、变量；
4、在重构的过程中尽量先满足可读，然后再优化效率，当然对效率极高的可以反过来，但一定要做好注释；
5、考虑周全，保证程序的7*24小时运行（这个非常重要，决定你这次重构的成败）；
我觉得重构不是替别人檫屁股，对自己的帮助非常大，提高也是非常有好处的。写的不一定对，仅供参考。
1、画出数据流程图（可简单画，只要自己能看明白）；
2、重新拆分类结构；
3、规范函数、变量；
4、在重构的过程中尽量先满足可读，然后再优化效率，当然对效率极高的可以反过来，但一定要做好注释；
5、考虑周全，保证程序的7*24小时运行（这个非常重要，决定你这次重构的成败）；
我觉得重构不是替别人檫屁股，对自己的帮助非常大，提高也是非常有好处的。写的不一定对，仅供参考。
yangchao0618 2010-02-21
- 打赏
- 举报
我的宗旨？？具体问题具体对待？？
习惯确实有时候很重要？
习惯确实有时候很重要？
xjlqlqlq 2010-02-20
- 打赏
- 举报
重构是个持续过程，不是在某个阶段一步完成的。
重构不必全部，更不是重写；
建议从必要的核心的局部开始，从小大到大，从局部到整体逐步累积进行，可能更切合实际。
重构不必全部，更不是重写；
建议从必要的核心的局部开始，从小大到大，从局部到整体逐步累积进行，可能更切合实际。
麦客来了 2010-02-20
- 打赏
- 举报
重构条件：
> 人员因素：需要技术比较全面的人领头做
> 时间因素：最合适的时机是项目开发完成，测试出很多问题或产品升级，这两个时间点最好，选择其它时间会因为各种压力而不能将重构继续下去
> 持续因素：重构工作是持续进行的过程，不能延续下去的重构工作是没有多少实际效果的。
重构的切入点：
> 编码规范
> 函数/方法改造
> 算法改造
> 结构改造
> 使用重构工具进行改造
需要选择一个合适的切入点
总结：
重构其实是在合适的时间里由合适的人按照合适的方式将代码改造、完善的更合适，不太好把握
> 人员因素：需要技术比较全面的人领头做
> 时间因素：最合适的时机是项目开发完成，测试出很多问题或产品升级，这两个时间点最好，选择其它时间会因为各种压力而不能将重构继续下去
> 持续因素：重构工作是持续进行的过程，不能延续下去的重构工作是没有多少实际效果的。
重构的切入点：
> 编码规范
> 函数/方法改造
> 算法改造
> 结构改造
> 使用重构工具进行改造
需要选择一个合适的切入点
总结：
重构其实是在合适的时间里由合适的人按照合适的方式将代码改造、完善的更合适，不太好把握
cuixd2020 2010-02-20
- 打赏
- 举报
总结：
我觉得有些工作说了没用，还是自己好好做实在。
我觉得有些工作说了没用，还是自己好好做实在。
前云 2010-02-20
- 打赏
- 举报
注重平时习惯，这个东西不是定式，各个各的思维模式
jin20000 2010-02-20
- 打赏
- 举报
1.重构原因,不是要在此基础上进行二次开发的话,我觉得没必要那么深入的重构
2.具体重构的方式和手法,都不重要,最重要的是测试,一定要有一个好的测试座保障,尤其你的项目已经在用了的
3.建议看下<重构>,我看的是C#的,但都是相通的,网上电子版很多
2.具体重构的方式和手法,都不重要,最重要的是测试,一定要有一个好的测试座保障,尤其你的项目已经在用了的
3.建议看下<重构>,我看的是C#的,但都是相通的,网上电子版很多
alicelijing1 2010-02-19
- 打赏
- 举报
学习一下，谢谢楼主啦！
fzman 2010-02-19
- 打赏
- 举报
希望得高人指点.谢谢
luohuajun 2010-02-18
- 打赏
- 举报
进来学习一下 请多多指教谢谢！
studyzyq 2010-02-18
- 打赏
- 举报
修改别人的代码是最麻烦的事情了。
我觉得要规范代码的开发，是一个循序渐近的过程了。
我觉得要规范代码的开发，是一个循序渐近的过程了。
mingjunwang 2010-02-16
- 打赏
- 举报
要养成习惯，注释是要的。
yshuui 2010-02-15
- 打赏
- 举报
如果源代码非常不规范，又想仔细整理，还是重写吧。把有用的留下，没用的去除。做适当的分类，建立相应单元。
22932565 2010-02-15
- 打赏
- 举报
我觉得：
1.首先要搞清楚重构的目的。
2.从大框架入手,比如模块整理,把模块中的过程分清楚来,然后再将继承该模版的版块进行整理及优化.
3.没有实在必要情况下不更改变量名的命名,如果该过程不经常修改,实在没有这个必要.
4.整理好编程规范文档,使整理后的代码有很好的良性发展.
1.首先要搞清楚重构的目的。
2.从大框架入手,比如模块整理,把模块中的过程分清楚来,然后再将继承该模版的版块进行整理及优化.
3.没有实在必要情况下不更改变量名的命名,如果该过程不经常修改,实在没有这个必要.
4.整理好编程规范文档,使整理后的代码有很好的良性发展.
加载更多回复（50）
