delphi项目重构思路，不差钱，闲分少可以另开贴。大家说说自己的想法，我暂时打算先从命名规范开始1.去掉垃圾
delphi项目重构思路，不差钱，闲分少可以另开贴。
大家说说自己的想法，
我暂时打算先从命名规范开始
1.去掉垃圾变量和注释
2.修改变量和函数名
3.拆分函数
4.形成新的单元文件，重新安排函数应该在的单元
5.整理成类，然后调整类与类的关系等
我觉得，即使123点看似简单，但是实际操作起来还有难度。
比如，怎么入手去修改代码，按照什么顺序去修改，业务
复杂程度，等等。
欢迎大家说出想法，这是我实际的工作，希望大家能给我有效的建议。
希望大家不要三言两语以蔽之，请详细分析和讨论。
可以介绍重构的工具
最好能形成一套完整的 具体的重构方案，步骤。
[解决办法]
注重平时习惯，这个东西不是定式，各个各的思维模式
[解决办法]
首先应该把程序缕一遍，重新规范变量和函数名定义
这个应该是挺简单的吧，主要是闹清程序的逻辑，起个适当的名字
让以后看到变量或者函数名就能知道是用在哪用来做什么的
函数拆分是相对比较麻烦的可以放到后面进行
先把函数分类整理，集成到不同的类中
使函数的使用更加清晰
中间可能用到类函数，单实例对象等更方便一些
然后就是尽可能的把函数拆分
[解决办法]
重构工具推荐：ModelMaker
如果高版本DELPHI里有自带的重构工具，也可以直接用（只是听说自带的好像不是很好用而已）
[解决办法]
修改变量和函数名 <- 一直认为这样东西不应等到重构的时候才做，否则你会多花N倍功夫。代码规范是要在日常中就养成好习惯的，并且应该作为一种开发要求。
[解决办法]
不懂什么重构。
说说我的看法：
根据业务流程，划分为几个模块；
相关性强的函数和数据用类封装，对外通过函数提供一些简单明了的接口；
太大的函数最好拆小一点；
变量命名要遵循一套规则，可以自己定，也可以参照一些习惯的方法；
类的封装，追求小而精，能够以后用于其它项目的类，最好独立出来。比方像访问串口的类、处理字符串的类、访问注册表的类等等，这些东西最好不要和目前的业务有钩挂，就是一个干干净净不依赖于其它单元的类，以后的项目如果需要，直接引用就可以。
[解决办法]
进来学习一下哦 啊丫丫
[解决办法]
先介绍一下项情况,产品状态,最令你烦恼的是什么,为什么要重构,??
目的和背景说清楚了,大家好提想法.
[解决办法]
暗暗暗暗暗暗啊!!什么东东
[解决办法]
來個demo講解一下吧。
[解决办法]
进来 学习 学习
[解决办法]
[解决办法]重构还不如重新
太多的细节要改
一不小心就改漏了
麻烦就大了
[解决办法]说说我的看法：
首先要搞清楚重构的目的。是软件的性能太低？代码杂乱难以维护？需要在原有程序基础上二次开发？
另外顺序上，我的看法与楼主不太一样。
首先对原有项目的结构调查，是否有不合理的地方，之后在模块级别，类级别进行调整与替换，调整的时候要注意跟上相关的文档与注释。
至于原有的注释，无用的变量与函数有相应的工具进行检查反而不太重要，应该最后进行。原因是如果先做这些细节，可能会发现辛辛苦苦整理出来的模块，需要整体或部分重写，反而成了无用功。当然如果对原程序不是很了解，边整理边调查是可以的。
[解决办法]重构一般是发生在开发过程中的，如果是接手烂摊子的话，很难重构，尤其某些DELPHI程序啥都堆窗体里的那种。
重构最好有测试用例做保证，这样才能确保重出来的东西跟原来等效。
[解决办法]嗯，重构应该在工作中随时进行：反思积累到一定程度，就可以动手了
[解决办法]ding si ni le
[解决办法]jixu ding 4qreqr
[解决办法]那我就进来顶一下！！！！！
[解决办法]非常牛。頂一下啦。!!!!
[解决办法]如果公司给时间，可以考虑哦
------解决方案--------------------
一个人一个习惯，恐怕谁也不愿接手维护别人的代码，难受死了。
代码排列要工整这是做pm最起码的要求！
[解决办法]同意楼上，先从大处着手，弄清目的，是什么性质的，如果是一个小的应用，那么在原有基础上重新开发一个也不难，如果是基础架构方面的，那就什么都需要了。在功能分析的基础上，先划分为小的模块，OO提倡的是面向接口编程，首先把接口设计好，然后才是细节问题。
[解决办法]我感觉您的过程很混乱;
重构是在不影响软件既有功能的情况下,重新规划程序的实现结构;
不管分解函数/规划类等等,都是为了改善结构;
这个任务要看您重构代码的规模,和实际代码的工作意义来规划和实施;
大的一个重构任务可能需要很长时间,
一个小的重构任务可能就需要几分钟而已;
[解决办法]先 看书 《重构》 你说的那些都可以
但是 得有 测试保证
其次， 你重构的方向应该如下：消除重复，简化逻辑，蹭清意图。
[解决办法]hhhhhhhhhhhhhhhhhhhhh
[解决办法]1、去掉注释并不是好的做法，优秀的代码，注释只其中必不可少的部分了；
2、最好先制定一个编码规范，规范并不一定要求最好的，重要的是要从头到尾都按照规范来实施；
[解决办法]关键是建立一个良好的测试框架。最好能支持自动化测试。
重构不难，改变变量名，函数名都很容易，查找替换即可。
即使是类抽象，函数功能分解等等，也不会太难，太复杂。
关键问题还是在于重构后，原有程序功能是否被改变了？
[解决办法]看看哦，顺带学习下。頂一下啦
[解决办法]最主要是原来的代码的模块化考虑的怎么样。
如果是那种动一下而动全身的你还是慎重重构吧。
有的时候全部重写比重构简单。
最主要你要先把目前这个项目的设计框架有个整理，毕竟已经有代码了。
然后先从整体设计和局部实现看目前的设计上有没有缺陷。
先设计重构再代码重构。
[解决办法][解决办法]一般重构，是在接口一级的下面进行
还要在单元自动测试的支持下比较好，要不怎么能保证重构质量？
如果像楼主你这样重构，和重写没太大分别，不建议对旧系统，可用系统，稳定系统做这种修改
[解决办法]顺便学习一下，学习学习，相互交流，大家一起提高
[解决办法]如果楼主有诚意，第二天楼主可以给贴子加分的。
[解决办法]。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
[解决办法]顶顶更健康
靠,还是太短了
[解决办法]先用Peganza.Pascal.Analyzer.v4.6.2.Cracked-EAT.rar
来分析下,能指出有些变量命令不规则等.
然后再自己人工去看下
[解决办法]mark 有空看 哈哈哈
[解决办法] 顶起~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[解决办法]谢谢哦 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~·
[解决办法]顶，谢谢楼主！！！！！！！！！！！！！
[解决办法]不明白什么意思 唉！！！！！！！！！！！！！！
[解决办法]刚开始学习delphi，感觉很不习惯！！
[解决办法]我觉得：
1.首先要搞清楚重构的目的。
2.从大框架入手,比如模块整理,把模块中的过程分清楚来,然后再将继承该模版的版块进行整理及优化.
3.没有实在必要情况下不更改变量名的命名,如果该过程不经常修改,实在没有这个必要.
4.整理好编程规范文档,使整理后的代码有很好的良性发展.
------解决方案--------------------
如果源代码非常不规范，又想仔细整理，还是重写吧。把有用的留下，没用的去除。做适当的分类，建立相应单元。
[解决办法]要养成习惯，注释是要的。
[解决办法]修改别人的代码是最麻烦的事情了。
我觉得要规范代码的开发，是一个循序渐近的过程了。
[解决办法]进来学习一下 请多多指教谢谢！
[解决办法]希望得高人指点.谢谢
[解决办法]学习一下，谢谢楼主啦！
[解决办法]重构条件：
> 人员因素：需要技术比较全面的人领头做
> 时间因素：最合适的时机是项目开发完成，测试出很多问题或产品升级，这两个时间点最好，选择其它时间会因为各种压力而不能将重构继续下去
> 持续因素：重构工作是持续进行的过程，不能延续下去的重构工作是没有多少实际效果的。
重构的切入点：
> 编码规范
> 函数/方法改造
> 算法改造
> 结构改造
> 使用重构工具进行改造
需要选择一个合适的切入点
总结：
重构其实是在合适的时间里由合适的人按照合适的方式将代码改造、完善的更合适，不太好把握
[解决办法] 重构是个持续过程，不是在某个阶段一步完成的。
重构不必全部，更不是重写；
建议从必要的核心的局部开始，从小大到大，从局部到整体逐步累积进行，可能更切合实际。
[解决办法]1.重构原因,不是要在此基础上进行二次开发的话,我觉得没必要那么深入的重构
2.具体重构的方式和手法,都不重要,最重要的是测试,一定要有一个好的测试座保障,尤其你的项目已经在用了的
3.建议看下<重构>,我看的是C#的,但都是相通的,网上电子版很多
[解决办法]注重平时习惯，这个东西不是定式，各个各的思维模式
[解决办法]我的宗旨？？具体问题具体对待？？
习惯确实有时候很重要？
[解决办法]我的重构经验是：
1、画出数据流程图（可简单画，只要自己能看明白）；
2、重新拆分类结构；
3、规范函数、变量；
4、在重构的过程中尽量先满足可读，然后再优化效率，当然对效率极高的可以反过来，但一定要做好注释；
5、考虑周全，保证程序的7*24小时运行（这个非常重要，决定你这次重构的成败）；
我觉得重构不是替别人檫屁股，对自己的帮助非常大，提高也是非常有好处的。写的不一定对，仅供参考。
