你们的项目经常重构代码吗？

我们的代码，经常都有代码review。但是代码review之后，大家并没有大量的重构代码。主要原因是重构代码需要花太多的时间，而且还有再次测试，对于很少的项目时间来说，重构代码是很不划算的。

不过不重构代码，大家的代码质量又很难提高。不知道大家怎么办？

评论

36 楼 seen 2009-07-01  

抛出异常的爱 写道

gigix 写道

neptune 写道

注意：如果是大项目或长时间的项目，重构好。如果是小项目或一次的项目，不要冲动，重构是需要成本的。

然后等客户说“第一期做得不错呀，你们接着做第二期吧”的时候抓栏杆撕床单

如果不用TTD一般的需求是怎么记录的?
用buglist这种方式有点冗余.
需求说明书又缺很多需求变更.
实在是不知道作二期的那群人
是怎么把一期的需求
从代码中扒出来的?

上个项目最失败的几点都是由于需求扒出来的时候走了样

按你说法 需求难道应该用tdd来保存？

35 楼 zhuxinyu 2009-07-01  

重构。。。。。。 重新构思。


          目的：改善原有的，不合理的，影响性能的问题。

34 楼 抛出异常的爱 2009-07-01  

gigix 写道

neptune 写道

注意：如果是大项目或长时间的项目，重构好。如果是小项目或一次的项目，不要冲动，重构是需要成本的。

然后等客户说“第一期做得不错呀，你们接着做第二期吧”的时候抓栏杆撕床单

如果不用TTD一般的需求是怎么记录的?
用buglist这种方式有点冗余.
需求说明书又缺很多需求变更.
实在是不知道作二期的那群人
是怎么把一期的需求
从代码中扒出来的?

上个项目最失败的几点都是由于需求扒出来的时候走了样

33 楼 gigix 2009-07-01  

neptune 写道

注意：如果是大项目或长时间的项目，重构好。如果是小项目或一次的项目，不要冲动，重构是需要成本的。

然后等客户说“第一期做得不错呀，你们接着做第二期吧”的时候抓栏杆撕床单

32 楼 neptune 2009-07-01  

一段时间后（有空），回头再看、再想原来的代码，一定会有不好地方，重构是必须的。如果不重构，一直推着做，大家就会养成“只实现功能”的习惯，常吃以往代码可想而知。

重构好处：
1.使用新的代码模式，新的框架，新的类库。
2.取老项目的优点，去其不好的地方。
3.新的思路，新的想法，会部用上。
4.一些看不上原代码质量的（因此而没有积极性的员工，或因此而要离职的员工），会留下（重要呀），而且会增加这些程序狂人的“激情”。

注意：如果是大项目或长时间的项目，重构好。如果是小项目或一次的项目，不要冲动，重构是需要成本的。

31 楼 墓里活人 2009-06-30  

逻辑封装为一组 业务封装为一组
即使在小的业务模块里，仍然可以做此划分。

重构的前提，建立在一开始就有充分的最大化解耦的思想。
重构才体现出 高复用的效果。

否则只是在做无谓的 代码拆分工作而已。

30 楼 laodizhuq 2009-06-30  

我一般边写边重构，因为一开始为了让思路快速展开，很多时候不能够很好的考虑代码结构和执行效率等问题，等写的60％成型后，就会逐渐的发现前面写的代码的不足之处，然后就开始一边写新代码，一边重构。

如果到了最后的代码review了才发现有很多问题，需要重构，那这个开发过程就比较失败了。因为这样的重构代价很大，但是不重构往往问题更大。

29 楼 tuti 2009-06-30  

poson 写道

advantech 写道

我觉得LZ这种重构不可能做的起来，周期太长了，问题积攒的太多。
抛开TDD不说，在普通项目里重构应该说是一个比较高级的技巧，需要程序员有良好的素养和一定的经验。如果一个新人不经过系统的培训，他根本就不知道什么地方应该重构，怎么重构。

严重同意你的说法
如果没有系统的培训，开发人员根本没有重构的意识。即使你给他指出重构的方向，他可能还是不以为然。

说白了，这还不是重构的问题，这是基本功的问题。
根本不知道程序应该写成什么样才算完。

28 楼 poson 2009-06-30  

advantech 写道

我觉得LZ这种重构不可能做的起来，周期太长了，问题积攒的太多。
抛开TDD不说，在普通项目里重构应该说是一个比较高级的技巧，需要程序员有良好的素养和一定的经验。如果一个新人不经过系统的培训，他根本就不知道什么地方应该重构，怎么重构。

严重同意你的说法
如果没有系统的培训，开发人员根本没有重构的意识。即使你给他指出重构的方向，他可能还是不以为然。

27 楼 daquan198163 2009-06-30  

by5739 写道

by5739 写道

