请教有关代码重构的问题

玫瑰从来不慌张

最近和一个同事一起合作写一个模块，她写实现部分，我写junit test case。
因为测试用例的输入参数比较多，最后要验证的参数也比较多，所以就导致一个test方法的代码行很多（可能有200多行吧）。
当我把写好的test case提交到cvs上以后，这个同事却以一个方法的方法体不应超过一屏为理由，硬是把一个test case拆分成好几个方法。
可是我觉得让一个类里面充斥着太多不能重用的private方法，反而更不利于后期的代码维护。我觉得不应该死板的守着什么重构规则，为了重构而重构。
不知道大家有没有遇到过类似的问题。当大家遇到这种问题时，是怎么解决的呢？

perryhg

这的确是个好问题，如果你经常维护代码，就会体会到小函数的好处了。把大段代码分割成小函数，不仅仅是为了重构和重用，这样做对理解代码的功能也非常有利。可能你维护和修改别人代码的机会不多，实际上随着你开发经验的增长，你的代码将来的修改人员很可能是几个月或者若干年以后的自己。Martin Fowler说过，好的代码不需要注释，如果你觉得这段代码需要注释才能让你将来回忆起它到底在干什么的话，你们你就需要重构了。要是你有机会修改过超过3000行且没有一个自定义函数的asp代码的话，你就能体会我所说的了。

tong0245

我修改过13000行的jsp 大约4000行的javascript 3000行的页面html 剩下的是java代码
在jsp中仁兄还写了若干方法和内部类 ..那个jsp我从来就没有看懂过

tong0245

private 好像和重用没有什么关系

[ 本帖最后由 tong0245 于 2006-5-14 12:42 编辑 ]

wobushiwo

一个方法的方法体不应超过一屏为理由

适当的切分是好习惯的，以后修改，拓展都有帮助

但上面的理由，主要是建立在合理的切割基础上

玫瑰从来不慌张

原帖由 perryhg 于 2006-5-14 07:04 发表
这的确是个好问题，如果你经常维护代码，就会体会到小函数的好处了。把大段代码分割成小函数，不仅仅是为了重构和重用，这样做对理解代码的功能也非常有利。可能你维护和修改别人代码的机会不多，实际上随着你开发 ...

感谢斑竹的回答
我想我有点明白了，因为以前我也试过去读别人的代码，当时就一个感觉：与其花时间去读懂，还不如我自己重新再写一个呢（呵呵，当然这是不现实的）。

玫瑰从来不慌张

原帖由 wobushiwo 于 2006-5-14 17:03 发表


适当的切分是好习惯的，以后修改，拓展都有帮助

但上面的理由，主要是建立在合理的切割基础上

这个我很同意

不过感觉自己经验还是太少了，所以有时候难以把握适当和合理的原则

tong0245

原帖由 玫瑰从来不慌张 于 2006-5-15 00:39 发表


这个我很同意

不过感觉自己经验还是太少了，所以有时候难以把握适当和合理的原则

切吧分吧 看吧

玫瑰从来不慌张

原帖由 tong0245 于 2006-5-15 11:00 发表

切吧分吧 看吧

jakieyoung

你这样想其实是软件开发中一个普遍的现象。
由于程序员缺乏沟通，导致团队成员不能互相理解别人的代码。所以你才会想“还不如自己再写一个”。
这样的话，很多时间大家都在做一些重复的事情，“重用”成了空谈。

解决这个问题的方法是：
多和同一个team的成员沟通。推荐使用XP的软件开发方法。

敏捷方法我自己也没有实践过。最近看了好多XP方面的文章，还熬夜看书。为什么因为单单看了这些文章就能够
感受到XP这种开发方式所带来的优点。多考虑一下XP的12个核心实践，就能够对自己再开发中产生的问题有很
深刻的理解。

XP这种开发方法，一开始肯定会受到管理者和程序员的一致反对。但是，当它们硬着头皮坚持一个月的时候，它们能发现
开发软件的效率增加了，质量和提高了。而且bug数量减少了，团队也更加团结了。这些还只是刚开始所能感受到的优点。
以后在软件需求变更，升级，维护或者是核心成员离开的时候，这个团队也能很快的适应，这些隐含的优点，更加难能可贵。

关于XP，还有很多很多，今天说的太多了啊～～