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

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

楼上说的那件事儿挺逗，笑死了。我觉得不提倡做删除操作，因为那个文件一删，那以前的修改记录就无迹可循了。

代码得经常检查的，技术方面的负责人应该经常检查一下代码提交情况（提交注释是不是写清楚了，避免有的开发人员提交太随意），以及代码内容，有不好的地方专门找那个开发人员说一下。这种活挺累的。但是等到开发了几天功能做完了，再去重构，就很难推动了。不知道还有其它什么做法？分享一下。

你说的很对，我们不是TDD

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

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

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

十天
间隔时间太长了.....
如果修正成本比当天重构的效果差了很多.

如果是压迫式的(与自发对应)代码review
最好在当天完成.

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

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

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

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

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