|
锁定老帖子 主题：你们的项目经常重构代码吗？
精华帖 (0) :: 良好帖 (5) :: 新手帖 (1) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-07-02
最后修改：2009-07-02
pangyi 写道 tuti 写道 没自动测试，就不要扯什么重构。
没有自动化测试，就不能重构了吗？ 不太合理吧。自动化测试与重构有必然关系吗？ Martin Fowler 写道 重构：在不改变代码可观察之行为的前提下修改代码结构以改善代码质量
没有自动化测试你怎么确保可观察的行为不改变？rename一下然后人肉回归所有功能？ |
| 返回顶楼 | |
|
发表时间：2009-07-02
是否重构那就要看性价比了。
|
| 返回顶楼 | |
|
发表时间：2009-07-03
eclipse2008 写道 是否重构那就要看性价比了。
重构在我看来是种看多代码需要变动的期权。 |
| 返回顶楼 | |
|
发表时间：2009-07-05
呵呵，项目经理要是没有这个意思，啥也白搭
|
| 返回顶楼 | |
|
发表时间：2009-07-06
mock1234 写道 不要把重构说成是一个重量级的企业开发文档开发步骤，那种理解是很荒唐的。XP的重构，是指发生在5～10分钟之内的那种操作，只有擅长每一次都高标准地完成看似短促、心血来潮就可以进行的重构才具有最大的威力，这个时候如果你的代码总是可以保持系统回归测试稳定性就可谓巅峰状态之作；而那些费了九牛二虎之力搞一场轰轰烈烈重构运动的笨重行为则反而不太擅长重构，初级水平、质量较低的开发人员就可以做这个事了。
这个说法有些偏激，尤其是最后一句。相反，这种大运动量的重构，更需要行家里手才行，否则，质量无法保证，重构等于空谈。 看了很多回复，大部分都排斥大规模的重构。但是，如果是针对老代码，老架构进行重构呢，这难道就不叫重构，就不能重构了？不然，而是缺少这样的魄力去做，没人敢冒这风险。其实，只要经过前期详细分析和设计，做好设计工作，中期在代码开发中坚决实施TDD,完全可以控制这种风险。 我理解的重构，关键不在量的多少，频度的多少，而是是否能在代码稳定性，健壮性，效率上有提升。 当然，频繁的小粒度的重构或许是种比较好的方式。 |
| 返回顶楼 | |
|
发表时间：2009-07-07
我们经常号称在重构， 但干的却是重写的勾当。
我们的项目运行于乌托邦，所以可以这样。 哈哈 |
| 返回顶楼 | |
|
发表时间：2009-07-08
rappy 写道 其实，只要经过前期详细分析和设计，做好设计工作，中期在代码开发中坚决实施TDD,完全可以控制这种风险。 这样做，你完全可以开发一个新的系统了。难道你没有意识到，在你给出的这个过程中，存在着重重风险吗？你去做分析，原始需求文档怎么保证？实现中，很多系统根本就没有任何文档，所有的文档都在早期开发者的脑袋里。而且即使有，你也难以保障你分析的结果是无误的，只要实际验证、使用时才会发现是否存在问题…… TDD不是万能的，而且其中隐含一个前提：你必须理解需求！ 一句话，对于某些项目：do not fix it until it is broken. |
| 返回顶楼 | |
|
发表时间：2009-07-09
如果是web页面，怎么做测试？手工点？
|
| 返回顶楼 | |
|
发表时间：2009-07-24
看这个讨论，才发现我已经步入重构强迫症的行列。 我是写几行代码就不舒服就想重构。方法命名，变量命名让我很纠结。是不是需要泛型，是不是要提个接口。。 哈哈
|
| 返回顶楼 | |
|
发表时间：2009-07-31
要想把代码写好的话，重构无处不在
|
| 返回顶楼 | |
