你们的项目经常重构代码吗？
我们的代码，经常都有代码review。但是代码review之后，大家并没有大量的重构代码。主要原因是重构代码需要花太多的时间，而且还有再次测试，对于很少的项目时间来说，重构代码是很不划算的。
不过不重构代码，大家的代码质量又很难提高。不知道大家怎么办？
如果不用TTD一般的需求是怎么记录的?
用buglist这种方式有点冗余.
需求说明书又缺很多需求变更.
实在是不知道作二期的那群人
是怎么把一期的需求
从代码中扒出来的?
上个项目最失败的几点都是由于需求扒出来的时候走了样
先出个需求说明书，然后分解成功能点或jira的task或用户故事或随便什么东西，
然后每次迭代实现一些功能，改一些bug，如此反复，直到没啥可做的了。
貌似跟tdd没啥关系。
如果不用TTD一般的需求是怎么记录的?
用buglist这种方式有点冗余.
需求说明书又缺很多需求变更.
实在是不知道作二期的那群人
是怎么把一期的需求
从代码中扒出来的?
上个项目最失败的几点都是由于需求扒出来的时候走了样
按你说法 需求难道应该用tdd来保存？
真的不知道用什么来保存
上家上上家都是用人脑来保存这些信息...... 39 楼 pangyi 2009-07-02 tuti 写道没自动测试，就不要扯什么重构。
没有自动化测试，就不能重构了吗？
不太合理吧。自动化测试与重构有必然关系吗？ 40 楼 gigix 2009-07-02 pangyi 写道tuti 写道没自动测试，就不要扯什么重构。
没有自动化测试，就不能重构了吗？
不太合理吧。自动化测试与重构有必然关系吗？
Martin Fowler 写道重构：在不改变代码可观察之行为的前提下修改代码结构以改善代码质量
没有自动化测试你怎么确保可观察的行为不改变？rename一下然后人肉回归所有功能？ 41 楼 eclipse2008 2009-07-02 是否重构那就要看性价比了。 42 楼 tuti 2009-07-03 eclipse2008 写道是否重构那就要看性价比了。
重构在我看来是种看多代码需要变动的期权。 43 楼 seekgirl 2009-07-05 呵呵，项目经理要是没有这个意思，啥也白搭 44 楼 rappy 2009-07-06 mock1234 写道不要把重构说成是一个重量级的企业开发文档开发步骤，那种理解是很荒唐的。XP的重构，是指发生在5～10分钟之内的那种操作，只有擅长每一次都高标准地完成看似短促、心血来潮就可以进行的重构才具有最大的威力，这个时候如果你的代码总是可以保持系统回归测试稳定性就可谓巅峰状态之作；而那些费了九牛二虎之力搞一场轰轰烈烈重构运动的笨重行为则反而不太擅长重构，初级水平、质量较低的开发人员就可以做这个事了。
这个说法有些偏激，尤其是最后一句。相反，这种大运动量的重构，更需要行家里手才行，否则，质量无法保证，重构等于空谈。
看了很多回复，大部分都排斥大规模的重构。但是，如果是针对老代码，老架构进行重构呢，这难道就不叫重构，就不能重构了？不然，而是缺少这样的魄力去做，没人敢冒这风险。其实，只要经过前期详细分析和设计，做好设计工作，中期在代码开发中坚决实施TDD,完全可以控制这种风险。
我理解的重构，关键不在量的多少，频度的多少，而是是否能在代码稳定性，健壮性，效率上有提升。
当然，频繁的小粒度的重构或许是种比较好的方式。
45 楼 lcllcl987 2009-07-07 我们经常号称在重构， 但干的却是重写的勾当。
我们的项目运行于乌托邦，所以可以这样。
哈哈
46 楼 tibetjungle 2009-07-08 rappy 写道
其实，只要经过前期详细分析和设计，做好设计工作，中期在代码开发中坚决实施TDD,完全可以控制这种风险。
这样做，你完全可以开发一个新的系统了。难道你没有意识到，在你给出的这个过程中，存在着重重风险吗？你去做分析，原始需求文档怎么保证？实现中，很多系统根本就没有任何文档，所有的文档都在早期开发者的脑袋里。而且即使有，你也难以保障你分析的结果是无误的，只要实际验证、使用时才会发现是否存在问题……
TDD不是万能的，而且其中隐含一个前提：你必须理解需求！
一句话，对于某些项目：do not fix it until it is broken.
47 楼 chxkyy 2009-07-09 如果是web页面，怎么做测试？手工点？ 48 楼 liusu 2009-07-24 看这个讨论，才发现我已经步入重构强迫症的行列。 我是写几行代码就不舒服就想重构。方法命名，变量命名让我很纠结。是不是需要泛型，是不是要提个接口。。 哈哈 49 楼 rocwon 2009-07-31 要想把代码写好的话，重构无处不在 50 楼 icewubin 2009-08-03 pipilu 写道楼上说的那件事儿挺逗，笑死了。我觉得不提倡做删除操作，因为那个文件一删，那以前的修改记录就无迹可循了。
SVN上文件如果是重构改名字导致的删除的话，历史都是保留的，跟着重构以后的文件走。
CVS不支持这个功能。
还有就是，真的是删除操作的话，之前的修改记录是找的回来的，就是比较麻烦而已。
51 楼 ldd600 2009-08-04 遗留代码很难重构吧，只有在fix问题的时候，适当的重构，加入相关的单元测试。即使做新的cr，也不会对遗留代码中相关部分进行大规模重构，老大们的意思一般都是不出问题，就不要去改它。 52 楼 xinnn 2009-09-16 重构代码是分层次和级别的，一般来说会有代码级的重构、模块级的重构和系统级的重构。
按照你的说法，你们的重构起码是模块级以上的了，如果是这样的话问题可能就会比较多了，很大一部分原因是系统模块的设计问题了，如果设计的兼容性比较差的话是会导致需要不断的做重构来适应需求的不断变化，而好的设计人员往往会提前在设计之时考虑到相关会涉及到的问题从而在设计方案中为潜在的问题和需求预留好解决的接口，不会导致系统出现大的改动，更不会有颠覆性的重构现象。
代码级的重构在功能实现之时就要自己来对涉及性能和复杂逻辑等问题进行代码重构了，而review的一个很重要的一点就是大家相互之间提出对代码的编写意见，其实质就是相互之间提出代码的重构意见。
总之，重构在项目质量的问题上时很重要的一环，具体来说重构在项目中的比重到底应该占多少，应该视对项目质量的比重而定，比如对时间比较紧的项目就可适当减少重构的比重。我曾做过连测试都没有就发布的项目，更不要说重构了，最要紧的问题是项目允许你的时间不够了。而重构代码绝对对你的代码编写能力的提高有帮助 53 楼 Durian 2009-12-21 1.反对TDD开发,太浪费时间，平时可以自己多做点黑盒，白合测试什么都有了。
2.适当的重构，不建议太大改动，测试成本太高。 54 楼 poson 2009-12-26 1.反对TDD开发,太浪费时间，平时可以自己多做点黑盒，白合测试什么都有了。
2.适当的重构，不建议太大改动，测试成本太高。Durian 写道1.反对TDD开发,太浪费时间，平时可以自己多做点黑盒，白合测试什么都有了。
2.适当的重构，不建议太大改动，测试成本太高。
确实是测试成本很高。别人帮我重构了代码，测试的时候发现一大堆问题。
不过自己经常重构，确实可以提高自己的编码水平。
55 楼 lkj107 2010-02-26 上线的系统重构风险太大，一般是忽悠上二期的时候推倒重来 56 楼 tuti 2010-02-26 Durian 写道1.反对TDD开发,太浪费时间，平时可以自己多做点黑盒，白合测试什么都有了。
2.适当的重构，不建议太大改动，测试成本太高。
TDD太浪费时间？你是和什么比太浪费时间？和Debug比？和你的黑箱，白箱测试比？
既然你那么能省时间，何必感叹代码改动还测试成本太高？