不要把所有该重构的地方积攒起来再一次性重构...这样积重难返..你都不想重构了...每当闻到bad smell的时候就应该重构了....当然需要完整的测试用例....
我们这里有个哥们最快每5分钟重构一次....有一次...这哥么和另一个哥们A合作.....A5分钟之前还在改某java文件..好不容易改好...提交svn....结果报告说版本过期..再一查...这个文件已经没有了...大喊救~~命....那哥们说...我1分钟之前重构删掉了..不要作废了.....哈啊哈哈....后来很长一段时间都成了我们的笑料..........

以至于这件事之后..每当我们要改某个java文件...就会对那哥们调侃大喊:某某java文件我正在改...可能超过5分钟....你不要重构删掉啊~~~~~~~~~~~~~哈哈哈.....

其实不是他的错，是你们svn更新和提交的频率太低了。

26 楼 advantech 2009-06-30  

我觉得LZ这种重构不可能做的起来，周期太长了，问题积攒的太多。
抛开TDD不说，在普通项目里重构应该说是一个比较高级的技巧，需要程序员有良好的素养和一定的经验。如果一个新人不经过系统的培训，他根本就不知道什么地方应该重构，怎么重构。

25 楼 by5739 2009-06-30  

by5739 写道

不要把所有该重构的地方积攒起来再一次性重构...这样积重难返..你都不想重构了...每当闻到bad smell的时候就应该重构了....当然需要完整的测试用例....
我们这里有个哥们最快每5分钟重构一次....有一次...这哥么和另一个哥们A合作.....A5分钟之前还在改某java文件..好不容易改好...提交svn....结果报告说版本过期..再一查...这个文件已经没有了...大喊救~~命....那哥们说...我1分钟之前重构删掉了..不要作废了.....哈啊哈哈....后来很长一段时间都成了我们的笑料..........

以至于这件事之后..每当我们要改某个java文件...就会对那哥们调侃大喊:某某java文件我正在改...可能超过5分钟....你不要重构删掉啊~~~~~~~~~~~~~哈哈哈.....

24 楼 by5739 2009-06-30  

poson 写道

by5739 写道

不要把所有该重构的地方积攒起来再一次性重构...这样积重难返..你都不想重构了...每当闻到bad smell的时候就应该重构了....当然需要完整的测试用例....
我们这里有个哥们最快每5分钟重构一次....有一次...这哥么和另一个哥们A合作.....A5分钟之前还在改某java文件..好不容易改好...提交svn....结果报告说版本过期..再一查...这个文件已经没有了...大喊救~~命....那哥们说...我1分钟之前重构删掉了..不要作废了.....哈啊哈哈....后来很长一段时间都成了我们的笑料..........

很有道理，但是我的重构的频率要低很多，可能半天或者两天才回去重构。

你们都是做了重构的培训么？还是自学？

整个公司开发人员集体学习了<重构—改善既有代码的设计>一书...上面有很多重构的方法和判断bad smell的方法....虽然很多重构的方法整好是相反的两个方向, 虽然我肯定记不得具体有多少种方法了...但是寻找bad smell的嗅觉....我留下了....每当闻到bad smell....我就有重构的欲望~~~~~~~~~~~ ...因为重构完之后....看着代码很舒服.....

23 楼 whaosoft 2009-06-29  

经常事儿 哎 我才知道美国人和日本人做事的态度太不一样了

22 楼 gecheng 2009-06-29  

有注释的地方就应该重构了，我们的目标：没有注释！

21 楼 daquan198163 2009-06-29  

TDD是不是以开发效率换代码质量（原标题：单元测试/TDD的成本和收益）
这里曾经讨论过一阵

20 楼 qiudawei115 2009-06-29  

重构的问题好像大家总是在说，但是。。。

19 楼 poson 2009-06-29  

RCFans 写道

code review更多的是在编码结束之后，发布测试版之前检查代码书写是否规范，有无潜在的漏洞和错误，通常有一个review的标准（QA颁发），然后进行。
重构更多的是改善程序的整体结构的有机性，和code review不是一回事。

恩。
看来是我概念没有搞清楚啊。

18 楼 RCFans 2009-06-29  

code review更多的是在编码结束之后，发布测试版之前检查代码书写是否规范，有无潜在的漏洞和错误，通常有一个review的标准（QA颁发），然后进行。
重构更多的是改善程序的整体结构的有机性，和code review不是一回事。

17 楼 香克斯 2009-06-29  

poson 写道

香克斯 写道

问一句，没别的意思 “对日外包？”
至少你们的这种做法像。1段时间的代码review只能是作为一种评估的手段，不应该用这个作为重构的前提。重构应该是随时进行的

不是外包，是互联网公司：）

我觉得你说的很对。
我们把review更多的当成是找问题和提高编码设计水平的一种手段。

作为“提高编码设计水平的一种手段”来说review是可行的。但是最好像老抛说的那样尽量以一天作为一个周期，否则积重难返,周期太长的话就算review出问题，改起来也麻烦，而且风险也更大。
但是用来找问题，有点扯淡了。我刚毕业时干过一个对日的项目是这么干的，一行行代码进行说明，让日方评价会不会有bug（sun）。找问题还是通过完善你们的测试代码来实现会更好。